共用方式為

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

  • 發行項

管理大量叢集的平臺管理員通常會以安全且可預測的方式，在預備多個叢集的更新時發生問題（例如，升級節點OS映像或 Kubernetes 版本）。 為了解決這項挑戰，Azure Kubernetes Fleet Manager （Fleet） 可讓您使用更新執行跨多個叢集協調更新。

更新執行包含階段、群組和策略，而且可以手動套用一次性更新，或使用自動升級配置檔進行中的一般更新。 所有更新執行 （手動或自動化） 都會接受成員叢集 維護視窗。

瞭解更新執行

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

顯示升級執行的圖表，其中包含兩個更新階段，每個階段都包含兩個具有兩個成員叢集的更新群組。

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

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

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

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

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

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

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

預定的維修

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

在更新執行中 (針對循序或階段類型的更新執行)，更新執行會依下列順序排列升級叢集的優先順序：

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

更新執行狀態

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

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

注意

您可以隨時重新執行更新執行，以重新套用可能已略過或失敗的升級。

了解自動升級設定檔 （預覽）

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

重要

Azure Kubernetes 機群管理員預覽功能由客戶自行決定取用。 預覽會以「現狀」和「可供使用時」提供，其其不受服務等級協定和有限瑕疵擔保所保護。 客戶支援部門會竭盡全力支援一部分的 Azure Kubernetes 機群管理員預覽功能。 因此，這些功能不適合實際執行用途。

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

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

穩動通道

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

範例：

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

快速通道

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

範例：

  • 最新支援的次要版本是 1.30。 1.30 次要範圍中的任何修補程式版本都會被視為快速通道更新。
  • 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 版。

次要版本略過行為

當次要 Kubernetes 版本有一個以上的次要 Kubernetes 版本差異時，自動升級不會移動叢集（例如：1.28 至 1.30）。 如果系統管理員有一組多樣化的 Kubernetes 版本，建議您先使用一或多個 更新執行 ，將成員叢集帶入一組一致的版本設定版本，讓 Stable 設定或 Rapid 通道更新確保未來維持一致性。

注意

使用自動升級時，請記住下列資訊：

  • 自動升級需要 1.3.0 版或更新版本的 Fleet Azure CLI 擴充功能。

  • 僅將更新升級為 GA 版本的 Kubernetes，且不會更新為預覽版本。

  • 自動升級需要叢集的 Kubernetes 版本位於 AKS 支援視窗中。

  • 如果叢集沒有定義的計劃性維護時間範圍，當更新執行到達叢集時，將會立即升級。

  • 如果您要升級 Kubernetes 版本，您必須使用 或 Stable 通道建立autoupgradeprofile Rapid

  • 如果您要升級 NodeImage 版本，您需要使用通道建立 autoupgradeprofile NodeImage 。

  • 您可以為相同的機隊建立多個自動升級配置檔。

下一步