在公司内部,基于kubernetes实现了简单的docker应用集群系统,拿出来和大家分享下,在这个系统中,实现了应用的自动部署、动态扩容、节点切换、健康检查、AB式版本更新等功能,也欢迎大家将各自的实现也分享给我。
整体架构如下图:
其中分为分为这几个块:
首先先介绍下最重要的部分,使用kubernetes作为技术实现,关于介绍和部署可以参考之前的 blog:kubernetes 0.18.1 安装 & 部署 & 初试 ,不过这个文档中只有单机的master-slave,不太符合线上使用,我们在此基础上做了以下升级:
附上制作https私有key&证书的方法:
openssl genrsa -aes256 -out ca-key.pem 2048
openssl req -new -x509 -days 3650 -key ca-key.pem -sha256 -out ca.pem (在提示输入Common Name时,输入https访问的host,如10.10.5.103)
openssl genrsa -out server-key.pem 2048
openssl req -subj "/CN=10.10.5.103" -new -key server-key.pem -out server.csr
echo subjectAltName = IP:10.10.5.103,IP:127.0.0.1 > extfile.cnf
openssl x509 -req -days 3650 -in server.csr -CA ca.pem -CAkey ca-key.pem /
-CAcreateserial -out server-cert.pem -extfile extfile.cnf
产生三个文件: ca-key.pem , server-key.pem , server-cert.pem
设置kube-apiserver参数:
--tls-cert-file=./server-cert.pem / --tls-private-key-file=./server-key.pem
在client访问时,通过ca-key.pem来进行访问
对于container节点,没什么好说的,其实就是kubernetes slave节点,部署有:kube-proxy, kubelet,docker。没有什么好说的,主要是对个别参数做了调整等等。
我们选用gorouter作为七层路由转发工具,并将其搭建起cluster,部署见bloggorouter 安装部署, 不过在设置rules的生命周期时,我们将周期设定为永久,如果发生rules失效,通过healthCheck来删掉已失效的rule。
四层负载均衡,就很统一了,开源的可以使用LVS,土豪的可以使用F5,我们是土豪,我们使用的是F5.
为app应用所依赖的mysql、redis等,有专门的童鞋负责维护,短期内不考虑和kubernetes、docker结合。
负责应用的镜像打包,我们这里选用 jekins 作为使用的工具,每次app上线前,首先要先构建此app 版本的dockerimage,push 到私有的docker-registry。之后的升级操作流程如下:
如果是回滚也十分方便,将上一个版本在走一次这个流程即可,对应用使用者来说,没有任何终端感知,当AB两个版本都生效后,将AB两个版本的rule都加入router,在将A版本的router下掉,就完成了上线/回滚的操作。代码地址稍后放出。
健康监控检查,可以说是集群中最重要的一部分了。我们在这里没有使用kubernetes推荐的方式,我们自己将其与内部的zabbix系统做了结合,通过zabbix来对整个集群进行监控、报警、自动化操作。
对于kubernetes master,监控项有:
- kube-controller-manager的状态;
- kube-scheduler的状态;
- kubernetes中namespace、replicationcontroller、service、pods等主要资源的数量&状态变化;
2. 对于kubernetes slave(即container节点),监控项有:
- kubelet健康状态;
- kube-proxy健康状态;
- docker 的dataspace、metadataspace 使用情况;
- 当前节点运行容器的信息,包括了全部数量、正在运行的数量、版本等;
3. 对于docker容器本身,可参考blog Docker监控的一点想法 ,监控项有:
- 创建时间 & 信息参数;
- 容器运行状态;
- 容器内存、cpu、流量情况;
4. 还有一个重点是对router及其rule做重点监控 :
- 检查所有router的运行状态;
- 监控所有node状态,如果非健康,及时删除router中所以指向此node的rules;
- 检查所有的pods及对应的rule,如果pods中的app服务失效 或者 没有对应的rule指向pods(比如node节点损坏,其原有的pod移动到新node节点),此时为pod更新router中的rule;
对于日志这块,业界一直没有一项统一的做法,在这里我们的做法是通过透传的方式,将容器中的日志汇总到宿主机,在进行进一步的处理:
1. 统一了所有接入系统的app的日志规范,包括了日志格式、日志路径;
2. 将容器中应用的日志根据app的不同映射到宿主机中指定的路径;
3. 结合 flume, kafka, influxDB 还有其他一些组件( 日志系统经典的 ELK组合),将应用的日志进行汇总,方便RD同学对日志进行处理。
目前先简单介绍到这里,稍后如有可能再将具体实现细节放出。