你好,游客 登录
背景:
阅读新闻

基于kubernetes的docker集群实践

[日期:2016-09-14] 来源:极客头条  作者: [字体: ]

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

整体架构

整体架构如下图:

图片描述

其中分为分为这几个块:

  • 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,| 72fb2910302a12da3b6c7d219f31484c3 |, | 72fb2910302a12da3b6c7d219f31484c4 | , 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,部署见blog gorouter 安装部署, 不过在设置rules的生命周期时,我们将周期设定为永久,如果发生rules失效,通过healthCheck来删掉已失效的rule。

nats

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

ThirdPart

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

APP Builder

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

执行AB上线
如果是回滚也十分方便,将上一个版本在走一次这个流程即可,对应用使用者来说,没有任何终端感知,当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同学对日志进行处理。

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

收藏 推荐 打印 | 录入:admin | 阅读:
相关新闻      
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款