基于Kubernetes舵手集群系统的设计及实现

单平平　林坤

摘要：为了打破运维和开发之间的边界，彻底解决DevOps中交付和部署环节的困境，基于Kubernetes的舵手集群系统应需而生。系统采用Kubernetes容器编排、EFK日志收集、Prometheus监控告警、Ceph后端存储和基于Jenkins/Gitlab的CICD技术，设计并实现了具有“源码一键部署”“日志实时收集”“监控告警展示”“数据存储分析”和“镜像管理维护”五大模块的舵手集群系统。系统不仅可以实现源码的一键部署，而且稳定可靠，功能齐全，管理性强，解决了开发和运维工程师在交付和部署环节的困境。

关键词：Kubernetes;EFK;Prometheus;源码部署;数据存储;镜像管理

中图分类号：TP311      文献标识码：A

文章编号：1009-3044（2021）03-0106-03

Abstract： In order to break the boundary between operation and development， and thoroughly solve the dilemma of delivery and deployment in DevOps， Kubernetes based helmsman cluster system should be born on demand. In this system， Kubernetes container arrangement， EFK log collection， Prometheus monitoring alarm， Ceph back-end storage and CICD technology based on Jenkins/Gitlab are used. The helmsman cluster system with five modules of “source code one key deployment”“log real-time collection”“monitoring alarm display”“data storage analysis”and “image management and maintenance”is designed and implemented. This system not only can realize the one key deployment of source code， but also is stable and reliable， with complete functions and strong management， which solves the difficulties in the delivery and deployment of development and maintenance engineers. After testing， the helmsman cluster system runs stably and achieves the expected effect.

Key words： Kubernetes; EFK; Prometheus; source code deployment; data storage; image management

1 背景

IT領域新技术、新概念层出不穷，尤其是以Docker为代表的容器技术的出现，终结了DevOps中交付和部署环节因环境、配置及程序本身的不同而造成的动辄几种甚至十几种部署配置的困境。部署的复杂度虽然降低了，但以容器格式运行的应用程序间的协同却成了一个新的亟待解决的问题，以Kubernetes为代表的容器编排技术应需而生[1-2]。

如何实现开发工程师只需为应用开发一套源码，运维工程师只需要配置一次运行时环境是很多IT工程师一直关心的问题。基于Kubernetes的舵手集群系统，是一个彻底解放开发人员和运维人员的集群系统，是高可用的、安全的、易管理的。

2 相关技术概述

舵手集群系统的部署工具及环境如表1所示：

2 系统设计

2.1 系统架构图

舵手集群系统在实现打破DevOps的边界实现源码的一键部署、日志实时收集、监控告警、数据存储和镜像管理的同时，还在抗高并发、防节点故障和数据存储可靠性上做了保障。舵手集群系统架构图如图1所示：

舵手集群系统数据流走向主要分以下几步：

1）开发工程师将项目源码合并到Master分支并推送到Gitlab源码管理仓库服务器;

2）Gitlab Webhook感知到Master分支发生改动后触发Jenkins持续集成Pod在Kubernetes集群中临时启一个Jenkins-slave Pod，进行项目源码拉取、编译、测试、构建Docker镜像、并推送镜像到私有仓库Harbor[3-5];

3）Jenkins通过Kubernetes deployment插件在Kubernetes集群中拉取推送到Harbor镜像仓库中的应用镜像制作成应用Pod，此时已经完成一键部署源码到Kubernetes集群;

4）Traefik代理容器编排集群中的应用服务，将应用服务暴露到公网供用户访问[6-7];

5）EFK日志收集集群的Kibana界面可以展示采集到的已经发布的应用服务的日志信息，供运维工程师和开发工程师分析;

6）Prometheus监控告警集群的Grafana展示界面可以实时刷新整个容器编集群和应用服务的运行状态，并将越限行为进行邮件告警发送给运维工程师;

7）舵手集群内所有有状态类应用程序的数据都存储在分布式存储集群Ceph[8]。

2.2 网络地址设计

舵手集群系统主要针对的是运维工程师和开发工程师，是对内所需，集群系统虚机采用内网IP。

1）Kubernetes集群采用三主三从模式，从架构规划上防止单点故障，保证集群高可用性;

2）由bs-k8s-ceph-209、bs-k8s-gitlab-208、bs-k8s-harbor-207三节点组成后端分布式存储Ceph集群;

3）Gitlab源码管理仓库是供开发工程师使用，独立于Kubernetes集群之外，既减轻了Kubernetes集群的负担又权限分明便于维护管理。

2.3 集群资源设计

将Etcd共享数据持久化存储集群集成到Kubernetes集群的Master节点，Ceph后端存储集群重复利用Gitlab源码管理机和Harbor镜像存储机，既完成了集群目标实现的同时又对物理主机资源进行了合理的重复性利用。

2.4 安全策略设计

集群的访问来源主要分三类人员：开发工程师、容器运维工程师和普通用户。Kubernetes对于鉴权拥有自己的一套规则，它通过一系列机制来实现集群的安全机制，包括API Server的认证、授权、准入控制机制等。最小权限原则，合理限制所有组件权限，确保组件只执行它被授权的行为，通过限制单个组件的能力来限制它所能达到的权限范围：

1）开发工程师只拥有对Gitlab服务器的操作权限，并且必须提交操作目的;

2）容器运维工程师拥有整套集群系统的全部权限;

3）普通用户对项目的访问必须经Traefik代理，确保普通用户对后端集群无感知。

3 系统架构部署

舵手集群系统实现的主要功能有：“源码部署”“日志收集”“监控告警”“数据存储”和“镜像管理”。部署舵手集群系统的过程如下：

1）Kubernetes容器编排集群部署：使用Ansible自动化部署Kubernetes容器编排集群，步骤如下：第一步：提前规划资源清单;第二步：书写资源配置清单;第三步：部署Kubernetes集群;第四步：检验部署;第五步：通过代理将Pod Service暴露到外网。

2）镜像仓库部署：为了主机资源的最大利用，在这里选择独立于Kubernetes集群之外部署。通过Harbor的UI界面，基本可以完成Harbor镜像仓库的所有功能。

3）日志收集部署：配置启动一个可扩展的Elasticsearch 集群，然后在 Kubernetes 集群中创建一个Kibana应用，最后通过DaemonSet来运行Fluentd，以便它在每个Kubernetes 工作节点上都可以运行一个Pod。

4）监控告警部署：舵手集群系统采用Prometheus的Operator部署模型，作为一个控制器，他会去创建Prometheus、ServiceMonitor、AlertManager以及PrometheusRule 4个CRD资源对象，然后会一直监控并维持这4个资源对象的状态。Grafana根据业务的需要，主要的监控对象有：主机、CPU、内存、IO性能、TCP和网络流量。AlertManager告警方式在这里使用网易云邮箱作为发送端，向QQ发送告警信息。

5）CICD部署：GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具。Jenkins通过Kubernetes Deployment插件在Kubernetes集群中临时启一个Jenkins-slave Pod进行项目源码拉取、源码编译、测试源码、制作Docker镜像、推送镜像到私有仓库Harbor。

6）分布式存储部署：分布式存储集群采用传统二进制部署，每个节点都要添加3块20G硬盘，做Ceph的Yum添加、时钟同步和免密钥登录认证。Ceph 采用原生的Dashboard功能，通过Dashboard可以获取Ceph集群的各种基本状态信息。

4 系统测试

在Kubernetes集群中观察应用Pod的变化，发现先创建了一个Jenkins-slave Pod处理源码拉取、构建、测试、打包镜像、推送镜像、部署应用Pod。过程代码如下：

# kubectl get pods -A -w | grep assembly

assembly      jenkins-agent-dl1xl-85ksz       1/1     Running             0          13s                      //临时启动一个Jenkins-Slave Pod

assembly   web-test-tomcat1-deployment-d645649bf-q272v   1/1     Running       0          22m           //部署完成應用程序

assembly      jenkins-agent-dl1xl-85ksz        0/1     Terminating         0          5m20s     //部署完成应用程序后Jenkins-Slave Pod 自动退出

在Harbor镜像管理仓库的日志记录中看到有推送和拉取。Harbor仓库日志记录图如图2所示：

在Google浏览器中访问代理域名，测试是否正确完成源码的一键部署。应用界面如图3所示。

通过观察Kubernetes 的Dashboard界面可以看到Pod确实部署成功。Dashboard显示Pod部署成功图如图4所示。

参考文献：

[1] 何鹏.基于Kubernetes云资源管理方法的研究与设计[D].北京：华北电力大学，2019.

[2] 冯一凡，朱文龙，杨双双.基于Docker的分布式网络安全攻防平台设计与实现[J].计算机产品与流通，2020（3）：47.

[3] 田贞朗.Kubernetes基于Prometheus弹性伸缩POD的方法[J].计算机产品与流通，2020（3）：270.

[4] 周莹，欧中红，李俊.基于Jenkins的持续集成自动部署研究[J].计算机与数字工程，2016，44（2）：267-270.

[5] 蔡永健，路云菲，邬远祥，等.基于Jenkins和Docker容器技术在数字化电站项目自动化部署的研究及应用[J].计算机时代，2020（2）：77-80.

[6] 李传根.Elasticsearch数据存储策略研究[D]. 重庆：重庆邮电大学，2019.

[7] 沈尚博，袁泉.基于Ansible的自动化运维工具设计与实现[J].信息与电脑（理论版），2020（1）：120-122.

【通联编辑：谢媛媛】