Docker仓库Harbor配置LDAP并开启TLS认证

公司使用harbor很长一段时间了,一直用http协议.最近升级到1.1.2版本了,顺便开启https,因此记录一下. 获取安装包 可以到项目官方Github的Release发布地址下载离线安装包,也可以下载在线安装包,一般用离线. 使用命令tar -zxf harbor-offline-installer-xxx.tgz解压下载的离线安装包. 配置 进入目录cd harbor,修改harbor.cfg文件vi harbor.cfg 设置hostname项为你harbor服务的IP或者域名,但不要设置为localhost或者127.0.0.1. ## Configuration file of Harbor #设置hostname项为你harbor服务的IP或者域名. #因为需要使用外部链接来获取服务,所以不要设置为 `localhost` 或 `127.0.0.1`. hostname = harbor.example.com #连接方式默认为http,可以改为https. ui_url_protocol = http #mysql数据库的root密码,另有需求可以自行修改. db_password = root123 #最大并发数默认为3.如果是公司或者公共镜像,可以根据服务器资源适当加大,我这改成10. max_job_workers = … “Docker仓库Harbor配置LDAP并开启TLS认证”

Read More

创建基于Fannel网络的Kubernetes 1.6.8

准备环境 Master节点的配置建议 2U2G 起,Node 节点的配置建议 2U2G 起. 需要配置各个节点的名称,IP,全部流程使用 root 权限,关闭 SELinux 与 Firewalld 服务. 节点名称和IP 三个Master节点,既为master也为node,一个纯Node节点,系统为 CentOS 7. Node Name IP master1 192.168.85.141 master2 192.168.85.142 master3 192.168.85.143 将每个节点的Hostname改为对应的Node Name: # master1 hostnamectl –static set-hostname master1 … “创建基于Fannel网络的Kubernetes 1.6.8”

Read More

Kubernetes内部监控集成: Grafana+Heapster+Influxdb

2018-06-03 Update: 在官方发布1.10.0 版本的ChangeLog中,–cadvisor-port被标记为Deprecation,其将于 1.12 版本中被默认置为关闭(可手动开启), 并在 1.13 版本中被移除. 简介 容器的出现使得应用服务变得更加扁平易扩展,从而导致监控对象的碎片化,使得监控实现更加困难. 得益于 Kubernetes / Swarm / Rancher / Mesos 等编排技术的出现,让开发人员有了相对统一的手段去监控这些运行在容器的服务,并收集数据. 而 Kubernetes 通过建立抽象层,比如 pods 和 services, 简化了容器的管理,让我们无需关心容器运行过程和它的资源消耗.但为了确保集群更安全,应用服务更高性能,因此我们需要监控我们的应用,容器,以及 Kubernetes 本身. 当下对于容器监控的主流方法是用来自的谷歌的 cAdvisor 搜集数据. cAdvisor是一个用Go编写的服务,它会收集当前节点以及运行容器的监控数据: cpu, memory, … “Kubernetes内部监控集成: Grafana+Heapster+Influxdb”

Read More

kubectl get csr 显示No Resources Found的解决记录

在添加了CA证书并部署了kube-apiserver,kube-controller-manager以及kube-scheduler几个k8s的master组件后,添加kubelet组件,同时生成证书认证的配置文件. kubelet 启动时向 kube-apiserver 发送 TLS bootstrapping 请求,需要先将 bootstrap token 文件中的 kubelet-bootstrap 用户赋予 system:node-bootstrapper 角色,然后 kubelet 才有权限创建认证请求(certificatesigning requests)。 文件token.csv内容: e21b2365eb6e3c86a670dec0bdb511cc,kubelet-bootstrap,10001,”system:kubelet-bootstrap” #正常情况下只需创建一次认证即可.配置根据token.csv中的内容自行修改. kubectl create clusterrolebinding kubelet-bootstrap –clusterrole=system:node-bootstrapper –user=kubelet-bootstrap 得到kubelet kubeconfig文件后,使用命令kubectl get csr可以看到还未认证的节点. 使用命令kubectl certificate approve {NodeName}可以加入TLS认证. … “kubectl get csr 显示No Resources Found的解决记录”

Read More

kube-apiserver搭配etcd2显示rpc error: code = 13 desc = transport is closing解决记录

code=13 按照官方的定义,应该是INTERNAL,即来自内部的错误,但有时也是自己配置上的错误. 在Ubuntu 16.04上安装kubernetes,etcd是直接apt-get安装的,当前版本为2.2.5,而kubernetes在1.5版本后默认使用etcd3的配置项。 因此在创建kube-apiserver.service配置文件时,需要指定etcd版本只需加入–storage-backend=etcd2参数即可. Ubuntu16.04的kube-apiserver.service配置文件示例,其中192.168.1.220替换为本机IP: [Unit] Description=Kubernetes API Server Documentation=https://github.com/GoogleCloudPlatform/kubernetes After=network.target [Service] User=root ExecStart=/usr/bin/kube-apiserver \ –admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \ –advertise-address=192.168.1.220 \ –allow-privileged=true \ –apiserver-count=1 \ –audit-log-maxage=30 \ –audit-log-maxbackup=1 \ –audit-log-maxsize=100 \ –audit-log-path=/var/lib/audit.log \ –authorization-mode=RBAC \ –bind-address=192.168.1.220 … “kube-apiserver搭配etcd2显示rpc error: code = 13 desc = transport is closing解决记录”

Read More

etcd cluster-health响应client: etcd cluster is unavailable or misconfigured解决记录

大体分两种情况: 1.防火墙或者iptables的原因. 2.etcd 配置错误. 解决措施 第一种情况比较好解决:开放对应端口/应用白名单,或者直接关闭防火墙 第二种就需要参考官方指导,搞明白每个设置项的功能. 放个Ubuntu16.04的示例,CentOS的改一下依赖的network名称就可以,192.168.1.220替换为本机IP: [Unit] Description=etcd – highly-available key value store Documentation=https://github.com/coreos/etcd Documentation=man:etcd After=network.target Wants=network-online.target [Service] #Environment=DAEMON_ARGS= #Environment=ETCD_NAME=%H #Environment=ETCD_DATA_DIR=/var/lib/etcd/default #EnvironmentFile=-/etc/default/%p Type=notify User=etcd WorkingDirectory=/var/lib/etcd/ PermissionsStartOnly=true #ExecStart=/bin/sh -c “GOMAXPROCS=(nproc) /usr/bin/etcdDAEMON_ARGS” #ExecStart=/usr/bin/etcd $DAEMON_ARGS ExecStart=/usr/bin/etcd … “etcd cluster-health响应client: etcd cluster is unavailable or misconfigured解决记录”

Read More

运行SourceTree后GitLab响应Forbidden解决方法

公司的Git服务是由GitLab的docker容器搭建的,当初我搭建/升级/启动都很方便,且没修改gitlab.rb配置文件,用的都是默认配置. 在SourceTree升级到2.1.10.0后,竟然坑爹的默认后台并发查询git仓库更新,近百个项目,这个并发查询超了GitLab并发访问的阈值,直接封了IP. 解决方法 根据官方说明:Rack Attack和IP Whitelist,解决方法三种: 添加IP白名单. 加大并发阈值. 直接关闭Rack Attack. 这里我是加大并发阈值和添加IP白名单. 因为跑的是容器,那么就直接进挂载的文件夹里找到config/gitlab.rb后,打开并找到gitlab_rails[‘rack_attack_git_basic_auth’]项,去掉注释,并修改为: gitlab_rails[‘rack_attack_git_basic_auth’] = { ‘enabled’ => true, ‘ip_whitelist’ => [“127.0.0.1″,”192.168.xxx.xxx”], ‘maxretry’ => 200, ‘findtime’ => 60, ‘bantime’ => 3600 } 这里在ip_whitelist字段后添加白名单IP即可,然后增加maxretry字段的值。

Read More

CentOS设置IP和hostname的shell脚本

把ens32替换为当前的网卡名称即可. #!/bin/bash if [ “(whoami)” == “root” ];then echo “当前执行权限: root” else echo “当前用户:”(whoami) echo “请使用管理员权限执行脚本.” exit fi while read -p “是否设置本机静态IP,退出输入:n,设置IP输入:y [y|n]” yn do if [[ {yn} == [Nn] ]];then exit elif [[{yn} == … “CentOS设置IP和hostname的shell脚本”

Read More