k8s極簡史：K8s多集群技術發展的歷史、現狀與未來

引子

隨著雲原生技術的普及，越來越多的企業使用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自身以及周邊關聯的多個技術領域開展了相關工作。

 

點擊關注，第一時間了解華為雲新鮮技術~

Tags:

VirMach 便宜 VPS

QNews

QNews