引子

隨著雲原生技術的普及，越來越多的企業使用Kubernetes來管理應用，並且叢集規模也呈爆發式增長，企業也亟需應對隨叢集規模增長而帶來的各種挑戰。同時，為了更好地提供高可用、彈性伸縮的應用，企業也對容器混合雲解決方案產生了極大的興趣。

縱觀容器混合雲市場，主要的雲服務提供商紛紛推出了自家的解決方案，例如華為雲的MCP、Google的Anthos、Vmware的 Tanzu、IBM的 Cloud Pak、Red Hat的ACM for K8s等等。可以說，當前容器混合雲市場紛繁嘈雜、百家爭鳴，儘管各廠商不遺餘力地鼓吹自家解決方案，但有個不爭的事實是在容器混合雲領域暫未出現領軍產品。

混合雲市場的亂象源於兩點，一是各廠商均嗅到了商機，發現了這一廣闊的藍海市場，急於在這場競爭中搶佔先機C位出道；二是開源界暫無統一的事實標準。根據歷史規律，後者是解決這一亂象的關鍵所在，正像Kubernetes終結容器編排領域的紛爭一模一樣。

在開源領域，致力於混合雲領域的專案數量與廣闊的市場相比，顯得極不相稱。目前只有Rancher的Fleet、SAP公司力推的Gardener、以及Kubernetes社群的Kubefed。Fleet和Gardener要麼缺乏創新，要麼格局較低，難成大氣，最有可能形成標準的便是被寄予厚望的、也是當前Kubernetes社群唯一的官方專案Kubefed。

K8s多叢集歷史

Kubernetes社群早在2015年便釋出了叢集聯邦技術白皮書，併成立了“SIG-Federation”（後更名為SIG-Multicluster）特別興趣小組致力於多叢集領域的研究，該興趣小組由華為領銜，同時也吸引了包括Google、Redhat在內的一線大廠。

SIG-Federation於2016年正式推出官方專案Federation，並在此基礎上發展出了Kubefed專案，而且技術架構也發生了較大的變化，因此Federation專案常常被稱為Federation V1，而Kubefed則被稱為Federation V2。

Federation V1架構

第一代架構中，引入了Federated API Server，用於增加叢集相關API，遮蔽叢集差異，統一請求入口，同時提供一個Cluster Controller用於管理多個叢集狀態、叢集級別物件建立，並且Service Controller用來實現跨叢集服務發現。整體架構如下圖所示：

V1架構相容K8S原生API，從單叢集到多叢集演進可以變得很自然，但它也有幾個不得不面對的缺陷。

• 叢集資訊嵌入原生API的Annotation中（如下圖所示），會導致原生API體積膨脹而醜陋；

• 沒有叢集生命週期管理特有API，導致其生命週期管理能力無法擴充套件；

• 無法提供API物件版本控制，比如Deployment在K8S為GA，但在Federation中可能仍是Beta；

Federation V2架構

在第二代架構中，利用CRD來提供獨立的API物件，新的API來封裝K8S原生物件，同時也可以方便的對新增API提供版本管理。
整體架構如下圖所示：

隨架構升級，Federation專案也更名為Kubefed。在新的架構中，Kubefed提供兩種配置型別：

• Type configuration（型別配置）： 定義Kubefed接管的K8S的資源型別

• Cluster configuration（叢集配置）： 定義Kubefed接管的K8S叢集

在型別配置中有三個關鍵的概念，用於控制資源向拖管叢集分發策略：

• Templates（模版）：定義一個原生的K8S資源型別；

• Placement（安置）：定義資源將分發的叢集；

• Overrides（修正）：針對叢集自由修正資源；

一個典型的Secret配置如下圖所示：

apiVersion: types.kubefed.io/v1beta1
kind: FederatedSecret
metadata:
  name: test-secret
  namespace: test-namespace
spec:
  template:
    data:
      A: YWxhIG1hIGtvdGE=
    type: Opaque
  placement:
    clusters:
    - name: cluster2
    - name: cluster1
  overrides:
  - clusterName: cluster2
    clusterOverrides:
    - path: /data
      value:
        A: null

上述配置中，通過template指定原生資源屬性，通過placement指定資源將分發到cluster1 和 cluster2叢集，最後overrides指示了分發到cluster2叢集時，消除Secret的data資訊。

K8s多叢集現狀

KubeFed的問題

Kubernetes社群當前已將Federation (v1)專案關閉，著重發展Kubefed，但該專案尚停留在beta階段，社群開發幾乎停滯，作為社群官方專案在該領域中的領導地位也在逐漸減弱。

Kubefed專案最大的問題是使用了非Kubernetes原生API來管理使用者應用部署，使用者必須先改造既有的工作流程才可遷移到Kubefed提供的API，這不僅抬高了使用門檻，而且Kubefed為每種資源型別均提供了CRD API，種類繁多的API也增加了使用者的學習成本。某位社群致力於多叢集管理的架構師坦言：“Kubefed專案強制使用者使用非原生API，這個錯誤的決定很大程度上導致了它的發展不如預期。”

另外，多叢集管理場景中，應用的多叢集分發與監控應該是最基本的訴求，而Kubefed只完成了應用分發，對於應用的執行狀態缺乏監管。使用者使用Kubefed分發應用只能看到應用是否分發成功，對於應用執行狀態，使用者仍需要遍歷叢集分別獲取。對使用者使用造成了極大的不便。

K8s多叢集管理標準化工作

當前Kubernetes社群針對Kubefed相關問題已經進行了多次討論，目前多叢集管理相關標準制定工作主要圍繞在跨叢集服務發現和工作負載配置管理，這兩塊也是實現多叢集應用管理最基礎的功能部分。

a.多叢集Service API

在多叢集應用背景下，使用者已經習慣於將應用分發到多個叢集，但對於Service應用而言，叢集是個硬性障礙，運行於叢集中的工作負載無法高效地訪問其他叢集中暴露的服務。多叢集Service API旨在提供解決這個問題的標準，它主要包括：

1）定義一組API支援跨叢集的Service服務發現和消費；

2）叢集中應用跨叢集訪問Service行為與本叢集一致；

該Service API提供ServiceExport物件表示單個叢集中需要暴露到多叢集的Service：

// ServiceExport declares that the associated service should be exported to
// other clusters.
type ServiceExport struct {
        metav1.TypeMeta `json:",inline"`
        // +optional
        metav1.ObjectMeta `json:"metadata,omitempty"`
        // +optional
        Status ServiceExportStatus `json:"status,omitempty"`
}

每個需要暴露給其他叢集的Service均對應一個ServiceExport物件。

此外，Service API還提供了ServiceImport物件，表示跨叢集的Service定義：

// ServiceImport describes a service imported from clusters in a supercluster.
type ServiceImport struct {
  metav1.TypeMeta `json:",inline"`
  // +optional
  metav1.ObjectMeta `json:"metadata,omitempty"`
  // +optional
  Spec ServiceImportSpec `json:"spec,omitempty"`
  // +optional
  Status ServiceImportStatus `json:"status,omitempty"`
}

該Service API 提案已被社群接納，該提案只定義了跨叢集Service的宣告方式，並沒有對其實現細節進行約束，可以想見，將來會有多種具體的解決方案被提出。

b.多叢集工作負載模型

關於聯邦應用如何在多叢集中分發，SIG-Multicluster也在進行嘗試一種與現有Kubefed不同的處理思路。Kubefed當前從一系列FederatedXXX配置中剝離出Kubernetes原生應用分發到多叢集，而新的嘗試是提供一個通用的ManifestWork物件封裝所有的應用，如下API設計：

// ManifestWork represents a manifests workload that hub wants to deploy on the managed cluster.

// A manifest workload is defined as a set of kubernetes resources.

// ManifestWork must be created in the cluster namespace on the hub, so that agent on the

// corresponding managed cluster can access this resource and deploy on the managed

// cluster.

type ManifestWork struct {

   metav1.TypeMeta   `json:",inline"`

   metav1.ObjectMeta `json:"metadata,omitempty"`


   // Spec represents a desired configuration of work to be deployed on the managed cluster.

   Spec ManifestWorkSpec `json:"spec"`


   // Status represents the current status of work

   // +optional

   Status ManifestWorkStatus `json:"status,omitempty"`

}

與Kubefed為每種應用型別均提供一個FederatedXXX 型別相比，這種新型的工作負載API則顯得更加簡單和通用。

未來展望

K8s多叢集技術是容器混合雲/多雲解決方案的核心技術領域，涉及到資源、應用、資料、流量多個層面，以及統一配置、註冊、視覺化、自動彈性等多個功能領域。目前開源業界包括K8s社群的KubeFed專案、以及現有市面上的各種產品與解決方案都沒有能夠覆蓋完整的多叢集技術領域。

華為雲MCP容器多雲平臺在K8s多叢集技術領域屬於較早也是實現較為全面的產品，而同時華為雲作為KubeFed社群專案的發起者與領導者，將在未來致力於完善現有KubeFed的功能集，並且實現K8s多叢集技術的標準化。下圖描述了K8s多叢集技術的全景，目前華為雲已經在KubeFed自身以及周邊關聯的多個技術領域開展了相關工作。

點選關注，第一時間瞭解華為雲新鮮技