摘要：健康监控检查，可以说是集群中最重要的一部分了。我们在这里没有使用推荐的方式，我们自己将其与内部的系统做了结合，通过来对整个集群进行监控报警自动化操作。
在公司内部，基于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.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对于container节点，没什么好说的，其实就是kubernetes slave节点，部署有：kube-proxy， kubelet，docker。
没有什么好说的，主要是对个别参数做了调整等等。
我们选用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下掉，就完成了上线/回滚的操作。
代码地址稍后放出。
健康监控检查，可以说是集群中最重要的一部分了。
我们在这里没有使用kubernetes推荐的方式，我们自己将其与内部的zabbix系统做了结合，通过zabbix来对整个集群进行监控、报警、自动化操作。
对于kubernetes master，监控项有：
kuber-apiserver的状态；
kube-controller-manager的状态；
kube-scheduler的状态；
kubernetes中namespace、replicationcontroller、service、pods等主要资源的数量&状态变化；
对于kubernetes slave（即container节点），监控项有：
kubelet健康状态；
kube-proxy健康状态；
docker 的dataspace、metadataspace 使用情况；
当前节点运行容器的信息，包括了全部数量、正在运行的数量、版本等；
对于docker容器本身，可参考blog Docker 监控的一点想法 ，监控项有：
创建时间 & 信息参数；
容器运行状态；
容器内存、cpu、流量情况；
还有一个重点是对router及其rule做重点监控：
检查所有router的运行状态；
监控所有node状态，如果非健康，及时删除router中所以指向此node的rules；
检查所有的pods及对应的rule，如果pods中的app服务失效 或者 没有对应的rule指向pods（比如node节点损坏，其原有的pod移动到新node节点），此时为pod更新router中的rule；
log对于日志这块，业界一直没有一项统一的做法，在这里我们的做法是通过透传的方式，将容器中的日志汇总到宿主机，在进行进一步的处理：
统一了所有接入系统的app的日志规范，包括了日志格式、日志路径；
将容器中应用的日志根据app的不同映射到宿主机中指定的路径；
结合 flume， kafka， influxDB 还有其他一些组件（ 日志系统经典的 ELK组合），将应用的日志进行汇总，方便RD同学对日志进行处理。
目前先简单介绍到这里，稍后如有可能再将具体实现细节放出。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/26443.html
摘要：健康监控检查，可以说是集群中最重要的一部分了。我们在这里没有使用推荐的方式，我们自己将其与内部的系统做了结合，通过来对整个集群进行监控报警自动化操作。 在公司内部，基于kubernetes实现了简单的docker应用集群系统，拿出来和大家分享下，在这个系统中，实现了应用的自动部署、动态扩容、节点切换、健康检查、AB式版本更新等功能，也欢迎大家将各自的实现也分享给我。 整体架构 整体架构...
摘要：容器云的背景伴随着微服务的架构的普及，结合开源的和等微服务框架，宜信内部很多业务线逐渐了从原来的单体架构逐渐转移到微服务架构。 容器云的背景 伴随着微服务的架构的普及，结合开源的Dubbo和Spring Cloud等微服务框架，宜信内部很多业务线逐渐了从原来的单体架构逐渐转移到微服务架构。应用从有状态到无状态，具体来说将业务状态数据如：会话、用户数据等存储到中间件中服务中。 showI...
摘要：容器云的背景伴随着微服务的架构的普及，结合开源的和等微服务框架，宜信内部很多业务线逐渐了从原来的单体架构逐渐转移到微服务架构。 容器云的背景 伴随着微服务的架构的普及，结合开源的Dubbo和Spring Cloud等微服务框架，宜信内部很多业务线逐渐了从原来的单体架构逐渐转移到微服务架构。应用从有状态到无状态，具体来说将业务状态数据如：会话、用户数据等存储到中间件中服务中。 showI...
摘要：个推针对服务场景，基于和搭建了微服务框架，提高了开发效率。三容器化在微服务落地实践时我们选择了，下面将详细介绍个推基于的实践。 2016年伊始Docker无比兴盛，如今Kubernetes万人瞩目。在这个无比需要创新与速度的时代，由容器、微服务、DevOps构成的云原生席卷整个IT界。个推针对Web服务场景，基于OpenResty和Node.js搭建了微服务框架，提高了开发效率。在微服...
摘要：个推针对服务场景，基于和搭建了微服务框架，提高了开发效率。三容器化在微服务落地实践时我们选择了，下面将详细介绍个推基于的实践。 2016年伊始Docker无比兴盛，如今Kubernetes万人瞩目。在这个无比需要创新与速度的时代，由容器、微服务、DevOps构成的云原生席卷整个IT界。个推针对Web服务场景，基于OpenResty和Node.js搭建了微服务框架，提高了开发效率。在微服...
阅读 3304·2021-11-18 10:02
阅读 2753·2019-08-30 13:56
阅读 410·2019-08-29 12:36
阅读 521·2019-08-28 18:07
阅读 714·2019-08-27 10:51
阅读 3450·2019-08-26 12:13
阅读 3287·2019-08-26 11:46
阅读 3315·2019-08-23 12:00
