趙旭杰，粱正和

(河海大學(xué) 計(jì)算機(jī)與信息學(xué)院，江蘇 南京 211100)

0 引 言

隨著計(jì)算機(jī)技術(shù)的快速發(fā)展，傳統(tǒng)的應(yīng)用部署方式已經(jīng)無(wú)法滿足開(kāi)發(fā)者的需求。現(xiàn)如今，既要避免應(yīng)用與操作系統(tǒng)的綁定，又要改善虛擬機(jī)技術(shù)十分笨重，不利于移植的特點(diǎn)。

Docker這種應(yīng)用容器引擎的出現(xiàn)填補(bǔ)了這個(gè)空缺。相對(duì)于傳統(tǒng)方式的虛擬機(jī)，它占用的空間更少，啟動(dòng)更快，并且不需要虛擬出整個(gè)操作系統(tǒng)，只需要虛擬出一個(gè)小規(guī)模的環(huán)境。每個(gè)容器之間互相隔離，并且有著自己的文件系統(tǒng)。容器之間可以通過(guò)共用網(wǎng)絡(luò)資源棧的方式進(jìn)行交互[1]。任何應(yīng)用都可以被打包成鏡像，在發(fā)布成功后，供其他人拉取使用[2]。但是，要將Docker應(yīng)用于具體的業(yè)務(wù)實(shí)現(xiàn)，還是存在著很大的困難。人們需要一種基于容器的集群管理平臺(tái)，來(lái)解決Docker在編排、管理和調(diào)度等方面上存在的問(wèn)題。

Kubernetes的出現(xiàn)填補(bǔ)了這個(gè)空缺，它是開(kāi)源的容器集群管理系統(tǒng)，可以實(shí)現(xiàn)容器集群的自動(dòng)化部署、自動(dòng)擴(kuò)縮容、自動(dòng)維護(hù)等功能[3-4]。并且因?yàn)樗腔谌萜鞯募夹g(shù)，在移植性、擴(kuò)展性和自動(dòng)化方面也具有很大的優(yōu)勢(shì)。Kubernetes可以滿足生產(chǎn)環(huán)境中的很多常見(jiàn)需求，比如：多個(gè)進(jìn)程的協(xié)同工作、存儲(chǔ)系統(tǒng)掛載、應(yīng)用實(shí)例的復(fù)制、日志訪問(wèn)、負(fù)載均衡等[1]。通過(guò)Kubernetes，可以直接管理云平臺(tái)中多個(gè)主機(jī)上的容器化的應(yīng)用。但與此同時(shí)，它也帶來(lái)了一些操作上的麻煩。目前，大多使用Kubectl命令行的方式，對(duì)平臺(tái)應(yīng)用進(jìn)行管理。而這種方式，很大程度上降低了開(kāi)發(fā)的效率，并且提高了運(yùn)維的成本。

為了改善這種情況，該文使用集成開(kāi)發(fā)平臺(tái)Fabric8實(shí)現(xiàn)對(duì)Kubernetes集群的操作，并且使用前端框架React和組件庫(kù)Ant Design實(shí)現(xiàn)平臺(tái)的可視化。通過(guò)該平臺(tái)，管理人員可以對(duì)Kubernetes中的物理節(jié)點(diǎn)、Pod節(jié)點(diǎn)、Replication Controller、Namespaces、Service 直接進(jìn)行操作，很好地取代了命令行的方式。

1 系統(tǒng)集成相關(guān)技術(shù)

1.1 Kubernetes

Kubernetes是一種面向應(yīng)用的容器集群部署和管理的系統(tǒng),前身源自Google公司內(nèi)部的Borg系統(tǒng)，有著強(qiáng)大的開(kāi)源支撐和10年以上的技術(shù)沉淀[5]。相對(duì)于Apache下的Mesos和Docker下的SWARM，Kubernetes具備的功能更加齊全，部署也更加方便。Kubernetes在具有強(qiáng)大的集群管理、防護(hù)策略和自我修復(fù)能力的同時(shí)，還支持彈性伸縮和負(fù)載均衡，并且提供便捷的服務(wù)升級(jí)和完善的管理工具[6]。Kubernetes架構(gòu)如圖1所示。

圖1 Kubernetes架構(gòu)

Kubernetes由管理節(jié)點(diǎn)和工作節(jié)點(diǎn)組成?？梢院?jiǎn)單理解為它們之間是主從的關(guān)系[7]。為了提高平臺(tái)的可靠性和決策能力，一般會(huì)部署奇數(shù)數(shù)量的管理節(jié)點(diǎn)，而工作節(jié)點(diǎn)也會(huì)部署多個(gè)，具體數(shù)目由實(shí)際資源情況決定。采用這種策略，可以有效地避免在某個(gè)節(jié)點(diǎn)宕機(jī)后，對(duì)整個(gè)集群產(chǎn)生影響。

管理節(jié)點(diǎn)中的核心組件有APIServer、Etcd、Controller Manager、Scheduler等。APIServer是資源操作的唯一入口，有著身份認(rèn)證、授權(quán)和訪問(wèn)控制等機(jī)制，也可以用于API注冊(cè)和發(fā)現(xiàn)[1,8-9]。管理人員借助Kubectl命令行工具，可以實(shí)現(xiàn)對(duì)于Kubernetes集群的管理。Etcd是一個(gè)可信賴的分布式鍵值存儲(chǔ)服務(wù)，是Kubernetes實(shí)現(xiàn)存儲(chǔ)化的方案，里面保存著整個(gè)集群的狀態(tài)[9-10]。而Scheduler則負(fù)責(zé)資源的調(diào)度，可以將Pod調(diào)度到相應(yīng)的物理機(jī)器上[11]。在調(diào)度的過(guò)程中，它會(huì)首先與APIServer進(jìn)行交互，然后通過(guò)APIServer將請(qǐng)求寫入到Etcd中。Controller Manager負(fù)責(zé)控制器的管理，使得集群達(dá)到期望中的狀態(tài)。Controller Manager中的Replication Controller、Replica Sets和Deployment都可以直接或間接控制Pod的副本數(shù)量，使其達(dá)到期望的副本數(shù)目。并且Controller Manager具備故障檢測(cè)、自動(dòng)拓展和滾動(dòng)更新等功能。

工作節(jié)點(diǎn)中主要運(yùn)行著Kubelet、Kube-proxy和Pod。Kubelet負(fù)責(zé)管理容器的生命周期，可以對(duì)節(jié)點(diǎn)中的容器進(jìn)行刪除和添加[8,12]。為了實(shí)現(xiàn)容器間文件的持久化和共享，需要借助Volume(CVI)，而這也是由Kubelet進(jìn)行管理的[1,13]。除此之外，Kubelet還負(fù)責(zé)容器的網(wǎng)絡(luò)管理和監(jiān)控等。因?yàn)楣?jié)點(diǎn)中容器有著大量的副本，所以Kubernetes Service想要訪問(wèn)其中對(duì)應(yīng)的副本，需要借助于Kube-proxy。并且Kube-proxy通過(guò)IPVS的模式，可以讓Service與Pod之間實(shí)現(xiàn)負(fù)載均衡。Pod既是工作節(jié)點(diǎn)中的主要成分，也是Kubernetes的最小單位，它的生命周期取決于其內(nèi)部容器的狀態(tài)[14]。

1.2 Fabric8

Fabric8是一個(gè)基于Docker、Kubernetes和Jenkins的開(kāi)源微服務(wù)平臺(tái)。通過(guò)Continuous Delivery管道可以很方便地創(chuàng)建、編譯、部署和測(cè)試微服務(wù)，并且通過(guò)Continuous Improvement和ChatOps可以對(duì)這些微服務(wù)進(jìn)行運(yùn)行和管理[15]。

在該項(xiàng)目中，會(huì)通過(guò)Fabric8調(diào)用Kubernetes的功能接口，使用Java語(yǔ)言實(shí)現(xiàn)可視化界面中后端接口的開(kāi)發(fā)。

1.3 React

React是一個(gè)用于構(gòu)建頁(yè)面UI的庫(kù)，它以組件化的思想開(kāi)發(fā)網(wǎng)站。開(kāi)發(fā)者從功能的角度出發(fā)，把UI拆分為不同的組件，各組件只負(fù)責(zé)自己部分的UI和邏輯，彼此互相獨(dú)立，不同的組件可通過(guò)組合或嵌套的方式和其他組件一起使用[16]。

該文通過(guò)React技術(shù)，將Kubernetes中每個(gè)應(yīng)用拆分為各個(gè)組件?？梢栽诓藛螜谥?，選擇想要操作的功能，進(jìn)入相應(yīng)的組件。通過(guò)各個(gè)功能的結(jié)合，可以達(dá)到在網(wǎng)頁(yè)中，直接操作Kubernetes的目的。

2 平臺(tái)設(shè)計(jì)

2.1 總體設(shè)計(jì)

Kubernetes容器云管理平臺(tái)分為四層架構(gòu)(見(jiàn)圖2)，分別為：資源層、容器層、平臺(tái)層和管理層。

圖2 層次架構(gòu)

資源層是平臺(tái)的最下面一層，它為容器層提供容器鏡像和一些系統(tǒng)配置文件。研發(fā)人員可以直接對(duì)其進(jìn)行修改配置，也可以通過(guò)管理層中的應(yīng)用對(duì)其進(jìn)行管理。

容器層是Kubernetes集成平臺(tái)的基礎(chǔ)，由開(kāi)發(fā)人員自身創(chuàng)建的私有鏡像庫(kù)提供?？梢愿鶕?jù)實(shí)際需求，自由組裝平臺(tái)需要的運(yùn)行環(huán)境。

平臺(tái)層是系統(tǒng)的核心，其他各層都是為其服務(wù)或者對(duì)其進(jìn)行配置。其中最重要的是Docker和Kubernetes這兩個(gè)組件。Docker為容器提供了運(yùn)行環(huán)境，Kubernetes則負(fù)責(zé)統(tǒng)一編排和調(diào)度Docker。

管理層主要是配置平臺(tái)層中的應(yīng)用，InfluDB加上Grafana可以對(duì)平臺(tái)的狀態(tài)進(jìn)行監(jiān)控，而Harbor會(huì)被用來(lái)管理私有鏡像庫(kù)。

2.2 平臺(tái)架構(gòu)描述

使用React作為前端開(kāi)發(fā)框架，使用Axios用于前后端接口的交互，并且使用React生態(tài)圈的新特性React Hook進(jìn)行開(kāi)發(fā)。借助React Hook可以把所有的組件都定義為函數(shù)，而不使用原來(lái)繼承類的形式，這樣可以使得組件的復(fù)用性得到很大的增強(qiáng)。

借助React Router來(lái)保持UI與URL間的同步，并且使得向應(yīng)用中添加視圖和數(shù)據(jù)流更加便捷。Axios向后端端口請(qǐng)求到的數(shù)據(jù)，會(huì)在頁(yè)面跳轉(zhuǎn)后，被渲染到對(duì)應(yīng)的UI組件中。

項(xiàng)目后臺(tái)由Spring和Spring Boot框架開(kāi)發(fā)而成(見(jiàn)圖3)，該層使用RequestMapping來(lái)完成請(qǐng)求地址的映射，使用框架Fabric8完成與云集成平臺(tái)的交互，從而可以通過(guò)前端頁(yè)面來(lái)完成對(duì)于Kubernetes集成平臺(tái)的管理。

圖3 前端各框架的關(guān)聯(lián)

2.3 功能模塊描述

平臺(tái)主要是為了使得原本的命令行管理方式，變得所見(jiàn)即所得。所以要把原本的功能，通過(guò)頁(yè)面的形式給復(fù)現(xiàn)出來(lái)。如圖4所示，主要包括以下幾種功能：

圖4 功能模塊

(1)物理節(jié)點(diǎn)。

需要知道部署在云平臺(tái)上的主機(jī)節(jié)點(diǎn)和從屬節(jié)點(diǎn)的IP地址。

(2)命名空間。

為了解決在集群下管理對(duì)象時(shí)的復(fù)雜性問(wèn)題，Kubernetes使用命名空間的概念。實(shí)際使用的時(shí)候，需要做到查看和創(chuàng)建命名空間的功能。

(3)Service管理。

Service是Kubernetes中的核心資源對(duì)象，它將運(yùn)行在一組Pods上的應(yīng)用程序公開(kāi)為網(wǎng)絡(luò)服務(wù)的抽象方法。所以，既要獲取所有的Service服務(wù)名稱，也要知道每個(gè)Service下的具體信息。并且，也需要根據(jù)需求，添加或刪除相應(yīng)的Service。

(4)Replication Controller管理。

RC(Replication Controller)的主要作用是：確保容器應(yīng)用的副本數(shù)，始終保持在用戶定義的數(shù)量。它可以根據(jù)情況，創(chuàng)建或回收Pod。在該模塊中，要實(shí)現(xiàn)對(duì)于所有RC的查詢，并且可以查詢每個(gè)RC的詳細(xì)信息。除此之外，還可以根據(jù)需要，手動(dòng)增加或刪除相應(yīng)的RC，也可以設(shè)置容器應(yīng)用中的副本數(shù)。

(5)Pod節(jié)點(diǎn)操作。

Pod是Kubernetes中能夠創(chuàng)建和部署的最小單位，里面包含一個(gè)或多個(gè)容器。所以，需要清楚地知道里面的各種屬性。

(6)中間件。

這里的中間件，主要是實(shí)現(xiàn)了對(duì)于MyCat的配置和查詢?？梢酝ㄟ^(guò)前端頁(yè)面，直接配置相應(yīng)的MyCat文件，而不需要在服務(wù)器端進(jìn)行配置。

(7)資源監(jiān)控。

該功能采用InfluDB(時(shí)序數(shù)據(jù)庫(kù))加上Grafana的形式。InfluDB是一種開(kāi)源分布式時(shí)序、時(shí)間和指標(biāo)數(shù)據(jù)庫(kù)，可以按照時(shí)間維度索引數(shù)據(jù)。Grafana是一款美觀、強(qiáng)大的可視化監(jiān)控指標(biāo)展示工具，可以很好地展示InfluDB監(jiān)控到的數(shù)據(jù)。通過(guò)InfluDB將Kubernetes集群平臺(tái)的資源使用情況記錄下來(lái)，再通過(guò)Grafana進(jìn)行圖形化展示，可以很好地監(jiān)控集群平臺(tái)的狀態(tài)。

(8)鏡像管理。

使用Harbor作為Docker私有鏡像倉(cāng)庫(kù)。Harbor提供了友好的Web UI界面，也可以進(jìn)行用戶權(quán)限管理等功能。將Harbor集成到該平臺(tái)之中，可以很方便地對(duì)鏡像進(jìn)行操作。

(9)日志模塊。

平臺(tái)中的日志模塊，主要實(shí)現(xiàn)了對(duì)于操作的記錄，以方便日后的還原和查詢。與此同時(shí)，也包含一些配置文件的讀取和操作。

3 實(shí)現(xiàn)細(xì)節(jié)

3.1 前端組件實(shí)現(xiàn)

前端組件的組合，得益于React Router的作用。React Router使得組件之間可以借助統(tǒng)一資源定位符，完成嵌套和地址的映射。這些組件中，有負(fù)責(zé)導(dǎo)航的類，比如：NsIndex、AdminIndex、ServiceIndex等。也有負(fù)責(zé)添加、刪除、展示的類，比如：NodeShow、ServiceShow、AddService等。它們借助于React Hook中的生命周期函數(shù)和Axios框架，可以實(shí)現(xiàn)與后端程序的交互。

3.2 后臺(tái)端口實(shí)現(xiàn)

后臺(tái)通過(guò)RequestMapping完成請(qǐng)求地址的映射，前臺(tái)的請(qǐng)求會(huì)首先在自身創(chuàng)建的SysGeneratorControlle類中進(jìn)行處理，然后調(diào)用對(duì)應(yīng)的業(yè)務(wù)邏輯類。在進(jìn)行業(yè)務(wù)邏輯處理的時(shí)候，會(huì)使用到一些自定義的類，比如：nodeSelf、podSelf、serviceSelf，這些類全部繼承自Fabric8框架中的原有類。該文在原來(lái)的基礎(chǔ)上，定義了一些公共方法，來(lái)完成一些特定的功能，比如：選擇性展示、添加、刪除、搜索等。

4 結(jié)束語(yǔ)

主要闡述了Kubernetes可視化管理平臺(tái)的構(gòu)建方式。主要是通過(guò)React框架來(lái)完成前臺(tái)頁(yè)面的渲染，通過(guò)Fabric8進(jìn)行Kubernetes接口的調(diào)用，通過(guò)Axios框架實(shí)現(xiàn)前后端數(shù)據(jù)的交互。相比于通過(guò)指令控制的方式，這種方式更加簡(jiǎn)便，對(duì)操作人員的要求也更低。

該文構(gòu)建的可視化管理界面，實(shí)現(xiàn)了一些核心功能，但也存在著一些不足和缺漏。在此基礎(chǔ)上，可以進(jìn)一步完成功能上的開(kāi)發(fā)，也可以進(jìn)行安全上的完善。