跨多個成員叢集更新 Kubernetes 和節點映像

適用於： ✔️ 車隊管理器 ✔️ 中樞叢集版車隊管理器

管理大量叢集的平台管理員經常會遇到以安全且可預測的方式分階段更新多個叢集 (例如，升級節點作業系統映像或 Kubernetes 版本) 的問題。 為了解決這項挑戰，Azure Kubernetes Fleet Manager 可讓您使用更新執行來協調多個叢集的更新。

更新執行由階段、群組和策略組成，可手動套用 (適用於一次性更新) 或自動套用 (適用於使用自動升級設定檔進行持續定期更新)。 所有更新執行（手動或自動化）都會遵守成員叢集 維護時段。

了解更新執行

下圖將升級回合可視化，其中包含兩個更新階段，每個階段都包含兩個具有兩個成員叢集的更新群組。 第一個階段和第二個階段之間會設定等候期間。

• 更新執行：更新執行代表套用至 AKS 叢集集合的更新，其中包含更新目標和順序。 更新目標代表所需的更新 (例如升級至 Kubernetes 1.28.3 版)。 更新順序描述將更新套用至多個成員叢集的確切順序，以階段和群組表示。 如果未指定，則所有成員叢集都會循序更新。 更新作業可以停止或啟動。
• 更新階段：更新執行分為多個階段，皆會依序套用。 例如，第一個更新階段可能會更新測試環境成員叢集，而第二個更新階段則會接著更新實際執行環境成員叢集。 您可以指定等候時間，在套用後續更新階段之間設定延遲。
• 更新群組：每個更新階段都包含一個或多個更新群組，用來選取要更新的成員叢集。 更新群組也可用來安排更新的應用到成員叢集。 在更新階段內，更新會以平行方式套用至所有不同的更新群組；在更新群組內，成員叢集會循序更新。 機群的每個成員叢集都只能屬於一個更新群組。
• 核准閘道 （預覽版） ：可以在每個階段或群組之前或之後進行設定。 核准會暫停更新程序，讓您或您設定的自動化系統檢查是否可以繼續。 經過您或您的自動化系統批准後，更新執行將繼續。
• 更新策略：更新策略描述具有階段和群組的更新順序，並可讓您重複使用更新執行組態，而不是在每次執行中重複定義順序。 更新策略不包含所需的 Kubernetes 或節點映像版本。

目前，成員叢集上支援的更新作業是升級。 您可以選擇三種類型的升級：

• 升級 Kubernetes 控制平面和節點的 Kubernetes 版本 (包括升級節點映像)。
• 僅升級叢集控制平面的 Kubernetes 版本。
• 只升級節點映像。

您可以指定要升級的目標 Kubernetes 版本，但無法指定確切的目標節點映射版本。 這是因為最新的可用節點映像版本可能會因叢集的 Azure 區域而有所不同（如需詳細資訊，請查看 AKS 發行追蹤器 ）。

系統會根據您的偏好設定自動為您選取目標節點映像版本：

• Latest：當叢集升級開始時，請使用叢集 Azure 區域中可用的最新節點映像。 因此，根據叢集所在的 Azure 區域及其升級的實際開始時間，可以使用不同的映像版本。
• Consistent：當更新執行啟動時，它會在此執行中，跨成員叢集的 Azure 區域挑選 最新的通用 映射版本，如此一來，叢集會使用相同的一致映射版本。

您應該選擇 Latest 來使用較新的映像版本，將安全性風險降到最低，並選擇 Consistent 來改善可靠性，先在較早的階段中使用及驗證叢集中的映像，再將其用於稍後的叢集中。

預定的維修

更新執行會遵循您在 Azure Kubernetes Service (AKS) 叢集層級設定的計劃性維護時段。

AKS 叢集支援兩個不同的維護時段 - 一個用於 Kubernetes (控制平面) 升級，一個用於節點映像升級。 維護時段會定義可將更新套用至叢集的期間，但不是更新觸發器。

機群管理員更新執行會遵循 AKS 維護時段，如下所示：

更新執行會根據計劃性維護，依下列順序排列升級叢集的優先順序：

1. 具有進行中維護時段的成員。
2. 在未來四小時後開啟維護時段的成員。
3. 沒有維護時段的成員。
4. 具有已關閉維護時段的成員。

更新執行狀態

更新執行可以是下列其中一種狀態：

• 未啟動：尚未啟動更新執行。
• 正在執行：至少一個成員叢集的更新執行正在進行中。
• 待處理
  • 成員叢集：成員叢集可能因為下列任一原因而處於狀態 Pending ，可以在訊息欄位中檢視。
    • 維護窗口未開啟。 訊息會指出下一次開啟時間。
    • 成員所在的 Azure 區域目前尚未提供目標 Kubernetes 版本。 AKS 發行追蹤器的訊息連結，讓您可以檢查跨區域發行的狀態。
    • 成員的 Azure 區域尚未提供目標節點映像版本。 訊息會連結到 AKS 發行追蹤器。
  • 更新群組：如果群組中的所有成員皆為 Pending 或尚未開始，或該群組具有 Pending 閘道，則該群組為 Pending。 當成員移至 Pending 時，更新執行會嘗試升級群組中的下一個成員。 如果所有成員都是 Pending，群組就會移至 Pending 狀態。 如果群組為 Pending，則更新執行會等候群組完成，再繼續進行下一個更新階段。
  • 更新階段：如果該階段中的所有更新群組皆為 Pending 或尚未開始，或該階段具有 Pending 閘道，則該階段為 Pending。
  • 執行：如果目前階段處於Pending狀態，則執行處於Pending狀態。
• 略過：可以略過更新執行的所有層級。 略過可以由系統或使用者起始。
  • 成員叢集：
    • 使用者略過成員、群組或階段的更新。
    • 成員叢集已是目標 Kubernetes 版本 (如果更新執行模式為 Full 或 ControlPlaneOnly)。
    • 成員叢集已是目標 Kubernetes 版本，而且所有節點集區都是目標節點映像版本。
    • 為更新執行選擇一致的節點映射時，如果找不到其中一個節點集區的目標映像版本，則會略過該叢集的升級。 例如，當更新執行啟動之後，新增具有新虛擬機 （VM） SKU 的新節點集區時，就會發生此情況。
  • 更新群組：
    • 使用者略過群組的更新。
    • 系統偵測到所有成員叢集的狀態為 Skipped。
  • 更新階段：
    • 使用者略過了階段的更新。
    • 所有在此階段的更新群組都被系統偵測為Skipped。
  • 更新執行：
    • 系統偵測到所有階段的狀態為 Skipped。
• 停止：更新執行的所有層級都可以停止。 有兩種進入停止狀態的可能性：
  • 使用者已停止更新執行，此時更新執行已停止追蹤所有作業。 如果作業已由更新執行起始（例如，叢集升級正在進行中），則該作業不會中止該個別叢集。
  • 如果在更新執行期間遇到失敗（例如其中一個叢集上的升級失敗），整個更新執行就會進入停止狀態。 在更新執行中，不會嘗試對任何後續叢集進行作業。
• 失敗：升級叢集失敗會導致下列動作：
  • 在成員叢集上將 MemberUpdateStatus 標示為 Failed。
  • 將所有父代 (群組 -> 階段 -> 執行) 標示為 Failed，並顯示錯誤訊息摘要。
  • 停止進一步執行更新。
• 已完成：更新執行已順利完成。

了解自動升級設定檔

當新的 Kubernetes 或節點映射版本可供 AKS 使用時，自動升級配置檔可用來自動觸發更新執行。

自動升級設定檔中， 您可以設定：

• a Channel （Stable、Rapid、NodeImage、TargetKubernetesVersion （預覽版）） ，以決定套用至叢集的自動升級類型。
• UpdateStrategy，其會設定叢集升級的順序。 如果未提供策略，叢集會循序更新。
• NodeImageSelectionType（最新、一致）用於指定在升級 Kubernetes 版本時如何選擇節點映像。

穩定頻道

穩定通道一律是次要版本 N-1 上最新的 AKS 支援的 Kubernetes 修補程式版本，其中 N 是最新支援的次要版本。

範例：

• 最新支援的次要 Kubernetes 版本為 1.30。 任何在 1.29 次要範圍中的修補程式版本都會被視為 Stable 通道更新。
• 1.31 的新次要 Kubernetes 版本已發佈。 任何在 1.30 次要範圍中的修補程式版本都會被視為 Stable 通道更新。 任何先前從 1.29 接收更新的叢集，都會更新為 1.30 的最新修補程式。

快速通道

Rapid 通道一律是最新的 AKS 支援的 Kubernetes 次要版本。

範例：

• 最新支援的次要版本是 1.30。 任何在 1.30 次要範圍中的修補程式版本都會被視為 Rapid 通道更新。
• 1.31 的新次要 Kubernetes 版本已發佈。 1.30 會轉移到穩定通道。 任何先前從1.30接收更新的叢集，現在都會更新到1.31的最新修補程式，這是目前的快速通道。

NodeImage 通道

成員叢集節點每週都會使用新修補的 VHD 進行更新，其中包含安全性修正和錯誤修正。 新 VHD 的更新會根據維護時段和激增設定中斷執行。 選擇此選項不會產生額外的 VHD 成本。

如果您使用此通道，Linux 的無人值守升級依預設會被停用。 只要仍支援 Kubernetes 次要版本，節點映像升級就支援已淘汰的修補程式版本。 節點映像經過 AKS 測試，完全管理，並採用安全的部署做法。

不同作業系統上的節點將會根據與這些操作系統一致的節點映像版本來更新。

範例：

• 叢集中有 NodeImage 為 AKSWindows-2022-containerd 版本 20348.2582.240716 的節點。 發行新的 NodeImage 版本 20348.2582.240916 ，且叢集節點會自動升級至 20348.2582.240916 版。

TargetKubernetesVersion 通道 (預覽)

TargetKubernetesVersion 通道可讓您在自動升級設定檔中指定機群，以控制何時將叢集移至下一個 Kubernetes 次要版本。 目標 Kubernetes 版本必須以「{major}.{minor}」格式指定（例如，「1.33」）。 當修補程式可用時，機群自動升級會自動將成員叢集升級至指定目標 Kubernetes 版本的最新修補程式版本。 在您更新自動升級設定檔的目標 Kubernetes 版本之前，Fleet 不會升級至下一個次要版本。

範例：

• 您可以使用 TargetKubernetesVersion 通道建立自動升級設定檔，並指定目標 Kubernetes 版本「1.30」。 新的修補程式版本 1.30.5 已發佈。 更新流程會自動建立，目標為 1.30.5。
• 您可以使用 TargetKubernetesVersion 通道建立自動升級設定檔、指定目標 Kubernetes 版本 “1.29”，並在自動升級設定檔中啟用 LongTermSupport （LTS）。 最新的社群支援次要版本是「1.33」。 新的修補程式版本 1.29.5 已發布。 更新執行程序會自動建立，目標版本為 1.29.5。 附註：如果產生的更新執行包含未啟用 LTS 的叢集，則會失敗。

次要版本略過行為

當有多個次要 Kubernetes 版本差異時，自動升級不會在次要 Kubernetes 版本之間移動叢集 （例如：1.28 到 1.30）。 如果系統管理員擁有多種 Kubernetes 版本，建議您先使用一或多個 更新操作，將成員叢集升級至統一的版本，以確保透過 Stable 設定或 Rapid 通道更新在未來維持一致性。

下一步

• 操作說明：使用 Azure Kubernetes Fleet Manager 更新執行升級多個叢集。
• 操作說明：使用 Azure Kubernetes Fleet Manager 自動升級多個叢集。
• 操作指南：監視 Azure Kubernetes Fleet Manager 的更新作業。
• 多叢集更新常見問答。