摘要：雲原生技術和雲市場不斷成熟，多雲、多叢集部署已經成為常态，未來将是程式設計式多雲管理服務的時代。
本文分享自華為雲社群《華為雲MCP多雲跨雲的容器治理與實踐》，原文作者：技術火炬手。
在華為開發者大會（Cloud）2021上，華為雲CTO張宇昕宣布多雲容器編排項目Karmada正式開源。4月26日，華為雲原生開源負責人王澤鋒與華為雲進階工程師徐中虎發表了《華為雲MCP多雲跨雲的容器治理與實踐》主題演講，分享了華為雲MCP的的發展情況與Karmada項目的核心黑科技。
演講主要包含五個方面的内容：
1）雲原生多雲現狀及挑戰
2）華為雲MCP曆程
3）Karmada項目
4）多叢集服務治理
5）小結與展望
根據最新的調查報告顯示，超過93%的企業正同時使用多個雲廠商的服務。雲原生技術和雲市場不斷成熟，多雲、多叢集部署已經成為常态，未來将是程式設計式多雲管理服務的時代。而業務部署到多雲或多叢集，它其實是分幾個階段的:
第一個階段，我們認為是多地部署統一運維管理，可以了解為是多個互操作的孤島，互操作意味着在不同的環境，不同的雲上，所用軟體的技術站是一套标準化的，在進行公有雲、公有雲1、公有雲2互相切換時，操作指令所輸入的指令請求都是一樣的，但其之間沒有任何業務相關性或業務相關性非常弱，此時去做統一的應用傳遞，比如部署運維，要麼手動執行重複的指令或者腳本化，或者最簡單的用一套CI/CD的系統堆上去即可。因為在這個階段大部分的業務相對來說比較固定，部署在哪個公有雲、哪個資料中心，哪個機房，不需要太多的動态性和變化性。
第二個階段為統一資源池，則會對資源池的動态性有一定的訴求。一般來說，在此處我們所認為的應用傳遞并不是一個簡單的CI/CD，因為我們希望動态性之後，流量也能夠随之遷移。在這種情況下，上面的應用傳遞就需要具備自動排程的能力，流量可以根據執行個體數的分布情況自己去擷取。當然也會有其他情況，比如用一些簡單的腳本化來處理你的流量，也可以認為達到了第二個階段。當然理想的狀态下，我們認為這些應該是全自動化的。
第三個階段是我們認為目前可預見到的一個多雲和多叢集的最終形态，也是我們所認為一個理想中的形态。其實不論用叢集、Kubernetes或以前的虛拟機，從整個雲計算的發展曆史來看，其實一直在不斷的突破邊界，或者說重新去定義邊界。比如最早的時候裝一些新的應用、部署新的服務，需要一台實體伺服器，而邊界非常不靈活，當後來有了虛機、容器，顆粒度變小了，但在跨機器跨環境的通路形态下，又産生了很多新的挑戰，是以Kubernetes的出現其實在産生了這麼多細膩度的容器之後，重新畫一個大的叢集作為邊界。
而多雲其實是在這些不斷演進的邊界基礎上，當在發展到一定的階段受到資料中心或雲的限制，可以用多雲的技術來突破雲的邊界，突破叢集的邊界，真正的做到業務的應用可以自由的在叢集、在雲之間靈活的部署和遷移。
但其實在雲原生話題下，多雲仍然存在非常多的挑戰，原因有以下幾點：
叢集繁多：繁瑣重複的叢集配置、雲廠商的叢集管理差異、碎片化的API通路入口
業務分散：應用在各叢集的差異化配置、業務跨雲通路、叢集間的應用同步
叢集的邊界限制：資源排程受限于叢集、應用可用性受限于叢集、彈性伸縮受限于叢集
廠商綁定：業務部署的“黏性”、缺少自動的故障遷移、缺少中立的開源多叢集編排項目
在Kubernetes裡面，多叢集的概念出現非常早，華為也是作為最早的發起的機關之一，2015年我們在社群提出了 Federation的概念，Federation的v1版本是在2016年啟動開發，在2017年将其獨立，作為Kubernetes的獨立子項目來研發。2017年中, 我們啟動了Federation v2的開發。商業化的話，其實華為是在2018年中啟動整個商業化的大平台，并且在年底提供了商用的能力，但我們在長期服務于客戶的過程中也發現一些問題，是以在2020年，我們啟動了全新的引擎Karmada。
Karmada是基于 Kubernetes Federation v1 和 v2 開發，它可以跨多個 Kubernetes 叢集和雲運作雲原生應用程式，而無需對應用程式進行更改。通過直接使用 Kubernetes 原生 API 并提供進階排程功能，Karmada 可以實作真正的開放式多雲 Kubernetes。
上圖為我們認為應該在開源社群所要呈現的多雲多叢集的技術站視角，圖中灰色框也是Karmada要覆寫的所有的能力範圍。從資料面、存儲以及運維相關的次元來看，我們向上要去解決容器網絡的多雲多叢集，服務發現的多雲多叢集甚至流量治理，原資料的持久化，這些将會Karmada項目在社群裡所要涵蓋的範圍。
在起步階段，我們主要會關注幾個方面，一是相容K8s原生API，這個特性其實是原來Federation的v2一個稍微比較大的阻礙，因為大家都習慣去使用k8s的API而不是新的API，是以我們在做全新的Karmada項目時，直接采用原生的API來提供多叢集的應用部署的能力。
在叢集同步方面，我們會支援多種網絡模式，包括控制面在公有雲，子叢集在私有雲或者是反過來，甚至是邊緣的場景，也都可以用Karmada這個項目去覆寫，并且我們會内置開箱即用的能力來實作最低成本的适配。
Karmada架構圖上面有一個統一的控制面，我們其實有一個獨立的API-server來出Kubernetes原生API也會出Karmada提供的額外政策API的能力，來做輔助的進階排程的核心功能。在叢集同步方面，我們有中心式的 Controller和 Agent兩種模式，分别對應于控制面和子叢集在公私有雲或倒置的情況。
另外一類是大邊緣的場景，它在雲邊的網絡環境下，需要管理一個邊緣的叢集，是以我們會結合KubeEdge在整個網絡環境下的優化來提供針對邊緣的叢集管理能力。
Karmada項目核心價值：
K8s原生API相容，豐富雲原生生态
内嵌政策，開箱即用
豐富的多叢集排程支援
叢集資源空間隔離
多種模式叢集同步，屏蔽地域、網絡限制
1）零改造 — 使用K8s原生API部署一個多叢集應用
示例政策：為所有deployment配置多AZ的HA部署方案
使用标準的K8s API定義部署應用
kubectl create -f nginx-deployment.yaml
2）Propagation Policy: 可重用的應用多叢集排程政策
resourceSelector
支援關聯多種資源類型
支援使用 name 或 labelSelector 進行對象篩選
placement
clusterAffinity:
定義傾向排程的目标叢集
支援通過 names 或 labelselector 篩選
clusterTolerations:
類似單叢集中Pod tolerations和 node taints
spreadConstraints:
定義應用分發的HA政策
支援對叢集動态分組：按Region、AZ、特性label分組，實作不同層級的HA
3）Override Policy: 跨叢集可重用的差異化配置政策
overriders
支援多種override插件類型
plainTextOverrider :基礎插件，純文字操作替換
imageOverrider:針對容器鏡像的差異化配置插件
多叢集服務治理要解決的問題
服務發現
DNS解析
負載均衡、熔斷、故障注入，流量切分等進階流量治理
跨雲的通路安全性
上圖是Istio ServiceMesh典型的架構圖，Istio是一個完全無侵入式的，通過自動注入Certificate的方式去攔截應用發出來的流量，并通過Certificate管理應用的流量。
1）流量治理
通過Resilience（熔斷、逾時、重試、故障注入等)，提高整個系統的韌性
灰階釋出：友善我們去更快的部署上線新版本
負載均衡、路由比對，基本上可以取代原來的那種微服務治理的架構
2）安全：資料加密、認證、鑒權
3）可觀測：可觀測性是更加友善應用運維人員去診斷系統的故障，這裡的典型的三個可觀測性的名額有Metrics、Traces（調用鍊）、Access Log（通路日志）。
接下來，将從下面這三個次元來進行技術細節的詳細說明:
扁平網絡 vs 非扁平網絡
單服務網格 vs 多服務網格
單控制面 vs 多控制面
優勢：
東西向服務通路延遲低
缺點：
組網複雜性
安全性：所有的工作負載在同一網絡中.
Scalability: pod、service IP位址不沖突
網絡隔離，安全性相對更高
組網簡單
Scalability: pod/service網絡位址可以重疊
跨叢集服務通路需要通過東西向網關
Gateway工作依賴TLS Auto Passthrough
單個控制面（可以部署在使用者叢集或者完全托管）
配置發現
Split Horizon EDS
東西向網關
控制面部署在每個叢集
Sidecar連接配接本叢集内的Istio控制面，與單控制面相比，有更好的性能和可用性
網關位址擷取
Split horizon EDS:
Network filter: “envoy.filters.network.sni_cluster”
附：Karmada社群技術交流位址
項目位址： https://github.com/karmada-io/karmada
Slack位址： https://karmada-io.slack.com
點選關注，第一時間了解華為雲新鮮技術~