中國移動磐舟磐基平臺基於KubeEdge的落地實踐

磐舟一體化雲交付平臺是中國移動自主研發的面向開發人員的程式碼開發，自動部署的平臺。磐舟一體化交付平臺自研實現了一套GitOps驅動引擎，支援從需求設計、開發構建、測試部署的全部開發與運維功能需求，實現應用一鍵上磐基容器雲平臺。

磐基容器雲平臺是中國移動資訊公司基於Kubernetes構建的企業級PaaS解決方案，實現Kubernetes能力的標準化封裝及呼叫，包括提供開發和執行環境、資源彈性伸縮、精細化微服務管理、便捷一站式服務、跨地域多叢集排程和智慧監控維護等六大能力。

磐舟和磐基是相互配合的，開發人員在磐舟叢集上開發，部署到磐基PaaS叢集上執行應用，也支援在磐舟上歸檔磐基叢集ops配置，透過GitOps來管理、部署磐基叢集。

隨著國產化程式推進，中國移動建設了大量的國產化伺服器叢集，磐基磐舟如何實現國產化的容器雲開發交付一體化體系?在某資源池我們需要統一管理近500臺鯤鵬伺服器，原始碼可以透過磐舟統一編譯為X86/ARM雙架構的映象，但是叢集的管理也需要實現ARM自動化支援，開發交付環節頻繁使用Kubernetes叢集，最近2個月已有800多次的叢集建立回收動作，人工支撐顯然已經跟不上雲原生的發展速度了。

另一個場景是，移動的開發人員在集團磐舟Kubernetes叢集上進行開發，製作好映象後，不能直接推送到省測公司的Kubernetes叢集，需要運維人員在磐基中心叢集上透過多級ssh跳板機，手工登入到省公司磐基K8s叢集進行部署。這一步沒有實現自動化，操作流程十分繁瑣。

想解決這些問題，我們進行了一些頭腦風暴。

首先是考慮是否可以將叢集統一?答案顯然是不行。因為集團k8s叢集，由於業務不同，不能和省公司的k8s叢集合為一體。

那麼是否可以做k8s的叢集聯邦?目前集團叢集與省公司叢集之間可能是比較遠的(跨省)，叢集聯邦的整體消耗會大一些，並且目前跳板機的場景，跳到省公司叢集一臺機器上就夠了，不需要看到省公司的所有機器。

維持ssh現狀，維護shell指令碼?shell指令碼需要人力維護，在省公司的節點邏輯很可能需要使用service來完整，繼續維護shell，第一不是那麼CloudNative，第二也背離了磐基磐舟輕鬆上雲的初衷。

本著達到靈活、易用，提升叢集部署時效，解決端到端開發運維效率，成就內部客戶的目的，我們針對整體場景做了進一步抽象，抽象成“1+31+N”的典型網路模型。

1箇中心+“31+N”個邊緣叢集的場景，中心與叢集、叢集與叢集，叢集與N之間，存在著網路隔離與網路不可預知的情況;在這些叢集之間，保持網路隔離的情況下，在中心節點做到雲原生體驗的自動化運維，做到GitOps自動化。

帶著抽象之後的這個模型，我們在平臺管理上進行了深入調研，最終選用了CNCF的邊緣計算專案KubeEdge來解決完成以上所有叢集的統一管理。

KubeEdge是什麼?解決什麼問題?

KubeEdge的特點是在雲邊通訊的資源消耗小，使用方式基於Kubernetes，上手方便，比較適合我們當前的場景。KubeEdge專案是華為雲開源的一個基於Kubernetes的開放平臺，併為網路應用提供基礎架構支援，提供雲和邊緣之間的部署和後設資料同步。

KubeEdge具有以下幾點關鍵優勢：

1)容器化應用封裝

Build once, run anywhere

輕量化基礎映象，降低資源佔用

2)通用的應用抽象定義

業界事實標準

雲上、邊緣統一管理

3)松耦合的架構

易擴充套件的API框架

易於定製平臺元件

KubeEdge 在架構上分為雲端元件 CloudCore 和邊緣側 EdgeCore，詳細的架構細節可以參考文件：

磐舟磐基平臺的KubeEdge實踐

透過對KubeEdge的應用場景分析，以及對移動內部1+31+N模型結合，我們可以將集團的“1”想象為KubeEdge的CloudCore節點、將各省公司的node節點想象為EdgeCore節點，從而就實現了1+31+N下的雲邊協同模型。對映到我們的具體場景是這樣：

1)叢集業務部署場景：

把集團的K8s master節點作為KubeEdge的CloudCore節點，省公司的node節點作為KubeEdge的EdgeCore節點，CloudCore節點與EdgeCore節點連線上後，在EdgeCore上啟動磐舟GitOps業務中ArgoCD pod，統一下發CD一體化的後設資料，從而將省公司資源池做到方便的叢集建立、叢集納管，最終方便的達成自動化GitOps交付。

2)叢集自動化建立場景：

基於省公司的資源池來建立磐基PaaS叢集，運維人員在master節點使用磐舟GitOps，透過CloudCore與EdgeCore的通訊，部署來自openEuler社群的叢集自動化部署工具-eggo的例項。之後在邊緣側，就可以透過eggo來自動化完成省公司磐基PaaS叢集的建立。

綜上，透過將KubeEdge整合至磐基PaaS平臺，成功打通移動集團與各省公司的網路，實現“1+31+N”的K8S叢集全部連通、實現統一管理、簡化多叢集的運維繫統、減少運營成本;同時也成功將前面提到的500臺鯤鵬伺服器以及它上面的BC-Linux for Euler叢集納入磐基PaaS平臺的大家庭之中，運維效率大幅增加。

磐舟磐基平臺在多叢集管理的下一步計劃

在完成KubeEdge整合到磐舟磐基平臺這項專項工作之後，考慮到後續不僅是由master節點納管單個edge節點，還會考慮在將南向叢集的單個節點組成一個叢集，實現控制面的自動化叢集部署，支撐省公司叢集的控制面自動化。磐舟磐基平臺計劃進一步整合CNCF社群最新的叢集聯邦方案Karmada來完成“1+31+N”的PaaS多叢集統一管理工作。