基于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.

【通聯編輯：謝媛媛】