一種基于容器編排技術(shù)的資源運(yùn)維系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

張勛，張呈宇，魏進(jìn)武

?

一種基于容器編排技術(shù)的資源運(yùn)維系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

張勛，張呈宇，魏進(jìn)武

（中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院大數(shù)據(jù)研究中心，北京 100176）

容器運(yùn)行、容器編排、框架編排是構(gòu)建容器運(yùn)維系統(tǒng)的核心功能。容器資源運(yùn)維系統(tǒng)的工作原理是運(yùn)用Mesos進(jìn)行資源調(diào)度、運(yùn)用Kubernetes進(jìn)行容器編排、運(yùn)用Marathon技術(shù)進(jìn)行框架管理。這3種技術(shù)在容器運(yùn)維中相互關(guān)聯(lián)、相互銜接，使得系統(tǒng)內(nèi)部機(jī)制正常運(yùn)轉(zhuǎn)。深入闡述了這3項(xiàng)技術(shù)是如何應(yīng)用到實(shí)際系統(tǒng)構(gòu)建中的，給了設(shè)計(jì)的組合架構(gòu)及改進(jìn)技術(shù)難點(diǎn)，以解決中國聯(lián)通現(xiàn)有業(yè)務(wù)應(yīng)用容器化之后資源調(diào)度不平衡的問題、現(xiàn)有物理集群彈性擴(kuò)/縮容的問題以及實(shí)際業(yè)務(wù)部署統(tǒng)一運(yùn)營的問題，從而實(shí)現(xiàn)容器運(yùn)維管理系統(tǒng)的建設(shè)。

資源運(yùn)維系統(tǒng)；容器調(diào)度；彈性擴(kuò)/縮容

1 引言

目前中國聯(lián)合網(wǎng)絡(luò)通信公司（以下簡稱聯(lián)通）采用的以VMware虛擬機(jī)為主的虛擬化技術(shù)，并不能滿足現(xiàn)有通信領(lǐng)域，實(shí)際業(yè)務(wù)應(yīng)用使用容器技術(shù)進(jìn)行虛擬化擴(kuò)/縮容的要求；并且聯(lián)通現(xiàn)有大數(shù)據(jù)集群，是以Hadoop為主的傳統(tǒng)固定集群模式，擴(kuò)/縮容需要依靠人工添加實(shí)際物理機(jī)的模式，重新安裝集群，人員、硬件成本開銷較大。而現(xiàn)有開源技術(shù)中，Kubernetes可以很好地解決使用Docker虛擬化技術(shù)之后容器的生命周期問題，以及實(shí)際業(yè)務(wù)應(yīng)用容器化技術(shù)之后快速擴(kuò)/縮容的問題。而Mesos可以解決Hadoop集群自動化擴(kuò)/縮容的問題。因此中國聯(lián)通研究院建設(shè)CU-DCOS容器運(yùn)維系統(tǒng)，結(jié)合現(xiàn)有開源技術(shù)解決上述兩項(xiàng)生產(chǎn)環(huán)境的固有問題。研究開源技術(shù)與聯(lián)通現(xiàn)有環(huán)境集成的容器資源運(yùn)維系統(tǒng)的實(shí)現(xiàn)。

2 現(xiàn)有容器應(yīng)用運(yùn)維的問題

中國聯(lián)通目前的IT系統(tǒng)能夠滿足生產(chǎn)供給和部署，但在實(shí)際運(yùn)維中卻十分依賴第三方廠商的協(xié)助，仍舊是每個業(yè)務(wù)一個團(tuán)隊(duì)的“作坊”模式。每年的人力維護(hù)成本十分巨大，且效率較低。隨著中國聯(lián)通承載的實(shí)際業(yè)務(wù)越來越多，不同業(yè)務(wù)應(yīng)用團(tuán)隊(duì)之間主機(jī)資源不平衡程度加劇，擴(kuò)/縮容能力較低，嚴(yán)重影響了生產(chǎn)環(huán)境的穩(wěn)定性和頑健性，如圖1和圖2所示。目前的各個業(yè)務(wù)系統(tǒng)運(yùn)營存在資源運(yùn)行不均衡、時(shí)段運(yùn)行不均衡等重大問題，主要體現(xiàn)在以下幾點(diǎn)：

圖1 不同作業(yè)的內(nèi)存分時(shí)段使用率統(tǒng)計(jì)

圖2 不同作業(yè)的CPU分段使用率統(tǒng)計(jì)

?集群分布在多個機(jī)房，業(yè)務(wù)增長過快導(dǎo)致頻繁的數(shù)據(jù)遷移，針對性的平臺性能優(yōu)化不足；

??因GP故障、生產(chǎn)性能不足等問題，自2015年至今經(jīng)歷多次數(shù)據(jù)遷移，存儲資源不足及必要的數(shù)據(jù)留存周期造成無法針對性做進(jìn)一步優(yōu)化；

?HBase庫在數(shù)據(jù)量增大后，讀的概率下降，查詢效率會逐步降低，需要持續(xù)優(yōu)化保障，其他業(yè)務(wù)需求增多，與核心生產(chǎn)服務(wù)資源征用情況相比較明顯，直接影響到cBSS原始明細(xì)下發(fā)、對外實(shí)時(shí)查詢等服務(wù)；

??單個業(yè)務(wù)團(tuán)隊(duì)運(yùn)維人員投入急劇增加，尤其需要增加實(shí)際業(yè)務(wù)自動化運(yùn)維監(jiān)控功能，落地自動化運(yùn)維監(jiān)控平臺，減少人員運(yùn)維成本；

??如圖1、圖2所示，如果能將不同主機(jī)的主機(jī)資源共享，將大大提高主機(jī)資源的使用率。生產(chǎn)系統(tǒng)中，每一個計(jì)算集群都部署在專門的物理機(jī)中，計(jì)算任務(wù)完成后，則會閑置，而其他的計(jì)算集群也無法使用該主機(jī)資源。原有的技術(shù)結(jié)構(gòu)存在的問題是缺乏純物理機(jī)資源的粗、細(xì)顆粒度的調(diào)度能力。

本文研究填補(bǔ)了中國聯(lián)通沒有統(tǒng)一的容器化資源運(yùn)維平臺的空白，讓實(shí)際業(yè)務(wù)應(yīng)用在無狀態(tài)化、容器化之后，統(tǒng)一管理業(yè)務(wù)應(yīng)用的生命周期。打通現(xiàn)有運(yùn)維模式，統(tǒng)一運(yùn)維所有的業(yè)務(wù)應(yīng)用資源，使現(xiàn)有的開源技術(shù)有機(jī)地和聯(lián)通傳統(tǒng)業(yè)務(wù)相結(jié)合。

3 國內(nèi)研究現(xiàn)狀

網(wǎng)狀網(wǎng)作為整個一級業(yè)務(wù)支撐系統(tǒng)的核心系統(tǒng)，是中國移動內(nèi)外部信息傳輸交換、服務(wù)管控、數(shù)據(jù)處理、業(yè)務(wù)支撐、運(yùn)營開放為一體的綜合信息交換樞紐。目前承載200多個平臺的接入，支撐業(yè)務(wù)達(dá)到2 000多個，系統(tǒng)承載業(yè)務(wù)具有容量大、實(shí)時(shí)性強(qiáng)、波動劇烈、增長迅速、重要性強(qiáng)、客戶影響大、無狀態(tài)業(yè)務(wù)居多等特點(diǎn)，非常適合做PaaS平臺的試點(diǎn)。業(yè)務(wù)支撐中心和網(wǎng)狀網(wǎng)項(xiàng)目技術(shù)團(tuán)隊(duì)經(jīng)過大量的研討，創(chuàng)新性地提出了應(yīng)用進(jìn)程單元（application process unit，APU）的概念，把資源和應(yīng)用有效地結(jié)合在一起，解決未來系統(tǒng)發(fā)展和管理的瓶頸。而且通過深入的技術(shù)研究和實(shí)踐探索，在Docker基礎(chǔ)上通過增強(qiáng)接口和管理功能，實(shí)現(xiàn)了APU概念的落地。結(jié)合Kunbernetes作為集群管理平臺，搭建了能夠承載網(wǎng)狀網(wǎng)系統(tǒng)的PaaS平臺試點(diǎn)，實(shí)現(xiàn)了整個平臺的容器化改造和集群的部署、管理和監(jiān)控。

4 容器運(yùn)維系統(tǒng)的設(shè)計(jì)

4.1 功能架構(gòu)及其設(shè)計(jì)思路

一般地，較設(shè)計(jì)需求來說，容器運(yùn)維系統(tǒng)是面向生產(chǎn)系統(tǒng)各應(yīng)用提供大數(shù)據(jù)微服務(wù)化能力管理、調(diào)度和開放化運(yùn)營的管理框架，并面向不同的業(yè)務(wù)部門和信息域的需求，實(shí)現(xiàn)多租戶管理的能力開放。因此在設(shè)計(jì)容器運(yùn)維系統(tǒng)的功能時(shí)，需要綜合考量。核心的必要功能羅列如下。

（1）容器管理

需包括整個容器的生命周期管理，即容器服務(wù)的部署創(chuàng)建、容器服務(wù)配置的修改管理、容器服務(wù)的銷毀、容器服務(wù)的應(yīng)用監(jiān)控。為適應(yīng)不同的用戶，還應(yīng)具備服務(wù)訪問的權(quán)限[1]。如管理員可以訪問所有的容器實(shí)例，而單個用戶只能訪問自己創(chuàng)建或者同組之間賦予權(quán)限的容器實(shí)例。各個分組之間應(yīng)是完全物理隔離或邏輯隔離的[2]。

（2）框架管理

也需包括整個框架的生命周期管理，即框架服務(wù)的部署與創(chuàng)建、框架服務(wù)配置的修改管理、框架服務(wù)的銷毀、框架服務(wù)的監(jiān)控。需要與容器有所區(qū)分的是，框架相對容器的生命周期較長，且一般都是相對復(fù)雜的應(yīng)用，交付方式也不單是網(wǎng)址端口如此簡單明確。很多業(yè)務(wù)場景下，如Hadoop的能力，其創(chuàng)建不應(yīng)由用戶自行創(chuàng)建，更多的業(yè)務(wù)場景則是用戶來發(fā)起工單、申請能力、管理員開通、交付使用。所以框架的生命周期管理應(yīng)由管理員掌控[3]。

（3）集群管理

相對地，也需要包括集群的全生命周期管理，如集群的創(chuàng)建、集群節(jié)點(diǎn)數(shù)量等服務(wù)配置的修改管理、集群的銷毀與監(jiān)控[4]。

其次需要包括完整的工單系統(tǒng)，包括用戶和管理員這兩個基本權(quán)限角色，同時(shí)為了管理更有序，還需要對用戶進(jìn)行分組，實(shí)現(xiàn)組間、組內(nèi)多租戶更細(xì)化地分配資源。作為工單系統(tǒng)，角色的注冊和權(quán)限管理也是必不可少的。另外還需要對已有的軟件資源（物理機(jī)、框架、鏡像）設(shè)計(jì)相對應(yīng)的管理功能。

?鏡像倉庫：鏡像的添加或刪除。

??框架倉庫：框架的添加或刪除。

??物理機(jī)資源：資源納管，將物理機(jī)納入策略設(shè)置[5]。

圖3 容器運(yùn)維系統(tǒng)功能

除了以上的核心功能，還需根據(jù)實(shí)際業(yè)務(wù)情況設(shè)計(jì)針對性的進(jìn)階功能，如針對快速迭代的DevOps管理、容器存儲的持久化、一鍵部署所需的應(yīng)用包功能。經(jīng)過功能梳理后，容器運(yùn)維系統(tǒng)的功能如圖3所示。

4.2 容器運(yùn)維系統(tǒng)的技術(shù)路線

經(jīng)過前期的技術(shù)選型通過集成已有的開源軟件技術(shù)可以完成以下功能的搭建。

? DCOS：集群生命周期管理、框架倉庫、物理機(jī)資源納管。

? Kubernetes: 容器生命周期管理、租戶管理。

? ? Mesos：資源調(diào)度。

? Marathon：框架生命周期管理。

? Harbor：鏡像庫管理。

? ? Nginx&Flannel：服務(wù)注冊、負(fù)載均衡、訪問鑒權(quán)。

? ? Helm：應(yīng)用分組管理。

? ? Ceph：容器持久化存儲。

? ? Jenkins：DevOps迭代開發(fā)。

? ? Heapster&&EFK：監(jiān)控容器運(yùn)行情況并輸出監(jiān)控日志。

容器資源運(yùn)維系統(tǒng)使用DCOS+Marathon+ Kubernetes 的架構(gòu)模式（如圖4所示），完成集群、框架、容器三大維度生命周期的管理。容器資源運(yùn)維系統(tǒng)從技術(shù)架構(gòu)上分為接入層、服務(wù)層、框架調(diào)度層和前臺的管理系統(tǒng)[6]。

? 接入層：負(fù)責(zé)服務(wù)發(fā)現(xiàn)和服務(wù)路由，把每個容器業(yè)務(wù)應(yīng)用串聯(lián)起來。

? 服務(wù)層：應(yīng)用Helm技術(shù)，把每個用戶自定義的容器配置保存起來打包，以便二次部署；基于Jenkins技術(shù)，在線編譯程序，快速構(gòu)建驗(yàn)證與開發(fā)環(huán)境，實(shí)現(xiàn)應(yīng)用的容器化封裝。

? 框架調(diào)度層：應(yīng)用Heapster，實(shí)現(xiàn)容器的健康度實(shí)時(shí)監(jiān)控；EFK完成系統(tǒng)日志層面的搜索、輸出、展示；Kubernetes完成容器的生命周期管理；Marathon完成框架的生命周期管理；Mesos提供這兩個模塊的資源調(diào)度。

圖4 系統(tǒng)技術(shù)架構(gòu)

圖5 Hadoop集群資源調(diào)度實(shí)例

? 前臺管理：用Java編寫前臺的客戶端，調(diào)用現(xiàn)有技術(shù)的API，實(shí)現(xiàn)所有技術(shù)的調(diào)用。

5 關(guān)鍵問題技術(shù)Mesos

5.1 Mesos的資源調(diào)度改進(jìn)設(shè)計(jì)

容器資源運(yùn)維系統(tǒng)針對主流的Hadoop系列大數(shù)據(jù)應(yīng)用，采用兩級調(diào)度策略，由Mesos發(fā)起資源分配，實(shí)際的應(yīng)用框架消費(fèi)資源，合理化使用物理機(jī)資源，如圖5所示，做到資源空閑時(shí)，大數(shù)據(jù)應(yīng)用集群搶占系統(tǒng)資源；資源緊張時(shí)，大數(shù)據(jù)應(yīng)用自動釋放資源，并且不影響實(shí)際業(yè)務(wù)使用。這其中包括改進(jìn)的Mesos資源配置機(jī)制，如圖6所示。

圖6 Mesos資源機(jī)制

? 預(yù)留資源：由特定框架或角色靜態(tài)或動態(tài)聲明的資源，包括一些已分配的資源。

? 已分配資源：已提供給框架或由框架接受并作為執(zhí)行程序/任務(wù)提供的資源。

? 可撤銷資源：可以由分配器或代理在任何時(shí)間/短期通知回收的資源以及這些資源上的容器將被銷毀?？沙蜂N資源可以由分配器和代理使用超額預(yù)訂生成。在代理使用超額預(yù)訂的上下文中，“可撤銷”的含義還包括容器可能經(jīng)歷節(jié)流的東西（例如較低的CPU份額、較少的網(wǎng)絡(luò)優(yōu)先級等）[7]。

5.2 Mesos的任務(wù)機(jī)制改進(jìn)設(shè)計(jì)

? 正常任務(wù)：在不可撤銷資源上運(yùn)行的任務(wù)，與AWS保留實(shí)例相同。

? 可撤銷任務(wù)：低優(yōu)先級和易碎的任務(wù)，如AWS spot實(shí)例。

? Lender框架：一個運(yùn)行正常任務(wù)并保留資源的框架，這個框架可能沒有充分利用那些保留的資源，這就像目前存在的任何框架。

? Tenant框架：一種運(yùn)行可撤銷任務(wù)并利用Lender框架中的資源的框架的新范例。這種類型的框架可以處理不穩(wěn)定/笨拙的資源和更高的任務(wù)故障率。租戶框架需要具有啟用“REVOCABLE_RESOURCES”的能力。

如圖7、圖8所示，Lender框架決定使用其保留的資源時(shí)，使用來自分配器所提供的資源來啟動任務(wù)。如果任務(wù)不適合當(dāng)前可用的資源，則代理首先通過殺死正在使用可撤銷的不可節(jié)制的資源的執(zhí)行器來驅(qū)逐一些任務(wù)[8]。這可以由預(yù)訂超額預(yù)訂和動態(tài)預(yù)留之間的交互觸發(fā)。在框架或操作者移除一些保留的資源之后，同時(shí)由“被移除的保留資源”所生成的“可撤銷非節(jié)流資源”正由任務(wù)/執(zhí)行器使用，則可撤銷的不可節(jié)制資源總量也將在代理上減少[9]。

圖7 驅(qū)逐保留資源任務(wù)

圖8 驅(qū)逐正常資源任務(wù)

6 結(jié)果驗(yàn)證

本文以CentOS 7為驗(yàn)證環(huán)境，驗(yàn)證了主機(jī)10.1.24.108、10.1.24.39、10.1.24.137、10.1.24.234這4臺x86機(jī)架服務(wù)器，集成Docker（1.11）、Hadoop2.7、Kubernetes1.5、Open DCOS 1.05、Mesos 1.0.0等開源軟件設(shè)計(jì)實(shí)現(xiàn)容器運(yùn)維系統(tǒng)。

（1）資源調(diào)度驗(yàn)證

由于設(shè)計(jì)方案側(cè)重大數(shù)據(jù)的資源調(diào)度。為了對比容器運(yùn)維系統(tǒng)與Open DCOS兩個調(diào)度大數(shù)據(jù)資源的方法，采用實(shí)際驗(yàn)證法對兩個方法進(jìn)行了驗(yàn)證。結(jié)果如下。

首先，驗(yàn)證了兩個系統(tǒng)對于Myriad框架對細(xì)粒度資源的支持。目的是驗(yàn)證Myriad框架對執(zhí)行任務(wù)時(shí)，按照細(xì)粒度模式申請資源，任務(wù)運(yùn)行時(shí)資源的利用情況。

實(shí)際驗(yàn)證結(jié)果如下。

Open DCOS：細(xì)粒度執(zhí)行時(shí)間為165.476 s，固定模塊執(zhí)行時(shí)間為147.648 s。

CU-DCOS容器運(yùn)維系統(tǒng)：細(xì)粒度執(zhí)行時(shí)間為164.693 s，固定模塊執(zhí)行時(shí)間為144.976 s。

通過驗(yàn)證發(fā)現(xiàn)，在資源模板配置零的情況下，計(jì)算任務(wù)的時(shí)間比固定資源配置要長一些，且兩種方法都支持Myriad框架對細(xì)粒度資源進(jìn)行調(diào)度。

其次，驗(yàn)證了兩個系統(tǒng)對于資源預(yù)留功能方面的功能實(shí)現(xiàn)。目的是驗(yàn)證Myriad的基礎(chǔ)資源預(yù)留功能以及在這個基礎(chǔ)上的附加功能，包括動態(tài)資源預(yù)留、資源搶占等。

在Mesos-slave機(jī)器上配置資源選項(xiàng)做配置，為CPU、內(nèi)存、角色等進(jìn)行資源靜態(tài)預(yù)留。在Myriad框架上，調(diào)用容器運(yùn)維系統(tǒng)新增的RESTful接口發(fā)起動態(tài)預(yù)留信息，將資源等配置資源到固定機(jī)器上。

實(shí)際驗(yàn)證結(jié)果如下。

圖9 容器運(yùn)維系統(tǒng)資源監(jiān)控

圖10 集群1壓力較大時(shí)容器運(yùn)維系統(tǒng)資源監(jiān)控

Open DCOS和容器運(yùn)維系統(tǒng)均支持動態(tài)、靜態(tài)資源預(yù)留，Open DCOS對資源搶占功能不支持，但容器運(yùn)維系統(tǒng)對于資源搶占功能支持。集群資源搶占效果如圖9所示，圖9中集群1有2臺主機(jī)，集群2有2臺主機(jī)。當(dāng)集群1壓力較大時(shí)，會搶占集群2較為空閑的主機(jī)資源參與計(jì)算，如圖10所示。

（2）Mesos運(yùn)行模式驗(yàn)證

驗(yàn)證結(jié)果發(fā)現(xiàn)應(yīng)用框架方便實(shí)用，并且可以根據(jù)需要自行開發(fā)。容器化需要對應(yīng)用進(jìn)行無狀態(tài)改造工作。改造工作主要針對以下3個有狀態(tài)內(nèi)容：會話方面使用Redis緩存或Memcached；日志使用日志服務(wù)器Graylog；非日志數(shù)據(jù)文件通過外掛存儲的方式移至持久化存儲。

（3）基于Mesos的未容器化的應(yīng)用解決方案

驗(yàn)證結(jié)果發(fā)現(xiàn)部分業(yè)務(wù)暫時(shí)難以容器化改造的應(yīng)用，特點(diǎn)為：有狀態(tài)、體量大、自身封閉、難以微服務(wù)化，且無響應(yīng)應(yīng)用框架，如核心應(yīng)用、Oracle等。

基于Kubernetes的大顆粒度Docker容器：使用大顆粒度容器承載整個應(yīng)用。這樣便于部署和管理，可以提高資源利用率，持續(xù)集成（DevOps），且Docker占用資源極少。

使用Marathon支持的Mesos-容器。Mesos-容器比Docker更輕，只針對進(jìn)程用CGroup做CPU、內(nèi)存的隔離，不對文件系統(tǒng)、網(wǎng)絡(luò)等進(jìn)行限制。不需要使用鏡像啟動，直接運(yùn)行命令行啟動該容器。

（4）技術(shù)路線對比驗(yàn)證

Kubernetes相較于Marathon（見表1）有更好的潛力，在容器化調(diào)度方面，支持證書，支持容器的持久化卷等額外的擴(kuò)展功能，且在多集群和容災(zāi)方面都比Marathon有更好的安全性保證?？傮w來說，Kubernetes更適合容器的編排和調(diào)度。在Mesos方面需要使用開源技術(shù)和自行研發(fā)結(jié)合方式實(shí)現(xiàn)，其中對資源的統(tǒng)一管理和調(diào)度采用開源的Mesos來支撐，但缺乏框架的自動安裝部署和門戶等附加功能，需要在穩(wěn)定的Mesos版本上深度研發(fā)。

7 結(jié)束語

容器運(yùn)維系統(tǒng)旨在通過新一代的云計(jì)算架構(gòu)——容器技術(shù)，解決聯(lián)通面臨的實(shí)際問題。在解決問題過程中，依賴于開源軟件通過自主架構(gòu)、自主方案設(shè)計(jì)，部分核心能力自主研發(fā)；形成了面向生產(chǎn)環(huán)境下的IT系統(tǒng)，實(shí)現(xiàn)資源的一體化調(diào)度、大數(shù)據(jù)微服務(wù)化管理能力；完成IT資源的集中管理的新一代的私有云平臺系統(tǒng)。一方面驗(yàn)證了以容器為基礎(chǔ)的PaaS平臺從模式、到技術(shù)的可行性，另一方面在行業(yè)內(nèi)首次實(shí)現(xiàn)了面向大數(shù)據(jù)、物理資源彈性調(diào)度、多租戶管理的“資源+數(shù)據(jù)+能力”的平臺架構(gòu)。

表1 技術(shù)對比驗(yàn)證

[1] BAIER J. Getting started with Kubernetes[M]. Birmingham: Packt Publishing, 2015.

[2] BERNSTEIN D. Containers and cloud: from LXC to Docker to Kubernetes[J]. IEEE Cloud Computing, 2015, 1(3): 81-84.

[3] HINDMAN B, KONWINSKI A, ZAHARIA M, et al. Mesos: a platform for fine-grained resource sharing in the data center[C]// USENIX Conference on Networked Systems Design & Implementation, April 2-5, 2010, Lombard, IL, USA. New York: ACM Press, 2010: 429-483.

[4] 吳龍輝. Kubernetes第1版實(shí)戰(zhàn)[M].北京: 電子工業(yè)出版社, 2015: 13-211.

WU L H. Kubernetes application 1st ed[M]. Beijing: Electronic Industry Press, 2015: 13-211.

[5] SIERRA K, BATES B. O’Reilly: head first java(中文版)[M]. O’Reilly Taiwan譯. 北京: 中國電力出版社, 2007.

SIERRA K, BATES B. O’Reilly: head first Java[M]. Translated by O’Reilly Taiwan. Beijing: China Electric Power Press, 2007.

[6] KAKADIA D. Mesos 大數(shù)據(jù)資源調(diào)度與大規(guī)模容器運(yùn)行最佳實(shí)踐[M]. 崔婧雯, 劉夢馨, 譯. 北京: 電子工業(yè)出版社, 2015.

KAKADIA D. Applications on Mesos[M]. Translated by CUI J W, LIU M X. Beijing: Electronic Industry Press, 2015.

[7] 曹旭, 曹瑞彤. 基于大數(shù)據(jù)分析的網(wǎng)絡(luò)異常檢測方法[J]. 電信科學(xué), 2014, 30(6): 152-156.

CAO X, CAO R T. Network anomaly prediction method based on big data [J]. Telecommunications Science, 2014, 30(6): 152-156.

[8] 漆晨曦. 立足小數(shù)據(jù)基礎(chǔ)的電信企業(yè)大數(shù)據(jù)分析應(yīng)用發(fā)展策略[J]. 電信科學(xué), 2014, 30(10): 15-20.

QI C X. Analysis and application development strategy of telecom enterprise big data based on small data [J]. Telecommunications Science, 2014, 30(10): 15-20.

[9] 韓晶, 張智江, 王健全, 等. 面向統(tǒng)一運(yùn)營的電信運(yùn)營商大數(shù)據(jù)戰(zhàn)略[J]. 電信科學(xué), 2014, 30(11): 154-158.

HAN J, ZHANG Z J, WANG J Q, et al. The unified-operation-oriented big data strategy for telecom operators[J]. Telecommunications Science, 2014, 30(11): 154-158.

Design and implementation of a resource operation and maintenance system based on container arrangement technology

ZHANG Xun, ZHANG Chengyu, WEI Jinwu

Big Data Center of China Unicom Research Institute, Beijing 100176, China

Kubernetes container layout tools, Docker operation technology and Mesos framework choreography technology selection were used to solve China Unicom’s existing problems of business application container’s unbalance of resource scheduling. The problem of existing physical cluster elastic scalability capacity was solved. Through cluster and the technique of Mesos, the original big data deploy faster and the scalability problems were solved. Finally, container operation and management system was realized.

resource operation system, container scheduling, elastic scalability capacity

TN923

A

10.11959/j.issn.1000?0801.2018110

張勛（1990?），男，中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院大數(shù)據(jù)研究中心軟件開發(fā)工程師，主要研究方向?yàn)殚_源技術(shù)、容器技術(shù)等。

張呈宇（1988?），男，中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院大數(shù)據(jù)實(shí)驗(yàn)室大數(shù)據(jù)平臺技術(shù)研發(fā)組組長，主要從事大數(shù)據(jù)、云計(jì)算IaaS、容器技術(shù)等的研發(fā)工作。

魏進(jìn)武（1978?），男，博士，現(xiàn)就職于中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院大數(shù)據(jù)研究中心，主要負(fù)責(zé)大數(shù)據(jù)架構(gòu)設(shè)計(jì)、規(guī)劃、實(shí)施方案，統(tǒng)一云化研究等的研究工作。

2017?10?20；

2018?02?09