Cluster API v1alpha3 帶來新功能與更佳的使用者體驗

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

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

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

• 宣告式控制平面管理
• 支援跨故障域分佈控制平面節點以降低風險
• 自動更換不健康的節點
• 支援基礎架構管理的節點群組

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

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

最後，對於任何為其自訂基礎架構或軟體需求擴展 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 基礎架構的 3 副本控制平面的範例，該專案維護用於測試和開發。 為了簡潔起見，未顯示其他必需的資源，如叢集和基礎架構範本，這些資源透過其名稱和命名空間引用。

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 可以與任何提供固定控制平面端點（即負載平衡器或虛擬 IP）的 v1alpha3 相容基礎架構提供者一起使用。 此端點使請求能夠到達多個控制平面副本。

什麼是基礎架構提供者？ 計算資源的來源（例如機器、網路等）。 社群維護 AWS、Azure、Google Cloud 和 VMWare 的提供者。 有關詳細資訊，請參閱 Cluster API Book 中的 提供者列表。

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

特別感謝 Vince Prignano 和 Chuck Ha

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

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

基於 Kubeadm 的 ControlPlane 在故障域之間分佈節點。 為了最大限度地減少在域中斷事件中丟失多個節點的可能性，它會嘗試均勻分佈它們：它會在現有節點最少的故障域中部署一個新節點，並在現有節點最多的故障域中移除一個現有節點。

MachineDeployment 和 MachineSet 不會在故障域之間分佈節點。 若要在多個故障域中部署工作節點，請為每個故障域建立一個 MachineDeployment 或 MachineSet。

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

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

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

自動更換不健康的節點

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

節點可能不健康的原因有很多。 kubelet 進程可能會停止。 容器運行時可能存在錯誤。 核心可能存在記憶體洩漏。 磁碟空間可能不足。 CPU、磁碟或記憶體硬體可能會故障。 可能會發生停電。 像這樣的故障在較大的叢集中尤其常見。

Kubernetes 旨在容忍它們，並幫助您的應用程式也容忍它們。 然而，只有有限數量的節點可能不健康，然後叢集才會耗盡資源，並且 Pod 會被逐出或根本無法排程。 不健康的節點應盡早修復或更換。

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

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

以下是 MachineHealthCheck 的範例。 有關更多詳細資訊，請參閱 Cluster API Book 中的 配置 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 具有虛擬機器擴展集，而 GCP 具有受管實例群組。 透過此 Cluster API 版本，基礎架構提供者可以新增對這些 API 的支援，使用者可以使用 MachinePool 資源部署 Cluster API Machine 群組。 有關更多資訊，請參閱 Cluster API 儲存庫中的 提案。

實驗性功能 MachinePool API 是一個實驗性功能，預設情況下未啟用。 鼓勵使用者嘗試並報告它在多大程度上滿足了他們的需求。

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

clusterctl

特別感謝 Fabrizio Pandini

如果您是 Cluster API 的新手，您的第一個體驗可能是使用專案的命令列工具 clusterctl。 透過新的 Cluster API 版本，它經過重新設計，比以前更令人愉悅。 該工具是您在幾個步驟中部署第一個 工作負載叢集 所需的一切。

首先，使用 clusterctl init 來 獲取 基礎架構和 Bootstrap 提供者的組態，並部署構成 Cluster API 的所有元件。 其次，使用 clusterctl config cluster 來 建立工作負載叢集資訊清單。 此資訊清單只是一組 Kubernetes 物件。 若要建立工作負載叢集，只需 kubectl apply 資訊清單即可。 如果此工作流程看起來很熟悉，請不要感到驚訝：使用 Cluster API 部署工作負載叢集就像使用 Kubernetes 部署應用程式工作負載一樣！

Clusterctl 也有助於「第 2 天」的操作。 使用 clusterctl move 將 Cluster API 自訂資源（如叢集和機器）從一個 管理叢集 遷移 到另一個。 此步驟（也稱為 pivot）對於建立使用 Cluster API 自我管理的工作負載叢集是必要的。 最後，當新的 Cluster API 版本可用時，使用 clusterctl upgrade 來 升級所有已安裝的元件。

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

Cluster API Book

感謝許多貢獻者！

專案的文件 非常廣泛。 新使用者應了解 架構 的一些背景資訊，然後使用 快速入門 建立自己的叢集。 clusterctl 工具本身有 參考。 開發人員指南 包含大量資訊，適用於任何有興趣為專案做出貢獻的人。

除了內容本身之外，專案的文件網站也很樂於使用。 它是可搜尋的，具有大綱，甚至支援不同的顏色主題。 如果您認為該網站很像另一個社群專案 Kubebuilder 的文件，那絕非巧合！ 非常感謝 Kubebuilder 作者創建了出色的文件範例。 並非常感謝 mdBook 作者創建了一個用於建構文件的出色工具。

整合與自訂

端對端測試框架

特別感謝 Chuck Ha

Cluster API 專案旨在具有可擴展性。 例如，任何人都可以開發自己的基礎架構和 Bootstrap 提供者。 但是，重要的是提供者以統一的方式工作。 而且，由於該專案仍在不斷發展，因此需要努力確保提供者與核心的新版本保持同步。

端對端測試框架為開發人員提供了一組標準測試，以驗證其提供者是否與當前版本的 Cluster API 正確整合，並幫助識別在 Cluster API 或提供者的新版本發布後發生的任何回歸。

有關框架的更多詳細資訊，請參閱 Cluster API Book 中的 測試，以及儲存庫中的 README。

提供者實作指南

感謝許多貢獻者！

社群維護了許多流行的基礎架構的 基礎架構提供者。 但是，如果您想建構自己的基礎架構或 Bootstrap 提供者，提供者實作 指南說明了整個過程，從建立 git 儲存庫，到為您的提供者建立 CustomResourceDefinitions，再到設計、實作和測試控制器。

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

加入我們！

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

在我們的每週會議上向社群自我介紹，我們在會議中專門安排了一段時間進行問答環節。 您還可以在 Kubernetes Slack 和 Kubernetes 論壇中找到維護者和使用者。 請查看下面的連結。 我們期待您的加入！

• 在 Kubernetes Slack 上與我們聊天： #cluster-api
• 加入 sig-cluster-lifecycle Google 群組以接收日曆邀請並取得文件存取權
• 每週三太平洋時間 10:00 加入我們的 Zoom 會議
• 發佈到 Cluster API 社群論壇

• ←上一篇
下一篇→