多云容器集群服務(wù)的設(shè)計與實現(xiàn)

謝冬鳴，黃 林，黃進軍，林 健

（東云睿連（武漢）計算技術(shù)有限公司，湖北武漢 430200）

0 引言

容器是近年來興起的一種應(yīng)用發(fā)布機制，其可為應(yīng)用提供可預(yù)測的執(zhí)行環(huán)境。當(dāng)越來越多的應(yīng)用采用容器進行開發(fā)和部署后，容器集群便成為必要需求。以Kuber?netes 為代表的容器集群平臺軟件可以自動化管理和調(diào)度由多個容器定義的應(yīng)用程序，使用戶以聲明的方式批量管理一組應(yīng)用，從而簡化業(yè)務(wù)的上線和運維。

企業(yè)運維一套穩(wěn)定的Kubernetes 容器集群并不輕松，通常需要專業(yè)的IT 人員管理包含虛擬機、存儲和網(wǎng)絡(luò)等資源在內(nèi)的基礎(chǔ)設(shè)施。面對這一問題，各個公有云廠商紛紛在云上提供可擴展、高性能的企業(yè)級云端Kubernetes 集群，即容器集群云服務(wù)。這些容器集群服務(wù)深度整合了各項基礎(chǔ)設(shè)施，使用多可用區(qū)容災(zāi)等技術(shù)構(gòu)建了高可用Kuber?netes 實例。借助云端容器集群服務(wù)，用戶可以方便快捷地創(chuàng)建和管理容器集群，從而更加專注于應(yīng)用的開發(fā)與運營，無需關(guān)注容器集群的運維。統(tǒng)計表明，大多數(shù)企業(yè)都使用了不止一家廠商提供的云服務(wù)［1］。業(yè)界普遍采用基于混合云的多云方案滿足信息安全、跨地區(qū)業(yè)務(wù)等需求，這些方案在支撐業(yè)務(wù)的同時也帶來了多云管理和接入的麻煩。此外，企業(yè)的應(yīng)用類型不盡相同，需要在云上部署不同的工作負載。云服務(wù)商在功能、性能方面亦各有優(yōu)劣［2］，使得多云環(huán)境下的容器集群服務(wù)選型和部署策略規(guī)劃成為企業(yè)面臨的重要問題。

1 容器集群適配面臨的問題

本文將多云環(huán)境下容器集群的適配問題歸納為宿主環(huán)境異構(gòu)性、多集群間網(wǎng)絡(luò)訪問約束以及容器負載多樣性三大類，以下分別闡述。

1.1 宿主環(huán)境異構(gòu)性

宿主環(huán)境異構(gòu)性問題與云服務(wù)商的基礎(chǔ)設(shè)施相關(guān)，涉及軟件接口和硬件設(shè)備等方面，以下列舉兩個典型要素。

（1）IaaS 服務(wù)接口差異化。由于各個云服務(wù)商的基礎(chǔ)設(shè)施實現(xiàn)有所差異，提供給用戶的IaaS 服務(wù)接口也不盡相同。這些接口可能格式不同，也可能概念不同。如果企業(yè)需要在多個云環(huán)境下使用容器集群，則必須對各個云服務(wù)商分別進行API級別的對接開發(fā)，工作內(nèi)容繁瑣且不易維護。

（2）計算器件多樣化。應(yīng)用的多樣性帶來了對算力的多元化需求，計算器件也正在從傳統(tǒng)的單一x86 架構(gòu)向x86+ARM+異構(gòu)加速器的復(fù)合架構(gòu)演化。當(dāng)企業(yè)需要構(gòu)建支持異構(gòu)體系的容器集群時，現(xiàn)有容器集群服務(wù)的問題便會凸顯。盡管Kubernetes 及其依賴的核心組件已經(jīng)提供了對多種CPU 及加速器架構(gòu)的支持，但其還需依賴很多第三方組件提供其他豐富的功能。這些組件的適配需要繁瑣的二次開發(fā)和編譯構(gòu)建等工作，特別是當(dāng)用戶需要使用GPU、InfiniBand 網(wǎng)卡等高性能設(shè)備時，將面臨宿主機驅(qū)動安裝、設(shè)備虛擬化、安全隔離配置等多種問題，工作量龐大且內(nèi)容復(fù)雜。

1.2 多集群間網(wǎng)絡(luò)訪問約束

當(dāng)企業(yè)實施多云環(huán)境下的多個容器集群時，集群間的網(wǎng)絡(luò)訪問受到很大約束，一方面存在私有云與公有云之間的網(wǎng)絡(luò)互通問題，另一方面多個云端集群之間也可能存在網(wǎng)絡(luò)訪問需求。

從可達性角度考量，國內(nèi)公有云服務(wù)商大多通過網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT）達到網(wǎng)絡(luò)間互通的目的。究其原因，當(dāng)前互聯(lián)網(wǎng)主要使用IPv4，但國內(nèi)可用的地址量十分有限。NAT 技術(shù)通過同一地址上不同的端口向不同私有地址進行映射，節(jié)省云服務(wù)商的公網(wǎng)地址。然而，使用NAT 會帶來端到端雙向連通性問題，限制了跨集群的數(shù)據(jù)互通。多云多集群間的訪問亦受到公網(wǎng)IP 的制約。目前公有云服務(wù)商普遍采用彈性IP 的方式提供云主機的公網(wǎng)入口，而彈性IP 普遍價格較高，配置一個典型企業(yè)應(yīng)用所需帶寬的彈性IP 每年動輒數(shù)萬，有時甚至達數(shù)十萬元。當(dāng)企業(yè)采用多云方案后，如果繼續(xù)通過彈性IP 實現(xiàn)網(wǎng)絡(luò)互通，費用將大幅增加。因此，尋求更經(jīng)濟的網(wǎng)絡(luò)訪問方式是企業(yè)采用多云服務(wù)時不得不考慮的問題。

1.3 容器負載多樣性

從業(yè)務(wù)特征方面考慮，云環(huán)境中的工作負載運行模式通常是多種多樣的，典型的兩種模式為微服務(wù)［3］和批處理作業(yè)。微服務(wù)的本質(zhì)為Web 或REST 服務(wù)，一般具有無狀態(tài)或以外部持久化方式存儲狀態(tài)的特征。理論上，該類負載的生命周期可以無限長。在云原生環(huán)境下，容器集群服務(wù)是管理和編排微服務(wù)的主要工具。微服務(wù)負載的調(diào)度策略一般涉及彈性伸縮、流量轉(zhuǎn)發(fā)、容錯恢復(fù)等，還依賴于服務(wù)發(fā)現(xiàn)等管理能力。批處理作業(yè)在運行時不僅帶有狀態(tài)，會在內(nèi)存中維護當(dāng)前運行信息，而且其生命周期往往取決于算法、算力等因素，一般為有限時長。批處理作業(yè)類負載除了生命周期與微服務(wù)模式有明顯區(qū)別外，在內(nèi)部調(diào)度策略上也存在巨大差異。微服務(wù)往往不涉及多個進程的協(xié)同工作，但批處理則不然，不僅不同作業(yè)間可能存在調(diào)度順序依賴，而且在作業(yè)內(nèi)部也可能存在多個任務(wù)協(xié)同工作，通常需要專業(yè)的調(diào)度框架完成［4］。

事實上，Kubernetes 最初是為微服務(wù)模式設(shè)計的，其主要功能和工作負載類型大多是匹配微服務(wù)的［5］。雖然其原生也支持批處理作業(yè)模式，但相關(guān)功能比較簡陋，無法滿足實際業(yè)務(wù)中各種復(fù)雜的調(diào)度需求，例如群調(diào)度。因此，如何使容器集群更好地支持微服務(wù)之外的工作負載成為亟需解決的問題。

2 相關(guān)解決方案

2.1 容器集群服務(wù)

容器技術(shù)的快速發(fā)展和廣泛應(yīng)用催生了容器集群編排軟件這一市場。以Kubernetes 為代表的容器集群軟件是現(xiàn)代企業(yè)開發(fā)和部署應(yīng)用的主流選擇，在此基礎(chǔ)上，各平臺軟件廠家和公有云服務(wù)商紛紛推出了自己的容器集群管理軟件和云容器集群服務(wù)［6-9］。依據(jù)服務(wù)形態(tài)維度，容器集群服務(wù)可分為公有云服務(wù)、私有云服務(wù)和混合云服務(wù)，典型代表如表1所示。

Table 1 Typical cloud services of container cluster表1 容器集群云服務(wù)典型代表

2.1.1 公有云服務(wù)

公有云服務(wù)通過互聯(lián)網(wǎng)面向公眾提供服務(wù)，主要滿足中小企業(yè)和長尾市場的需求。容器集群服務(wù)在公有云上一般處于PaaS 層，它們通常會面臨多租管理［10］、安全隔離、彈性伸縮、成本優(yōu)化等公有云服務(wù)的共性問題。

2.1.2 私有云服務(wù)

私有云服務(wù)通常部署在企業(yè)內(nèi)部，面向可信管理域，是大型企業(yè)的主流選擇。私有云服務(wù)的安全性要求一般低于公有云。然而，私有化容器集群通常受到可用資源的限制，有時具有接入外部容器集群、構(gòu)建混合容器云的需求。

2.1.3 混合云服務(wù)

混合云是指企業(yè)在私有云的基礎(chǔ)上，將部分業(yè)務(wù)運行在公有云之上的一種云服務(wù)形態(tài)。企業(yè)使用混合云服務(wù)既能彌補私有云資源的不足，也可以將核心數(shù)據(jù)資產(chǎn)保留在私有云中以保證安全性。然而，混合云的構(gòu)建通常需要更為復(fù)雜的技術(shù)手段和設(shè)施支撐。

通過調(diào)研和分析容器集群云服務(wù)發(fā)現(xiàn)，現(xiàn)有技術(shù)管理多個容器集群環(huán)境的能力大多比較薄弱，它們或者只能接入多個云環(huán)境中的容器集群，但不能創(chuàng)建和管理多云環(huán)境中容器集群的全生命周期；或者只能提供Kubernetes 原生集群的能力，但不能實現(xiàn)跨云互操作等高級能力［11］。

2.2 多云管理工具

高效管理多個云服務(wù)商的資源是一個復(fù)雜問題，當(dāng)前主流思路為基礎(chǔ)設(shè)施即代碼（Infrastructure as Code，IaC），即通過代碼方式和標(biāo)準化配置管理與維護基礎(chǔ)設(shè)施取代傳統(tǒng)的控制臺和圖形界面管理方式。目前業(yè)界主流的IaC工具包括Ansible、Pulumi 和Terraform 等，其中Terraform［12］是處于云服務(wù)商抽象之上的一個基礎(chǔ)設(shè)施自動化編排工具，其以配置文件為驅(qū)動，通過與平臺無關(guān)的DSL 語言定義和管理云基礎(chǔ)設(shè)施資源，如計算實例、網(wǎng)絡(luò)實例、存儲實例等。目前Terraform 已經(jīng)支持包含亞馬遜、阿里云、華為云等在內(nèi)的主流云服務(wù)商。雖然Terraform 提供了與云服務(wù)商無關(guān)的特性支持，但在執(zhí)行具體的云環(huán)境資源配置時仍需編寫與具體云環(huán)境適配的DSL 配置，且其基本操作方式為命令行，具有一定的技術(shù)門檻。此外，作為一款通用IaC 工具，Terraform 對容器集群領(lǐng)域的專業(yè)需求滿足度也較為不足。

3 OMCC云容器服務(wù)系統(tǒng)設(shè)計

針對容器集群服務(wù)適配多云環(huán)境時遇到的問題，本文提出OMCC（Oriental Mind Cloud Container）云容器服務(wù)系統(tǒng)，其是一套云原生、一站式的系統(tǒng)與應(yīng)用服務(wù)化平臺軟件。OMCC 的功能視圖如圖1 所示，其提供兼容多種公有云和私有云環(huán)境的容器集群管理等核心功能，支持負載管理和應(yīng)用網(wǎng)格管理等業(yè)務(wù)需求。軟件主體分為業(yè)務(wù)邏輯組件與資源管理組件兩部分，其中業(yè)務(wù)邏輯組件主要負責(zé)容器集群管理、容器負載管理以及應(yīng)用網(wǎng)格管理；資源管理組件主要負責(zé)多云環(huán)境下的資源管理以及集群側(cè)設(shè)備接入。

Fig.1 Functional view of OMCC圖1 OMCC功能視圖

以一套平臺軟件支持多云環(huán)境下容器集群的服務(wù)化管理，無差別地調(diào)度和編排不同的基礎(chǔ)設(shè)施及應(yīng)用業(yè)務(wù)，對用戶屏蔽環(huán)境差異，是OMCC 與同類產(chǎn)品在產(chǎn)品定位方面的主要區(qū)別。在技術(shù)路線方面，OMCC 通過自舉式容器集群管理機制，使用統(tǒng)一公共調(diào)度層抽象與集群驅(qū)動層適配解決了多云環(huán)境下的宿主環(huán)境異構(gòu)性問題；通過代理網(wǎng)關(guān)與內(nèi)網(wǎng)穿透機制解決了多云環(huán)境下多容器集群的互通問題；通過統(tǒng)一負載機制實現(xiàn)了在容器集群上同時部署微服務(wù)和批處理等不同類型工作負載的目標(biāo)。

4 OMCC關(guān)鍵技術(shù)

4.1 自舉式容器集群創(chuàng)建機制

OMCC 使用集群驅(qū)動層處理不同云環(huán)境的異構(gòu)性，以滿足對多云環(huán)境的擴展性需求。其采用自舉式容器集群創(chuàng)建機制，該機制是指集群驅(qū)動層組件自身的執(zhí)行過程作為OMCC 所在底座容器集群之上的普通作業(yè)執(zhí)行，通過邏輯自包含的容器作業(yè)完成對新容器集群的生命周期管理操作。自舉式容器集群全生命周期管理是OMCC對傳統(tǒng)容器集群服務(wù)的增強。在異構(gòu)多云環(huán)境中，傳統(tǒng)方案只能導(dǎo)入已經(jīng)創(chuàng)建的容器集群，而OMCC能透明創(chuàng)建并全程維護容器集群。

OMCC 集群管理邏輯的數(shù)據(jù)流圖如圖2 所示。在公共調(diào)度層，容器集群客戶端請求經(jīng)過邏輯中間件統(tǒng)一抽象后以高級配置語言的形式傳遞給資源中間件，隨后轉(zhuǎn)換為資源配置文件；在集群驅(qū)動層，解釋器對資源配置文件進行解釋，將其轉(zhuǎn)換為Terraform 的DSL 配置，最后傳遞給Terra?form 執(zhí)行。

Fig.2 Dataflow of cluster management logic in OMCC圖2 OMCC集群管理邏輯的數(shù)據(jù)流圖

4.1.1 公共調(diào)度層

以統(tǒng)一的抽象支持多云環(huán)境下容器集群的生命周期管理是OMCC 在云原生領(lǐng)域的特色之一。具體方案是在業(yè)務(wù)邏輯組件和資源管理組件之間插入抽象層，對容器集群的屬性和操作分別提供一致的數(shù)據(jù)結(jié)構(gòu)與接口。容器集群屬性對包含各種基礎(chǔ)設(shè)施在內(nèi)的容器集群云服務(wù)信息進行形式化描述，容器集群操作則負責(zé)集群服務(wù)生命周期的啟停等管理操作，兩者都能映射到不同云環(huán)境下的容器集群管理語義。

公共調(diào)度層的統(tǒng)一抽象解決的關(guān)鍵問題為容器集群對其依賴的基礎(chǔ)設(shè)施和特殊資源需求語義的表達，例如集群需要的節(jié)點資源規(guī)格、資源數(shù)量、存儲類型、網(wǎng)絡(luò)模型、高性能網(wǎng)絡(luò)設(shè)備等。OMCC 對資源需求語義進行結(jié)構(gòu)化分層管理，同時采用可擴展字段的方式兼顧特殊資源的需求。每種資源類型的功能實現(xiàn)由資源管理組件完成，對用戶和上層應(yīng)用高度透明，屏蔽了各云環(huán)境IaaS服務(wù)的接口差異。

4.1.2 集群驅(qū)動層

為將統(tǒng)一容器集群抽象翻譯為具體云環(huán)境下的容器集群管理語義，OMCC 在資源管理組件中針對主流公有云研發(fā)了各自的容器集群服務(wù)驅(qū)動層，以實現(xiàn)云環(huán)境中容器集群生命周期管理的具體操作。各驅(qū)動層基于Terraform工具實現(xiàn)，通過編排和擴展Terraform 生態(tài)中各公有云服務(wù)的適配插件，以DSL 語言格式配置各云環(huán)境中容器集群的資源需求，并適配各云環(huán)境計算器件的資源異構(gòu)性。OMCC 通過組織和編排不同驅(qū)動層配置，完成了多云環(huán)境下容器集群的創(chuàng)建、資源縮容與擴容、網(wǎng)絡(luò)配置、存儲配置、高性能設(shè)備接入等多維度容器集群管理能力。針對私有云環(huán)境，OMCC 也實現(xiàn)了以O(shè)penStack 為代表的私有云集群側(cè)驅(qū)動，通過在OpenStack 中部署Magnum［13］等少量社區(qū)開源組件，統(tǒng)一實現(xiàn)了基于Terraform 的集群側(cè)驅(qū)動。

4.1.3 自舉式實現(xiàn)

OMCC 使用Kubernetes 作為自身服務(wù)運行時的底座集群。在使用自舉式容器集群管理機制時，OMCC 以容器的形式在該底座集群上動態(tài)創(chuàng)建多個管理云環(huán)境容器集群的工作進程。這些容器實現(xiàn)了邏輯自包含，即涵蓋了在云環(huán)境上操作目標(biāo)容器集群的完整功能，而無需宿主環(huán)境中其他軟件的輔助。當(dāng)云環(huán)境中的目標(biāo)容器集群管理工作完成后，這些工作容器隨即被銷毀。

4.2 代理網(wǎng)關(guān)與內(nèi)網(wǎng)穿透機制

在私有云環(huán)境中管理和訪問多個公有云容器集群時，通常會涉及兩個問題：一是私有云如何與公有云環(huán)境網(wǎng)絡(luò)互通，二是容器集群外部流量如何進入容器集群內(nèi)部工作負載。OMCC 在這兩個方面都進行了相關(guān)探索與研究。

在私有云與公有云多容器集群網(wǎng)絡(luò)訪問方面，OMCC支持通過傳統(tǒng)的VPN 機制和自研的內(nèi)網(wǎng)穿透機制打通私有云和公有云容器集群。在VPN 模式下，用戶需要購買和部署公有云提供的VPN 服務(wù)。在采用內(nèi)網(wǎng)穿透機制時，只需要在公有云環(huán)境中部署OMCC 內(nèi)網(wǎng)穿透組件，無需VPN和彈性IP即可實現(xiàn)私有云與公有云環(huán)境的網(wǎng)絡(luò)通信。

原生Kubernetes 在處理集群外部網(wǎng)絡(luò)流量進入集群內(nèi)部的問題時，只提供了基于負載均衡服務(wù)的實現(xiàn)機制［14］，其實現(xiàn)通常由各云服務(wù)商提供。OMCC 研發(fā)了容器集群網(wǎng)關(guān)代理組件，該組件可以在沒有負載均衡服務(wù)的情況下將容器集群外部流量代理至容器集群內(nèi)部。網(wǎng)關(guān)代理組件為私有云環(huán)境下的容器集群提供了等同于公有云服務(wù)的流量接入能力，這是OMCC 有別于其他私有云容器集群服務(wù)的技術(shù)創(chuàng)新。

圖3 給出了連接多個云環(huán)境的組合方案示例，其中OMCC 通過VPN 和內(nèi)網(wǎng)穿透機制，配合網(wǎng)關(guān)代理組件，實現(xiàn)了與兩個云環(huán)境中Kubernetes容器集群工作負載的互通。

內(nèi)網(wǎng)穿透組件采用SSH（Secure Shell）反向隧道方式實現(xiàn)，以安全、可靠且輕量的方式滿足了多云容器集群網(wǎng)間訪問的可達性需求。網(wǎng)關(guān)代理組件由自研的負載組件和開源的Istio［15］兩部分實現(xiàn)，其中負載組件基于VIP（Virtual IP）［16］實現(xiàn)，以Kubernetes DaemonSet 工作負載的形式運行于集群的控制節(jié)點上，在云環(huán)境中通過ARP（Address Reso?lution Protocol）技術(shù)從二層網(wǎng)絡(luò)完成容器集群網(wǎng)絡(luò)的接入；負載組件提供了類似公有云負載均衡服務(wù)的功能，在保證高可用的同時將集群外流量導(dǎo)入容器集群。Istio 組件則提供了工作負載流量的代理和治理功能，為OMCC 提供了應(yīng)用網(wǎng)格的服務(wù)能力。

Fig.3 Example of a combination scheme for connecting multiple cloud environments圖3 連接多個云環(huán)境的組合方案示例

4.3 統(tǒng)一負載抽象機制

OMCC 將容器集群工作負載分為微服務(wù)和批處理兩種類型分別進行統(tǒng)一抽象，以滿足具有業(yè)務(wù)多樣性負載的部署需求［17］。以一致化的模型增加對批處理工作負載的支持是OMCC 對原生Kubernetes 容器集群的增強，也是其區(qū)別于業(yè)界傳統(tǒng)方案的創(chuàng)新。

4.3.1 微服務(wù)統(tǒng)一抽象

對于微服務(wù)類型的工作負載，OMCC 復(fù)用了Kuber?netes 自身的負載抽象和語義［18］。其通過Deployment 的抽象描述一個微服務(wù)的部署和副本，通過Service 的抽象描述服務(wù)發(fā)現(xiàn)和負載均衡。OMCC 還在Kubernetes 原生負載語義的基礎(chǔ)上進行了字段擴展，增加了對多集群、高性能硬件等特性的支持。

4.3.2 批處理統(tǒng)一抽象

對于批處理類型的工作負載，OMCC 在第三方方案［19］的基礎(chǔ)上設(shè)計了一套抽象語義進行描述，通過作業(yè)、任務(wù)、任務(wù)組和完成策略的抽象定義統(tǒng)一的批處理作業(yè)語義。在實現(xiàn)上，OMCC 研發(fā)了專有的批處理中間件，負責(zé)容器集群上的作業(yè)調(diào)度和資源分配。該機制能夠滿足多種常見分布式批處理作業(yè)的調(diào)度需求，包括但不限于人工智能領(lǐng)域的TensorFlow、PyTorch 等深度學(xué)習(xí)作業(yè)，以及大數(shù)據(jù)領(lǐng)域的Hadoop、Spark、Hive等數(shù)據(jù)分析處理作業(yè)。

以下代碼給出了OMCC使用JSON實現(xiàn)的批處理負載統(tǒng)一抽象示例，其中的關(guān)鍵字段為task_groups，用于表示在批處理場景下的任務(wù)組抽象。作業(yè)中包含以count字段定義的特定數(shù)量的任務(wù)，這些任務(wù)可以通過gpu_enabled、rdma_en?abled、command 等字段設(shè)置是否需要GPU、是否需要配置RDMA高性能網(wǎng)絡(luò)以及啟動命令等屬性。代碼具體表示為：

5 系統(tǒng)實現(xiàn)

5.1 軟件架構(gòu)

OMCC 軟件架構(gòu)遵循云原生理念設(shè)計，采用前后端分離模式，以Spring Cloud 分布式微服務(wù)框架為基礎(chǔ)，使用Spring Boot 為核心技術(shù)棧實現(xiàn)服務(wù)中間件，并基于Kuber?netes 生態(tài)組件構(gòu)建容器集群基礎(chǔ)環(huán)境。圖4展示了OMCC容器集群管理邏輯涉及的關(guān)鍵軟件架構(gòu)，以下就其中重點部分進行介紹。

Fig.4 Key software architecture of OMCC圖4 OMCC關(guān)鍵軟件架構(gòu)

OMCC 的關(guān)鍵組件包括一個自有容器集群、一個邏輯中間件、一個資源管理中間件和一組容器集群編排鏡像。

自有容器集群是用于運行OMCC 自身服務(wù)中間件和容器集群編排鏡像的基礎(chǔ)集群環(huán)境。OMCC 在開源版本Kubernetes 的基礎(chǔ)上，通過研發(fā)專有的CRD 資源和Opera?tor插件，實現(xiàn)了對云容器集群的原生控制功能。

邏輯中間件主要負責(zé)與客戶端的請求交互，其以REST API 的方式接收客戶端提交的容器集群管理請求，如創(chuàng)建與擴縮容器集群、部署工作負載等。在接收到請求后，經(jīng)過一系列解析與編排操作，將請求轉(zhuǎn)換為高級配置語言并傳遞給資源管理組件。

資源管理中間件的主要職責(zé)為管理目標(biāo)容器集群，其通過調(diào)度自有容器集群、運行自舉式容器完成工作。具體流程為：①解析收到的操作容器集群的高級配置語言，找出其中的配置參數(shù)和操作類型，匹配待操作的目標(biāo)環(huán)境與目標(biāo)資源類型；②從一組容器集群編排鏡像中匹配合適的鏡像，向自有容器集群請求調(diào)度運行該鏡像并傳遞配置參數(shù)，完成對目標(biāo)容器集群的操作。

OMCC 包含一組用于容器集群編排的Docker 鏡像，這些鏡像實現(xiàn)了不同云環(huán)境中容器集群生命周期管理的驅(qū)動適配。鏡像內(nèi)部的組件包括解釋器和執(zhí)行器兩部分，其中解釋器用于解釋資源管理中間件傳入的配置參數(shù)，將其轉(zhuǎn)換成目標(biāo)云環(huán)境的Terraform 資源描述文件；執(zhí)行器則是基于Terraform 的腳本程序，完成目標(biāo)云環(huán)境上的資源管理和容器集群操作。這種將不同云環(huán)境中的容器集群操作以容器化的方式動態(tài)地在自有集群上調(diào)度運行的方式應(yīng)用了自舉式工作機制，實現(xiàn)了容器集群管理與服務(wù)軟件架構(gòu)的解耦，方便未來擴展支持更多云環(huán)境。

5.2 關(guān)鍵特性

OMCC 除具有多云容器集群管理和多類型負載管理的核心功能外，還包含若干創(chuàng)新的關(guān)鍵特性。例如，OMCC基于Kubernetes 的Device Plugin［20］機制實現(xiàn)了高性能硬件支持。在GPU 方面，OMCC 通過研發(fā)增強型插件實現(xiàn)了GPU 復(fù)用等高級特性。相較于業(yè)界開源的、以顯存為資源選擇依據(jù)的GPU 共享插件［21］，OMCC 支持“毫GPU”等靈活易用的單位。在RDMA［22］網(wǎng)絡(luò)方面，OMCC實現(xiàn)了In?finiBand、RoCE 等高速網(wǎng)卡在容器集群下的虛擬化接入和安全隔離。

OMCC 還在X86 架構(gòu)之外實現(xiàn)了ARM 架構(gòu)支持。目前，OMCC 所有組件已針對華為鯤鵬等國產(chǎn)CPU 完成了適配并取得認證。宿主環(huán)境無關(guān)的自舉式機制還支持構(gòu)建具有異構(gòu)CPU 的多云環(huán)境。

在應(yīng)用層容器網(wǎng)格服務(wù)方面，OMCC為用戶提供了開箱即用的云原生應(yīng)用管理能力。用戶通過圖形化界面即可完成負載均衡策略管理、灰度發(fā)布、流量分發(fā)等服務(wù)治理操作。

6 系統(tǒng)評價

OMCC 的功能和性能已在生產(chǎn)環(huán)境中得到驗證，并形成了若干典型應(yīng)用案例。

6.1 性能測試

OMCC 性能測試涉及自身服務(wù)接口性能和大規(guī)模工作負載性能兩方面。測試結(jié)果表明，在不同數(shù)量級和并發(fā)壓力下，服務(wù)接口均能保持數(shù)毫秒至百毫秒級的響應(yīng)時間。這是由于OMCC 的工作負載實際是由各云環(huán)境中的容器集群負責(zé)，其負載能力不會因為OMCC的引入而下降。

圖5 展示了OMCC 服務(wù)的一組性能測試結(jié)果，測試以部署10 萬和100 萬大規(guī)模工作負載請求為場景（并發(fā)請求數(shù)為50），該場景能夠覆蓋絕大部分企業(yè)對應(yīng)用負載的部署需求。以創(chuàng)建批處理作業(yè)負載為例，OMCC 的異步調(diào)用響應(yīng)時間均能控制在200ms以內(nèi)。

6.2 應(yīng)用案例

OMCC 現(xiàn)已服務(wù)于多種應(yīng)用場景，并在多個客戶環(huán)境中得到成功應(yīng)用，以下以O(shè)MCC 支撐某上市公司的PaaS 應(yīng)用引擎服務(wù)為例進行介紹。

如圖6 所示，在該案例中，PaaS 應(yīng)用引擎服務(wù)通過OMCC 管理了應(yīng)用業(yè)務(wù)組件在不同云環(huán)境中部署的各種中間件，如MySQL、Redis 等。這些中間件以微服務(wù)的方式長期運行于不同地域和云服務(wù)商的云環(huán)境中。通過OMCC 的網(wǎng)絡(luò)訪問機制，企業(yè)本地的研發(fā)團隊能夠在內(nèi)部私有云環(huán)境中直接部署、管理、監(jiān)控和訪問多云容器集群上的工作負載。同時，OMCC 的應(yīng)用網(wǎng)格管理特性為中間件提供了自動負載均衡與灰度版本切換的能力。OMCC在本案例中實現(xiàn)了業(yè)務(wù)組件的統(tǒng)一集中管理以及中間件的高可用運行，顯著降低了客戶的運維成本。

Fig.5 Performance test results of OMCC圖5 OMCC性能測試結(jié)果

Fig.6 Implementation architecture of OMCC in a PaaS application engine service圖6 OMCC在某PaaS應(yīng)用引擎服務(wù)中的實施架構(gòu)

7 結(jié)語

容器技術(shù)是支撐現(xiàn)代云原生應(yīng)用的基石，在多云環(huán)境中實施容器集群服務(wù)是業(yè)界的新興趨勢。分析眾多現(xiàn)有平臺軟件可以發(fā)現(xiàn)，多云容器集群服務(wù)需要解決宿主環(huán)境異構(gòu)性、多集群間網(wǎng)絡(luò)訪問約束和容器負載多樣性等問題［23］。OMCC 是在分析以上問題的基礎(chǔ)上，面向一站式、高性能目標(biāo)設(shè)計和研發(fā)的多云容器集群服務(wù)軟件。其基于IaC 理念，屏蔽了多云環(huán)境中的底層細節(jié)［24］；基于自舉式容器集群創(chuàng)建機制解決了多云環(huán)境下IaaS 服務(wù)接口和計算器件異構(gòu)性問題，使得構(gòu)建帶有加速器和高性能網(wǎng)卡的異構(gòu)容器集群成為可能；基于代理網(wǎng)關(guān)與內(nèi)網(wǎng)穿透機制解決了多集群互通時的網(wǎng)絡(luò)可達性問題，有助于建設(shè)混合云容器環(huán)境，同時滿足了私有云環(huán)境下流量接入與負載均衡的需求；基于統(tǒng)一負載抽象機制在傳統(tǒng)容器集群中拓展了對批處理作業(yè)的支持，有利于以同一套資源支持微服務(wù)容器、大數(shù)據(jù)計算、人工智能訓(xùn)練等負載，實現(xiàn)資源利用率和管理效率的提升。OMCC 的性能測試和應(yīng)用案例亦證實了其可用性與實用性，其設(shè)計思路和工程實踐經(jīng)驗可為該領(lǐng)域的研發(fā)工作提供參考。