解讀多雲跨雲下的容器治理與實踐
摘要：雲原生技術和雲市場不斷成熟，多雲、多叢集部署已經成為常態，未來將是程式設計式多雲管理服務的時代。
本文分享自華為雲社群《華為雲MCP多雲跨雲的容器治理與實踐》，原文作者：技術火炬手。
在華為開發者大會（Cloud）2021上，華為雲CTO張宇昕宣佈多雲容器編排專案Karmada正式開源。4月26日，華為雲原生開源負責人王澤鋒與華為雲高階工程師徐中虎發表了《華為雲MCP多雲跨雲的容器治理與實踐》主題演講，分享了華為雲MCP的的發展情況與Karmada專案的核心黑科技。
演講主要包含五個方面的內容：
- 1）雲原生多雲現狀及挑戰
- 2）華為雲MCP歷程
- 3）Karmada專案
- 4）多叢集服務治理
- 5）小結與展望
雲原生多雲現狀及挑戰
根據最新的調查報告顯示，超過93%的企業正同時使用多個雲廠商的服務。雲原生技術和雲市場不斷成熟，多雲、多叢集部署已經成為常態，未來將是程式設計式多雲管理服務的時代。而業務部署到多雲或多叢集，它其實是分幾個階段的:
典型階段1：多雲多地部署，統一管理運維，減少重複勞動
第一個階段，我們認為是多地部署統一運維管理，可以理解為是多個互操作的孤島，互操作意味著在不同的環境，不同的雲上，所用軟體的技術站是一套標準化的，在進行公有云、公有云1、公有云2互相切換時，操作命令所輸入的命令請求都是一樣的，但其之間沒有任何業務相關性或業務相關性非常弱，此時去做統一的應用交付，比如部署運維，要麼手動執行重複的命令或者指令碼化，或者最簡單的用一套CI/CD的系統堆上去即可。因為在這個階段大部分的業務相對來說比較固定，部署在哪個公有云、哪個資料中心，哪個機房，不需要太多的動態性和變化性。
典型階段2：多雲統一資源池，應對業務壓力波動
第二個階段為統一資源池，則會對資源池的動態性有一定的訴求。一般來說，在此處我們所認為的應用交付並不是一個簡單的CI/CD，因為我們希望動態性之後，流量也能夠隨之遷移。在這種情況下，上面的應用交付就需要具備自動排程的能力，流量可以根據例項數的分佈情況自己去獲取。當然也會有其他情況，比如用一些簡單的指令碼化來處理你的流量，也可以認為達到了第二個階段。當然理想的狀態下，我們認為這些應該是全自動化的。
典型階段3：多雲協同，統一應用平臺，業務跨雲部署
第三個階段是我們認為當前可預見到的一個多雲和多叢集的最終形態，也是我們所認為一個理想中的形態。其實不論用叢集、Kubernetes或以前的虛擬機器，從整個雲端計算的發展歷史來看，其實一直在不斷的突破邊界，或者說重新去定義邊界。比如最早的時候裝一些新的應用、部署新的服務，需要一臺物理伺服器，而邊界非常不靈活，當後來有了虛機、容器，顆粒度變小了，但在跨機器跨環境的訪問形態下，又產生了很多新的挑戰，所以Kubernetes的出現其實在產生了這麼多細膩度的容器之後，重新畫一個大的叢集作為邊界。
而多雲其實是在這些不斷演進的邊界基礎上，當在發展到一定的階段受到資料中心或雲的限制，可以用多雲的技術來突破雲的邊界，突破叢集的邊界，真正的做到業務的應用可以自由的在叢集、在雲之間靈活的部署和遷移。
但其實在雲原生話題下，多雲仍然存在非常多的挑戰，原因有以下幾點：
- 叢集繁多：繁瑣重複的叢集配置、雲廠商的叢集管理差異、碎片化的API訪問入口
- 業務分散：應用在各叢集的差異化配置、業務跨雲訪問、叢集間的應用同步
- 叢集的邊界限制：資源排程受限於叢集、應用可用性受限於叢集、彈性伸縮受限於叢集
- 廠商繫結：業務部署的“黏性”、缺少自動的故障遷移、缺少中立的開源多叢集編排專案
華為雲MCP歷程
在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要覆蓋的所有的能力範圍。從資料面、儲存以及運維相關的維度來看，我們向上要去解決容器網路的多雲多叢集，服務發現的多雲多叢集甚至流量治理，原資料的持久化，這些將會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: 跨叢集可重用的差異化配置策略
resourceSelector
- 支援使用 name 或 labelSelector 進行物件篩選
overriders
- 支援多種override外掛型別
- plainTextOverrider :基礎外掛，純文字操作替換
- imageOverrider:針對容器映象的差異化配置外掛
多叢集服務治理
多叢集服務治理要解決的問題
- 服務發現
- DNS解析
- 負載均衡、熔斷、故障注入，流量切分等高階流量治理
- 跨雲的訪問安全性
ServiceMesh的優勢
上圖是Istio ServiceMesh典型的架構圖，Istio是一個完全無侵入式的，通過自動注入Certificate的方式去攔截應用發出來的流量，並通過Certificate管理應用的流量。
Istio的基本功能：
1）流量治理
- 通過Resilience（熔斷、超時、重試、故障注入等)，提高整個系統的韌性
- 灰度釋出：方便我們去更快的部署上線新版本
- 負載均衡、路由匹配，基本上可以取代原來的那種微服務治理的框架
2）安全：資料加密、認證、鑑權
3）可觀測：可觀測性是更加方便應用運維人員去診斷系統的故障，這裡的典型的三個可觀測性的指標有Metrics、Traces（呼叫鏈）、Access Log（訪問日誌）。
多叢集多雲場景下，如何進行服務網格的技術選型？
接下來，將從下面這三個維度來進行技術細節的詳細說明:
- 扁平網路 vs 非扁平網路
- 單服務網格 vs 多服務網格
- 單控制面 vs 多控制面
1）多叢集服務網格-扁平網路
優勢：
- 東西向服務訪問延遲低
缺點：
- 組網複雜性
- 安全性：所有的工作負載在同一網路中.
- Scalability: pod、service IP地址不衝突
2）多叢集服務網格-非扁平網路
優勢：
- 網路隔離，安全性相對更高
- 組網簡單
- Scalability: pod/service網路地址可以重疊
缺點：
- 跨叢集服務訪問需要通過東西向閘道器
- Gateway工作依賴TLS Auto Passthrough
3）非扁平網路-單控制面
- 單個控制面（可以部署在使用者叢集或者完全託管）
- 服務發現
- 配置發現
- Split Horizon EDS
- 東西向閘道器
4）非扁平網路-多控制面
- 控制面部署在每個叢集
- 服務發現
- 配置發現
- Sidecar連線本叢集內的Istio控制面，與單控制面相比，有更好的效能和可用性
5）非扁平網路-東西向閘道器
- 閘道器地址獲取
- Split horizon EDS:
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: cross-network-gateway namespace: istio-system spec: selector: istio: eastwestgateway servers: - hosts: - '*.local' port: name: tls number: 15443 protocol: TLS tls: mode: AUTO_PASSTHROUGH
- Network filter: “envoy.filters.network.sni_cluster”
附：Karmada社群技術交流地址
專案地址：https://github.com/karmada-io/karmada
Slack地址：https://karmada-io.slack.com