本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Cluster API v1alpha3 帶來新功能和改進的使用者體驗

作者：Daniel Lipovetsky (D2IQ) | 2020 年 4 月 21 日，星期二

Cluster API 是一個 Kubernetes 專案，旨在將宣告式、Kubernetes 風格的 API 引入叢集的建立、配置和管理。它在核心 Kubernetes 之上提供了可選的、附加的功能，以管理 Kubernetes 叢集的生命週期。

在 2019 年 10 月釋出 v1alpha2 後，Cluster API 社群的許多成員在加利福尼亞州舊金山會面，規劃下一個版本。該專案剛剛經歷了重大轉型，交付了一個新架構，有望使使用者更容易採用該專案，並使社群更快地構建。在那兩天裡，我們找到了共同的目標：實現對管理生產叢集至關重要的功能，使其使用者體驗更直觀，並使其開發過程充滿樂趣。

Cluster API 的 v1alpha3 版本為在生產環境中大規模執行 Kubernetes 的任何人帶來了重要功能。主要亮點包括：

宣告式控制平面管理
支援在故障域之間分配控制平面節點以降低風險
自動替換不健康的節點
支援基礎設施管理的節點組

對於任何想要了解 API，或者重視簡單而強大的命令列介面的人，新版本帶來了：

重新設計的 clusterctl，一個用於安裝和管理 Cluster API 生命週期的命令列工具（和 Go 庫）
Cluster API 手冊中廣泛且最新的文件

最後，對於任何為自定義基礎設施或軟體需求擴充套件 Cluster API 的人：

新的端到端 (e2e) 測試框架
將 Cluster API 整合到您的叢集生命週期棧中的文件

所有這些都歸功於眾多貢獻者的辛勤工作。

宣告式控制平面管理

特別感謝 Jason DeTiberus、Naadir Jeewa 和 Chuck Ha

基於 Kubeadm 的控制平面 (KCP) 提供了一個宣告式 API，用於部署和擴充套件 Kubernetes 控制平面，包括 etcd。這是許多 Cluster API 使用者一直期待的功能！直到現在，要部署和擴充套件控制平面，使用者必須建立專門的 Machine 資源。要縮減控制平面，他們必須手動從 etcd 叢集中移除成員。KCP 自動化了部署、擴充套件和升級。

什麼是 Kubernetes 控制平面？ Kubernetes 控制平面的核心是 kube-apiserver 和 etcd。如果其中任何一個不可用，則無法處理 API 請求。這不僅影響核心 Kubernetes API，還影響透過 CRD 實現的 API。其他元件，如 kube-scheduler 和 kube-controller-manager，也很重要，但對可用性的影響不同。
控制平面最初很重要，因為它負責排程工作負載。然而，在控制平面中斷期間，某些工作負載可以繼續執行。如今，工作負載依賴於操作員、服務網格和 API 閘道器，所有這些都將控制平面用作平臺。因此，控制平面的可用性比以往任何時候都更加重要。
管理控制平面是叢集操作中最複雜的部分之一。由於典型的控制平面包括 etcd，因此它是有狀態的，操作必須按正確順序進行。控制平面副本可能且確實會失敗，維持控制平面可用性意味著能夠替換故障節點。
控制平面可能會完全中斷（例如 etcd 中仲裁的永久丟失），恢復（以及定期備份）有時是唯一可行的選擇。
有關更多詳細資訊，請參閱 Kubernetes 文件中的 Kubernetes 元件。

這是一個用於 Cluster API Docker 基礎設施的三副本控制平面示例，該專案維護此基礎設施用於測試和開發。為簡潔起見，未顯示其他必需資源，如叢集和基礎設施模板（透過其名稱和名稱空間引用）。

apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
kind: KubeadmControlPlane
metadata:
  name: example
spec:
  infrastructureTemplate:
    apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
    kind: DockerMachineTemplate
    name: example
    namespace: default
  kubeadmConfigSpec:
    clusterConfiguration:
  replicas: 3
  version: 1.16.3

使用 kubectl 部署此控制平面

kubectl apply -f example-docker-control-plane.yaml

以與擴充套件其他 Kubernetes 資源相同的方式擴充套件控制平面

kubectl scale kubeadmcontrolplane example  --replicas=5

kubeadmcontrolplane.controlplane.cluster.x-k8s.io/example scaled

將控制平面升級到更新的 Kubernetes 版本補丁

kubectl patch kubeadmcontrolplane example --type=json -p '[{"op": "replace", "path": "/spec/version", "value": "1.16.4"}]'

控制平面副本數量 預設情況下，KCP 配置為管理 etcd，並要求奇數個副本。如果 KCP 配置為不管理 etcd，則建議使用奇數，但不是必需的。奇數副本可確保最佳 etcd 配置。要了解為什麼您的 etcd 叢集應該有奇數個成員，請參閱 etcd FAQ。

作為核心 Cluster API 元件，KCP 可以與任何 v1alpha3 相容的、提供固定控制平面端點（即負載均衡器或虛擬 IP）的 Infrastructure Provider 一起使用。此端點使得請求能夠到達多個控制平面副本。

什麼是基礎設施提供商 (Infrastructure Provider)？ 計算資源（例如機器、網路等）的來源。社群維護 AWS、Azure、Google Cloud 和 VMWare 的提供商。有關詳細資訊，請參閱 Cluster API 手冊中的提供商列表。

分佈控制平面節點以降低風險

特別感謝 Vince Prignano 和 Chuck Ha

Cluster API 使用者現在可以將節點部署在不同的故障域中，從而降低叢集因域中斷而失敗的風險。這對於控制平面尤為重要：如果一個域中的節點發生故障，只要控制平面可用於其他域中的節點，叢集就可以繼續執行。

什麼是故障域？ 故障域是一種將因某種故障而變得不可用的資源進行分組的方式。例如，在許多公共雲中，“可用區”是預設的故障域。一個可用區對應一個數據中心。因此，如果一個特定的資料中心因停電或自然災害而宕機，該區域中的所有資源都將變得不可用。如果您在自己的硬體上執行 Kubernetes，您的故障域可能是機架、網路交換機或電源分配單元。

基於 Kubeadm 的控制平面將節點分佈在故障域中。為了最大程度地降低在域中斷事件中丟失多個節點的可能性，它嘗試均勻地分佈它們：它在現有節點最少的故障域中部署一個新節點，並在現有節點最多的故障域中移除一個現有節點。

MachineDeployments 和 MachineSets 不會將節點分佈在故障域中。要將您的工作節點部署到多個故障域中，請為每個故障域建立一個 MachineDeployment 或 MachineSet。

故障域 API 適用於任何基礎設施。這是因為每個基礎設施提供商都以自己的方式對映故障域。API 是可選的，因此如果您的基礎設施不夠複雜而不需要故障域，則無需支援它。此示例適用於 Cluster API Docker 基礎設施提供商。請注意，其中兩個域被標記為適合控制平面節點，而第三個域不適合。基於 Kubeadm 的控制平面將只部署節點到標記為適合的域。

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: DockerCluster
metadata:
  name: example
spec:
  controlPlaneEndpoint:
    host: 172.17.0.4
    port: 6443
  failureDomains:
    domain-one:
      controlPlane: true
    domain-two:
      controlPlane: true
    domain-three:
      controlPlane: false

由 Cluster API 專案維護的 AWS 基礎設施提供商 (CAPA) 將故障域對映到 AWS 可用區。使用 CAPA，您可以跨多個可用區部署叢集。首先，為多個可用區定義子網。CAPA 控制器將為每個可用區定義一個故障域。使用 KubeadmControlPlane 部署控制平面：它將在故障域中分發副本。最後，為每個故障域建立單獨的 MachineDeployment。

自動替換不健康的節點

特別感謝 Alberto García Lamela 和 Joel Speed

節點不健康的原因有很多。kubelet 程序可能會停止。容器執行時可能存在 bug。核心可能存在記憶體洩漏。磁碟空間可能耗盡。CPU、磁碟或記憶體硬體可能發生故障。可能會發生停電。這些故障在大規模叢集中尤其常見。

Kubernetes 的設計宗旨是容忍這些故障，並幫助您的應用程式容忍它們。然而，在叢集資源耗盡之前，只有有限數量的節點可以是不健康的，Pod 將被逐出或根本無法排程。不健康的節點應儘快修復或替換。

Cluster API 現在包含一個 MachineHealthCheck 資源和一個監控節點健康的控制器。當它檢測到不健康的節點時，它會將其移除。（另一個 Cluster API 控制器檢測到節點已被移除並替換它。）您可以根據您的需求配置控制器。您可以配置在移除節點之前等待多長時間。您還可以設定不健康節點的數量閾值。達到閾值時，不再移除節點。等待時間可以用於容忍短期中斷，而閾值可以防止同時替換過多的節點。

控制器將僅移除由 Cluster API MachineSet 管理的節點。控制器不會移除控制平面節點，無論是透過基於 Kubeadm 的控制平面管理，還是像 v1alpha2 中那樣由使用者管理。有關更多資訊，請參閱 MachineHealthCheck 的限制和注意事項。

這是一個 MachineHealthCheck 的示例。有關更多詳細資訊，請參閱 Cluster API 手冊中的配置 MachineHealthCheck。

apiVersion: cluster.x-k8s.io/v1alpha3
kind: MachineHealthCheck
metadata:
  name: example-node-unhealthy-5m
spec:
  clusterName: example
  maxUnhealthy: 33%
  nodeStartupTimeout: 10m
  selector:
    matchLabels:
      nodepool: nodepool-0
  unhealthyConditions:
  - type: Ready
    status: Unknown
    timeout: 300s
  - type: Ready
    status: "False"
    timeout: 300s

基礎設施管理的節點組

特別感謝 Juan-Lee Pang 和 Cecile Robert-Michon

如果您執行大型叢集，您需要在幾分鐘內建立和銷燬數百個節點。儘管公共雲使得處理大量節點成為可能，但不得不為每個節點的建立或刪除發出單獨的 API 請求可能會擴充套件不佳。例如，API 請求可能必須延遲以保持在速率限制內。

一些公共雲提供了將節點組作為單個實體進行管理的 API。例如，AWS 有 AutoScaling Groups，Azure 有 Virtual Machine Scale Sets，GCP 有 Managed Instance Groups。透過此版本的 Cluster API，基礎設施提供商可以新增對這些 API 的支援，使用者可以使用 MachinePool 資源部署 Cluster API 機器組。有關更多資訊，請參閱 Cluster API 倉庫中的提案。

實驗性功能 MachinePool API 是一個實驗性功能，預設情況下未啟用。建議使用者嘗試並報告它是否滿足他們的需求。

Cluster API 使用者體驗，重新構想

clusterctl

特別感謝 Fabrizio Pandini

如果您是 Cluster API 的新手，您的首次體驗可能來自該專案的命令列工具 clusterctl。隨著新的 Cluster API 版本的釋出，它已被重新設計，比以前更令人愉悅。該工具是您只需幾個步驟即可部署您的第一個工作負載叢集所需的全部。

首先，使用 clusterctl init 獲取您的基礎設施和引導提供商的配置，並部署構成 Cluster API 的所有元件。其次，使用 clusterctl config cluster 建立工作負載叢集清單。此清單只是 Kubernetes 物件的集合。要建立工作負載叢集，只需 kubectl apply 該清單。如果此工作流看起來很熟悉，請不要驚訝：使用 Cluster API 部署工作負載叢集就像使用 Kubernetes 部署應用程式工作負載一樣！

Clusterctl 還協助“第二天”操作。使用 clusterctl move 將 Cluster API 自定義資源（例如叢集和機器）從一個管理叢集遷移到另一個。此步驟（也稱為樞軸）對於建立使用 Cluster API 管理自身的工作負載叢集是必要的。最後，當新的 Cluster API 版本可用時，使用 clusterctl upgrade 升級所有已安裝的元件。

還有一件事！Clusterctl 不僅是一個命令列工具。它還是一個 Go 庫！將該庫視為在 Cluster API 之上構建的專案的一個整合點。clusterctl 的所有命令列功能都可以在庫中使用，使其易於整合到您的堆疊中。要開始使用該庫，請閱讀其文件。

Cluster API 手冊

感謝眾多貢獻者！

專案文件內容廣泛。新使用者應瞭解一些架構背景知識，然後透過快速入門建立自己的叢集。clusterctl 工具擁有自己的參考資料。開發者指南為任何有興趣為專案做出貢獻的人提供了大量資訊。

除了內容本身，專案文件網站使用起來也很愉快。它可搜尋，有大綱，甚至支援不同的顏色主題。如果您認為該網站與另一個社群專案 Kubebuilder 的文件非常相似，那並非巧合！非常感謝 Kubebuilder 作者建立瞭如此出色的文件示例。也非常感謝 mdBook 作者建立瞭如此出色的文件構建工具。

整合與定製

端到端測試框架

特別感謝 Chuck Ha

Cluster API 專案旨在實現可擴充套件性。例如，任何人都可以開發自己的基礎設施和引導提供商。然而，重要的是提供商以統一的方式工作。而且，由於專案仍在發展中，因此需要努力確保提供商與核心的新版本保持同步。

端到端測試框架為開發人員提供了一套標準測試，以驗證他們的提供商是否與 Cluster API 的當前版本正確整合，並幫助識別在新的 Cluster API 或提供商版本釋出後發生的任何迴歸。

有關該框架的更多詳細資訊，請參閱 Cluster API 手冊中的測試和儲存庫中的README。

提供商實現者指南

感謝眾多貢獻者！

社群為許多流行的基礎設施維護基礎設施提供商。但是，如果您想構建自己的基礎設施或引導提供商，提供商實現者指南解釋了從建立 git 倉庫到為您的提供商建立 CustomResourceDefinitions，再到設計、實現和測試控制器整個過程。

積極開發中 提供商實現者指南正在積極開發中，可能尚未反映 v1alpha3 版本中的所有更改。

加入我們！

Cluster API 專案是一個非常活躍的專案，涵蓋了許多感興趣的領域。如果您是基礎設施專家，您可以為其中一個基礎設施提供商做出貢獻。如果您喜歡構建控制器，您將找到創新的機會。如果您對測試分散式系統感到好奇，您可以幫助開發專案的端到端測試框架。無論您的興趣和背景如何，您都可以對專案產生真正的影響。

每週例會上，我們都會留出一段時間進行問答環節，屆時請向社群介紹自己。您還可以在 Kubernetes Slack 和 Kubernetes 論壇上找到維護者和使用者。請檢視以下連結。我們期待您的加入！

在 Kubernetes Slack 上與我們聊天： #cluster-api
加入 sig-cluster-lifecycle Google 群組以接收日曆邀請並訪問文件
加入我們的 Zoom 會議，每週三太平洋時間上午 10:00 舉行
在 Cluster API 社群論壇釋出帖子