基于國產云基座的私有化容器云平臺構建研究

蘇奕豪

（中國鐵路蘭州局集團有限公司 科技和信息化部,蘭州 730000）

隨著云計算技術的發展,云平臺已經成為企業信息基礎設施的重要組成部分。云計算發展初期,以基礎設施即服務（IaaS,Infrastructure as a Service）模式為主的虛擬化技術有效解決了硬件層的資源共享與資源隔離等問題,但其承載應用的虛擬機操作系統占用了較多的宿主機硬件資源,增加了系統及應用的運營維護（簡稱：運維）、管理復雜度。

近年來,容器云平臺憑借其輕量化、高可用、遷移便利、彈性計算等優勢逐步成為助力企業發展及數字化變革的新興技術。翁湦元等人[1]提出可將原業務系統進行容器化改造后遷移至云平臺,以達到提高平臺靈活性、穩定性,降低運維成本的目的；田源等人[2]為了解決乘客信息系統應用軟件部署量大、部署效率低的問題,提出一種基于Docker 容器技術的軟件部署架構,為乘客信息系統的進一步云化提供了技術支撐；許孟豪等人[3]闡述了云邊架構下的應用協同架構,研究了基于容器的應用協同技術；郝曉培等人[4]提出了基于Kubernetes 容器的平臺即服務（PaaS,Platform as a Service）平臺,將容器云技術與深度學習相結合,實現了平臺資源隔離及動態部署。基于以上研究,本文以國產Linux 操作系統為云基座,構建私有化容器云平臺,為企業構建標準化、規范化的信息基礎設施提供有力支撐。

1 私有化容器云平臺及其構成

1.1 私有化容器云平臺簡介

容器云平臺是指基于容器化和容器編排技術,結合云原生服務框架構建的一種輕量級云平臺,其核心是在操作系統層面上實現對應用程序運行環境的隔離和封裝[5],為應用提供開發、發布、編排、治理和運維管理的全生命周期管理能力。容器化在資源利用率、遷移便利性等方面較傳統虛擬化技術有明顯的優勢,如圖1 所示,傳統虛擬化層中的虛擬機管理程序和虛擬機操作系統都被Docker 容器層所取代,采用容器化的部署、運行方式,進一步提高了底層硬件的資源利用率。

圖1 虛擬化和容器化對比示意

私有化容器云平臺是基于企業內部網絡構建的與互聯網隔離的容器云平臺,僅服務于企業內部信息系統和應用,依托高速的內部網絡和完善的邊界防護體系,具備更高的穩定性、可用性和安全性。

1.2 私有化容器云平臺構成

1.2.1 私有化容器云平臺基座

本文所討論的基座是指負載私有化容器云平臺運行的服務器底層硬件和操作系統,基座中的底層硬件為平臺提供計算能力、存儲能力和網絡鏈接,而平臺運行所依賴的服務及組件則按照節點的屬性和類型按需部署在基座操作系統上。隨著國家提倡核心技術自主可控,為有效降低企業構建信息基礎設施的成本,綜合考量實際應用場景及穩定性、兼容性等需求,本文選擇基于國產Linux 內核的OpenEuler操作系統作為搭建私有化容器云平臺的云基座。

1.2.2 私有化容器云平臺鏡像倉庫

在容器云中,鏡像是用于創建容器的模板和基礎,所有容器化應用均基于鏡像啟動,因此需要搭建私有鏡像倉庫對鏡像資源進行統一管理,以確保容器云平臺在構建和運行過程中所使用的各類鏡像資源安全可靠。本文采用企業級開源容器鏡像倉庫Harbor[6],滿足Docker 鏡像的存儲、分發及統一管理需求,提供圖形化管理界面、基于角色訪問控制、鏡像遠程復制及日志審計等企業級鏡像管理功能。

2 私有化容器云平臺設計

私有化容器云平臺作為企業的核心信息基礎設施,對安全性和容災能力均有極高的要求,因此,在堅持高可用、易擴展原則的同時,須滿足多租戶在應用研發、測試、運維等方面的多樣化需求。基于此,本文采用Kubernetes 容器編排工具,設計并搭建私有化容器云平臺的集群環境,部署了10 臺計算節點,包括3 臺Master 節點、4 臺Node 節點、2 臺Proxy 代理節點及1 臺負載Harbor 私有鏡像倉庫、Openssl（cfssl）證書簽發環境、離線Yum 倉庫和Yaml 資源配置倉庫的Private-store 節點。當平臺運算或存儲能力不足時,僅增加Node 計算節點數量即可實現平臺的快速橫向擴容。私有化容器云平臺總體架構如圖2 所示。

2.1 Master 節點部署

Master 節點是Kubernetes 集群的管理核心,負責整個集群的管理,同時也是整個容器云平臺的控制中樞。云平臺在3 臺Master 節點上分別部署了etcd分布式鍵值數據庫及API Server、Controller manager、Scheduler 等核心組件[7]。

（1）Etcd 是一個分布式鍵值存儲系統（數據庫）[8],用于存儲集群配置信息和服務注冊信息[9]。為避免Etcd 出現單點故障,在測試環境中采用了集群方式部署,共安裝了3 臺Etcd 節點組建集群,最多可容忍2 臺Etcd 節點同時故障。

（2）API Server 提供了對集群中各類資源對象（如Pod、Deployment、Daemonset、Service、Ingress、Configmap 等）的增、刪、改、查操作,是整個集群的管理入口。

（3）Controller Manager（簡稱：CM）是集群內部的管理控制中心,負責集群內所有資源的動態管理[10],當集群中某一臺Node 節點發生故障時,CM會及時發現故障并啟動自動化修復流程,確保集群始終處于預期的工作狀態[11]。

（4）Scheduler 主要負責整個集群中的資源調度管理,它按照特定的算法及策略,將Pod（Kubernetes中最小的管理單元,一個Pod 可以封裝一個容器或多個容器[12]）調度到最優或最適合的Node 節點上,從而使集群內的資源分配更加合理、資源利用更加充分。

2.2 Node 節點部署

Node 節點是集群中的工作節點,提供了Pod 運行的基礎環境,支撐著集群中運行容器的全生命周期管理。云平臺在4 臺Node 節點上分別部署了Kubelet 組件、Kube-proxy 組件及Docker 引擎。

（1）Kubelet 組件的主要功能是定期從API Server 接收新的或變更的Pod 定義,確保Pod 及其容器在期望的狀態下運行,并實時向API Server 報送采集到的相關信息。

（2）Kube-proxy 是Pod 的TCP/UDP 代理,負責轉發從Service 到后端多個Pod 實例的訪問流量,引入IPVS（IP Virtual Server）模式,實現了在Kubernetes集群中負載更小、擴展性更高、性能更強的虛擬轉發網絡。

（3）Docker 引擎是支撐容器運行的基礎,主要包含Docker 客戶端（Docker Client）及Docker 守護進程（Daemon、Containerd、Runc）,各組件協同負責容器的創建和管理。

2.3 其他計算節點部署

（1）2 臺Proxy 節點作為平臺的入口,配置為高可用集群,分別部署DNS 和Nginx。其中,DNS負責解析Host 主機域和Kubernetes 服務域；Nginx提供反向代理。4 層反向代理指向3 臺API Server,實現集群核心組件的高可用；7 層反向代理用于向外暴露Kubernetes 內部服務。

（2）1 臺Private-store 節點同時部署Harbor 私有鏡像倉庫、Openssl 及cfssl 證書簽發環境、離線Yum 倉庫和Yaml 資源配置倉庫。

2.4 集群核心組件部署

為構建完善的容器云平臺管理及運維體系,在部署集群規劃的節點和基礎組件的基礎上,還須安裝部分功能性組件,用于承擔域名解析、資源通信、服務發現、圖形化管理及監控等任務。為確保組件具備高可用性,本文以容器化集群方式進行部署。

（ 1） 域名解析組件采用 CoreDNS 作為Kubernetes 集群的核心功能組件之一,主要承擔服務發現配置中心的職責,負責對集群內創建的Service和Pod 自動生成對應的DNS 記錄。

（2）資源通信組件采用符合CNI（Container Network Interface）接口規范的Flannel,提供了Pod間通訊的標準化網絡解決方案。通過為每個Pod 分配獨立IP 地址,并將數據包封裝在獨立網絡（覆蓋網絡 Overlay Network）中進行轉發,能夠有效解決Pod 資源跨域、跨節點的通信問題。

（3）Traefik 組件承擔了平臺內服務自發現的功能,同時,實時監測Service 自動更新路由規則,實現更加便捷高效的服務發布。根據預先定義的邏輯規則對外部請求進行攔截,支持HTTP 反向代理或負載均衡等不同的工作模式。

（4）Dashboard 組件是一個基于Web 圖形化界面的集群管理用戶接口,用于部署容器化應用及服務,同時可監控集群狀態、執行故障排查及管理集群資源[13],配合Metrics-Server 組件可實現對集群核心狀態的聚合可視化監控。

3 私有化容器云平臺關鍵技術

3.1 Node 節點證書自簽機制

由于Master 節點中的API Server 組件啟用了TLS 認證,當Node 節點中的Kubelet 和Kube-proxy組件與API Server 進行通信時,必須使用CA 認證中心簽發的有效證書才能建立互信通道。因此當平臺需要擴容時,通常需要手動為新加入集群的Node 節點簽署和頒發證書,在帶來較大工作量的同時會增加集群擴展的復雜度。

為了簡化集群擴容工作流程,本文采用TLS Bootstraping 機制來實現客戶端證書的自動頒發,證書自簽流程如圖3 所示。

圖3 TLS bootstraping 證書自簽流程

當新加入集群的Node 節點中的kubelet 組件在啟動時會加載TLS Bootstraping 的Kubeconfig 認證配置文件,并以一個較低的用戶權限向核心組件API Server 申請證書,當認證配置信息中的token 加密數據和權限驗證通過后,會創建證書簽名請求（CSR,Certificate Signing Request）并自動完成證書的簽署和頒發。

3.2 分布式文件存儲

傳統容器云平臺通常使用網絡文件系統（NFS,Network File System）+ 持久存儲卷聲名（PVC,Persistent Volume Claim）+ 持久存儲卷（PV,Persistent Volume）的存儲資源配置方案,但由于NFS 共享存儲安全性較低且存在單點故障隱患,因此本文引入了Ceph 分布式文件存儲系統,利用多臺存儲服務器有效分擔存儲負荷,不僅可以提高系統的可靠性、可用性和存取效率,還能夠有效將硬件設備引入的不穩定因素降到最低。Ceph 在存儲數據時能夠充分且均衡地利用每個計算節點的存儲能力,同時,提供可供集群選擇的塊存儲（RBD,Rados Block Device）、對象存儲（RGW,Rados GateWay）及文件系統存儲（cephFS,cephFleSorage）等服務[14]。ceph 在 Kubernetes 集群中的應用模式如圖4 所示,利用集群中Node 節點的磁盤空間構建一個高性能、高可用、易拓展的分布式存儲集群,為私有化容器云平臺提供可負載多種業務的、安全可靠的數據存儲服務。

圖4 ceph 在Kubernetes 集群中的應用模式

4 應用方向及風險應對策略

4.1 應用方向

本文構建的私有化容器云平臺具備高性能、高可用、易拓展等特性及較高的安全性,可為構建企業級數據中心提供全新的云計算參考模型,同時為企業內部存量信息系統及應用遷移上云提供最小化資源消耗的解決方案,能夠實現研發項目的敏捷管理、自動化測試、持續集成和持續交付,完成需求交付端到端流程的自動化,橫向打通設計、研發、測試、運維等部門間的數據壁壘,助力企業提升內部協同效率和工作質量。

4.2 風險及應對策略

私有化容器云平臺在構建過程中可能存在以下風險：（1）在容器和容器編排技術領域,相關開源技術及產品種類繁多且良莠不齊,為技術選型帶來了一定的難度；（2）平臺采用了大量第三方開源產品及組件,社區開源軟件相較于商業企業軟件往往缺乏更可靠的技術支持服務,因此存在一定的供應鏈安全風險；（3）平臺涉及網絡、存儲、日志、監控、安全、微服務等眾多技術維度,研發、運維團隊的技術儲備和經驗不足時將難以支撐企業在容器云平臺下的應用開發和運維等需求。

為盡量規避上述風險,本文提出以下應對策略：（1）在選擇構建容器云平臺的技術路線或產品時,應確保各產品和組件之間保持松耦合架構,方便更新和替換,尤其要強化應對供應鏈產品出現重大安全漏洞及供應鏈產品斷供等極端情況下的應急處置措施；（2）對于集群中核心組件的非缺陷性版本升級需求,要保持謹慎,至少應在非生產環境或測試環境中予以充分驗證后再投入使用；（3）要不斷強化相關技術領域的技術培訓和人才培養工作,為企業全面應用容器化云平臺提供強有力的技術支撐。

5 結束語

本文以國產開源Linux 系統為云基座,以Kubernetes+Docker 構建私有化容器云平臺,為企業構建標準化、規范化的信息基礎設施提供了研究方向,同時也為企業提升開發運維效率、優化信息資源配置提供了新的解決方案。

作為能夠承載企業級應用需求的私有化容器云平臺,如何在平臺中提供通用的、基礎的且具有共性需求的技術、數據及資源支撐服務,將是平臺向標準化、成熟化演進的重要技術實踐路徑。未來將重點研究如何通過構建技術中臺來逐步完善云平臺基礎設施,有效將技術能力與業務能力進行分離,通過標準應用程序接口實現快速集成,以標準化、產品化的方式為集群應用提供技術支撐。