將複寫的控制平面遷移至使用雲端控制器管理員

cloud-controller-manager 是一個 Kubernetes 控制平面元件，其中嵌入了雲端特定的控制邏輯。雲端控制器管理員可讓您將叢集連結到您的雲端供應商的 API，並將與該雲端平台互動的元件，與僅與您的叢集互動的元件分離開來。

透過分離 Kubernetes 和底層雲端基礎架構之間的互操作性邏輯，cloud-controller-manager 元件使雲端供應商能夠以不同於主要 Kubernetes 專案的速度發布功能。

背景

作為雲端供應商提取工作的一部分，所有雲端特定的控制器都必須從 kube-controller-manager 中移出。所有在 kube-controller-manager 中執行雲端控制器的現有叢集都必須遷移，以便在雲端供應商特定的 cloud-controller-manager 中執行控制器。

領導者遷移提供了一種機制，透過此機制，HA 叢集可以在升級複寫的控制平面時，透過 kube-controller-manager 和 cloud-controller-manager 之間共用的資源鎖定，安全地在 kube-controller-manager 和 cloud-controller-manager 之間遷移「雲端特定的」控制器。對於單節點控制平面，或者如果可以容忍控制器管理員在升級期間不可用，則不需要領導者遷移，並且可以忽略本指南。

可以透過在 kube-controller-manager 或 cloud-controller-manager 上設定 --enable-leader-migration 來啟用領導者遷移。領導者遷移僅在升級期間適用，並且在升級完成後可以安全地停用或保持啟用狀態。

本指南將引導您完成從具有內建雲端供應商的 kube-controller-manager 升級控制平面到同時執行 kube-controller-manager 和 cloud-controller-manager 的手動過程。如果您使用工具來部署和管理叢集，請參閱該工具和雲端供應商的文件，以取得有關遷移的特定說明。

開始之前

假設控制平面正在執行 Kubernetes N 版本，並且將升級到 N + 1 版本。雖然可以在相同版本內遷移，但理想情況下，遷移應作為升級的一部分執行，以便配置變更可以與每個版本對齊。N 和 N + 1 的確切版本取決於每個雲端供應商。例如，如果雲端供應商建置與 Kubernetes 1.24 協同運作的 cloud-controller-manager，則 N 可以是 1.23，而 N + 1 可以是 1.24。

控制平面節點應執行已啟用領導者選舉的 kube-controller-manager，這是預設行為。從 N 版本開始，必須使用 --cloud-provider 旗標設定樹內雲端供應商，且尚不應部署 cloud-controller-manager。

樹外雲端供應商必須已建置具有領導者遷移實作的 cloud-controller-manager。如果雲端供應商匯入 v0.21.0 或更新版本的 k8s.io/cloud-provider 和 k8s.io/controller-manager，則領導者遷移將會可用。但是，對於 v0.22.0 之前的版本，領導者遷移為 Alpha 階段，並且需要在 cloud-controller-manager 中啟用功能閘道 ControllerManagerLeaderMigration。

本指南假設每個控制平面節點的 kubelet 啟動 kube-controller-manager 和 cloud-controller-manager 作為由其 Manifest 定義的靜態 Pod。如果元件在不同的設定中執行，請相應地調整步驟。

關於授權，本指南假設叢集使用 RBAC。如果另一個授權模式授予 kube-controller-manager 和 cloud-controller-manager 元件權限，請以符合該模式的方式授予所需的存取權。

授予遷移 Lease 的存取權

控制器管理器的預設權限僅允許存取其主要 Lease。為了使遷移能夠運作，需要存取另一個 Lease。

您可以透過修改 system::leader-locking-kube-controller-manager 角色，授予 kube-controller-manager 對 Lease API 的完整存取權。本任務指南假設遷移 Lease 的名稱為 cloud-provider-extraction-migration。

kubectl patch -n kube-system role 'system::leader-locking-kube-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge`

對 system::leader-locking-cloud-controller-manager 角色執行相同的操作。

kubectl patch -n kube-system role 'system::leader-locking-cloud-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge`

初始領導者遷移配置

領導者遷移可選擇採用一個配置檔案，表示控制器到管理器的分配狀態。目前，使用樹內雲端供應商，kube-controller-manager 執行 route、service 和 cloud-node-lifecycle。以下範例配置顯示了分配情況。

可以在沒有配置的情況下啟用領導者遷移。請參閱預設配置以取得詳細資訊。

kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
resourceLock: leases
controllerLeaders:
  - name: route
    component: kube-controller-manager
  - name: service
    component: kube-controller-manager
  - name: cloud-node-lifecycle
    component: kube-controller-manager

或者，由於控制器可以在任一控制器管理器下執行，因此將雙方的 component 設定為 * 可使配置檔案在遷移的雙方之間保持一致。

# wildcard version
kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
resourceLock: leases
controllerLeaders:
  - name: route
    component: *
  - name: service
    component: *
  - name: cloud-node-lifecycle
    component: *

在每個控制平面節點上，將內容儲存到 /etc/leadermigration.conf，並更新 kube-controller-manager 的 Manifest，以便將檔案掛載到容器內的相同位置。此外，更新相同的 Manifest 以新增以下引數

--enable-leader-migration 以在控制器管理器上啟用領導者遷移
--leader-migration-config=/etc/leadermigration.conf 以設定配置檔案

在每個節點上重新啟動 kube-controller-manager。此時，kube-controller-manager 已啟用領導者遷移，並已準備好進行遷移。

部署雲端控制器管理器

在 N + 1 版本中，控制器到管理器的期望分配狀態可以用新的配置檔案表示，如下所示。請注意每個 controllerLeaders 的 component 欄位從 kube-controller-manager 變更為 cloud-controller-manager。或者，使用上述萬用字元版本，效果相同。

kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
resourceLock: leases
controllerLeaders:
  - name: route
    component: cloud-controller-manager
  - name: service
    component: cloud-controller-manager
  - name: cloud-node-lifecycle
    component: cloud-controller-manager

在建立 N + 1 版本的控制平面節點時，應將內容部署到 /etc/leadermigration.conf。應更新 cloud-controller-manager 的 Manifest，以與 N 版本的 kube-controller-manager 相同的方式掛載配置檔案。同樣地，將 --enable-leader-migration 和 --leader-migration-config=/etc/leadermigration.conf 新增至 cloud-controller-manager 的引數。

建立一個具有更新的 cloud-controller-manager Manifest 的 N + 1 版本的新控制平面節點，並將 kube-controller-manager 的 --cloud-provider 旗標設定為 external。N + 1 版本的 kube-controller-manager 絕不能啟用領導者遷移，因為使用外部雲端供應商時，它不再執行遷移的控制器，因此不參與遷移。

請參閱雲端控制器管理器管理，以取得有關如何部署 cloud-controller-manager 的更多詳細資訊。

升級控制平面

控制平面現在包含 N 和 N + 1 版本的節點。N 版本的節點僅執行 kube-controller-manager，而 N + 1 版本的節點同時執行 kube-controller-manager 和 cloud-controller-manager。遷移的控制器（如配置中所指定）在 N 版本的 kube-controller-manager 或 N + 1 版本的 cloud-controller-manager 下執行，具體取決於哪個控制器管理器持有遷移 Lease。任何控制器在任何時候都不會在兩個控制器管理器下同時執行。

以滾動方式，建立一個新的 N + 1 版本的控制平面節點，並關閉一個 N 版本的節點，直到控制平面僅包含 N + 1 版本的節點。如果需要從 N + 1 版本回滾到 N 版本，請將啟用了 kube-controller-manager 領導者遷移的 N 版本節點新增回控制平面，每次替換一個 N + 1 版本的節點，直到只剩下 N 版本的節點。

（選用）停用領導者遷移

現在控制平面已升級為同時執行 N + 1 版本的 kube-controller-manager 和 cloud-controller-manager，領導者遷移已完成其工作，可以安全地停用以節省一個 Lease 資源。為了將來回滾，可以安全地重新啟用領導者遷移。

以滾動管理器的方式，更新 cloud-controller-manager 的 Manifest 以取消設定 --enable-leader-migration 和 --leader-migration-config= 旗標，同時移除 /etc/leadermigration.conf 的掛載，最後移除 /etc/leadermigration.conf。若要重新啟用領導者遷移，請重新建立配置檔案，並將其掛載和啟用領導者遷移的旗標新增回 cloud-controller-manager。

預設配置

從 Kubernetes 1.22 開始，領導者遷移提供適用於預設控制器到管理器分配的預設配置。可以透過設定 --enable-leader-migration 但不設定 --leader-migration-config= 來啟用預設配置。

對於 kube-controller-manager 和 cloud-controller-manager，如果沒有任何旗標啟用任何樹內雲端供應商或變更控制器的所有權，則可以使用預設配置來避免手動建立配置檔案。

特殊情況：遷移 Node IPAM 控制器

如果您的雲端供應商提供 Node IPAM 控制器的實作，您應該切換到 cloud-controller-manager 中的實作。透過在 N + 1 版本的 kube-controller-manager 的旗標中新增 --controllers=*,-nodeipam 來停用 Node IPAM 控制器。然後將 nodeipam 新增至遷移的控制器清單中。

# wildcard version, with nodeipam
kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
resourceLock: leases
controllerLeaders:
  - name: route
    component: *
  - name: service
    component: *
  - name: cloud-node-lifecycle
    component: *
  - name: nodeipam
-   component: *

下一步

閱讀控制器管理器領導者遷移增強提案。

上次修改時間：2024 年 12 月 04 日上午 11:27 PST：Update controller-manager-leader-migration.md (f1d5525f85)