转载

基于kubernetes的docker集群实践

在公司内部,基于kubernetes实现了简单的docker应用集群系统,拿出来和大家分享下,在这个系统中,实现了应用的自动部署、动态扩容、节点切换、健康检查、AB式版本更新等功能,也欢迎大家将各自的实现也分享给我。

整体架构

整体架构如下图:

基于kubernetes的docker集群实践

其中分为分为这几个块:

  • APPBuilder: 应用构建模块,负责将app打包成dockerimage,并入image版本库;
  • container: 容器运行,docker容器实际运行的地方;
  • thirdPart: 应用依赖的第三方资源,如redis、mysql等;
  • scheduler: 调度系统,核心部分,负责各个子模块的智能调度;
  • router: 基于7层的请求分发,根据url将请求分发到对应的app容器;
  • nats: 基于4层的负载均衡,,将流量负载均衡到router集群;
  • healthManage: 健康检查系统,包括了对router rules、容器状态、物理机状态等各个子模块健康的检查,并做相应补救action;
  • log模块: 统一处理app所产生的日志;

scheduler

首先先介绍下最重要的部分,使用kubernetes作为技术实现,关于介绍和部署可以参考之前的 blog:kubernetes 0.18.1 安装 & 部署 & 初试 ,不过这个文档中只有单机的master-slave,不太符合线上使用,我们在此基础上做了以下升级:

  • 部署etcd集群,具体过程可以参考etcd官方: Clustering Guide
  • 部署kubernetes master cluster,分别部署有 kube-apiserver,kube-scheduler,kube-controller-manager;
  • 增加对kubernetes访问的 认证 & 授权, 具体可参考我之前的blog, kubernetes Authorization , kubernetes Authentication , kubernetes中的Admission Controllers
  • 关闭kube master的非安全端口访问,关闭 insecure-port,开启secure-port,并对kubernetes secure api访问增加前端负载均衡,如在blog kubernetes 实用 api list 所示,访问就是通过认证&https请求api(当然了其中的信息都是假的,但是格式不变);
  • 设置相关的访问权限,如,kube slave节点只允许来自kube-master节点的iP访问,kube-master只允许具有操作权限的机器节点的ip访问等等;
  • 对kubernetes master子模块的参数做符合我们要求的调整等;

附上制作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.pemserver-key.pemserver-cert.pem

设置kube-apiserver参数:

--tls-cert-file=./server-cert.pem   / --tls-private-key-file=./server-key.pem 

在client访问时,通过ca-key.pem来进行访问

container

对于container节点,没什么好说的,其实就是kubernetes slave节点,部署有:kube-proxy, kubelet,docker。没有什么好说的,主要是对个别参数做了调整等等。

Router

我们选用gorouter作为七层路由转发工具,并将其搭建起cluster,部署见bloggorouter 安装部署, 不过在设置rules的生命周期时,我们将周期设定为永久,如果发生rules失效,通过healthCheck来删掉已失效的rule。

nats

四层负载均衡,就很统一了,开源的可以使用LVS,土豪的可以使用F5,我们是土豪,我们使用的是F5.

ThirdPart

为app应用所依赖的mysql、redis等,有专门的童鞋负责维护,短期内不考虑和kubernetes、docker结合。

APP Builder

负责应用的镜像打包,我们这里选用 jekins 作为使用的工具,每次app上线前,首先要先构建此app 版本的dockerimage,push 到私有的docker-registry。之后的升级操作流程如下:

基于kubernetes的docker集群实践

如果是回滚也十分方便,将上一个版本在走一次这个流程即可,对应用使用者来说,没有任何终端感知,当AB两个版本都生效后,将AB两个版本的rule都加入router,在将A版本的router下掉,就完成了上线/回滚的操作。代码地址稍后放出。

health Manage

健康监控检查,可以说是集群中最重要的一部分了。我们在这里没有使用kubernetes推荐的方式,我们自己将其与内部的zabbix系统做了结合,通过zabbix来对整个集群进行监控、报警、自动化操作。

  1. 对于kubernetes master,监控项有:

    • kuber-apiserver的状态;

- 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;

log:

对于日志这块,业界一直没有一项统一的做法,在这里我们的做法是通过透传的方式,将容器中的日志汇总到宿主机,在进行进一步的处理:

1. 统一了所有接入系统的app的日志规范,包括了日志格式、日志路径;

2. 将容器中应用的日志根据app的不同映射到宿主机中指定的路径;

3. 结合 flume, kafka, influxDB 还有其他一些组件( 日志系统经典的 ELK组合),将应用的日志进行汇总,方便RD同学对日志进行处理。

目前先简单介绍到这里,稍后如有可能再将具体实现细节放出。

正文到此结束
Loading...