Azure Kubernetes Service 修補程式和升級指南

發行項
10/15/2024

Azure Kubernetes Service (AKS) 的第 2 日作業指南說明 AKS 背景工作角色節點和 Kubernetes 版本的修補和升級策略。如果您是叢集作業人員，就需要一套計畫讓叢集保持在最新狀態，並長期監控 Kubernetes API 的變更和取代。

背景和更新類型

AKS 有三種更新類型，每項更新都以彼此為基礎：

更新類型	升級的頻率	支援計劃性維護	支援的作業方法	Target	文件的連結
節點作業系統安全性修補程式	夜間	Yes	自動 (每週)、手動/非受控 (夜間)	節點	自動升級節點映像
節點映像版本升級	Linux：每週 Windows：每月	Yes	自動、手動	節點集區	AKS 節點映像升級
Kubernetes 版本 (叢集) 升級	每季	Yes	自動、手動	叢集與節點集區	AKS 叢集升級

更新類型

節點作業系統安全性修補程式 (僅限 Linux)。 如果是 Linux 節點，Canonical Ubuntu 和 Azure Linux 每天都會提供一次作業系統安全性修補程式。 Microsoft 會在每週更新節點映像時測試這些修補程式並組合成套件。
節點映像每週更新。 AKS 會提供節點映像的每週更新。這些更新包括最新的作業系統和 AKS 安全性修補程式、錯誤修正和增強功能。節點更新並不會變更 Kubernetes 版本。 Linux 會依據日期來格式化版本 (例如 202311.07.0)，Windows 則會依據 Windows Server OS 版本和日期 (例如 20348.2113.231115)。如需詳細資訊，請參閱 AKS 版本狀態。
每季的 Kubernetes 版本。 AKS 會每季更新 Kubernetes 版本。這些更新讓 AKS 使用者能夠運用最新的 Kubernetes 功能和增強功能。其中包括安全性修補程式與節點映像更新。如需詳細資訊，請參閱 AKS 支援的 Kubernetes 版本。

升級前的考量

對整體叢集的影響

就地升級 (無論節點或叢集) 的過程會影響 Kubernetes 環境的效能。透過適當地設定 Pod 中斷預算、節點激增設定和妥善規劃，您就能將此影響降到最低。
以藍/綠更新策略來取代就地升級，可消除叢集效能受到的任何影響，但會增加成本和複雜性。
無論採取何種升級和修補策略，您都需要為叢集計畫一套可靠的測試和驗證程序。先修補和升級較低版本的環境，再執行維護後驗證，藉此確認叢集、節點、部署和應用程式的健康情況。

AKS 工作負載的最佳做法

若要確保 AKS 叢集在維護期間順利運作，請遵照以下最佳做法：

定義 Pod 中斷預算 (PDB)。 為您的部署設定 Pod 中斷預算是必要的動作。 PDB 會強制執行最低數量的應用程式可用複本，確保中斷事件期間的持續運作。 PDB 有助於讓叢集在維護或節點失敗期間維持穩定性。

警告

PDB 若設定錯誤，可能會阻礙升級程序，因為 Kubernetes API 會使輪流節點映像升級時所需的隔離和清空無法執行。此外，如果同時移動過多 Pod，可能會發生應用程式中斷。 PDB 設定可降低這類風險。
檢查可用的計算和網路限制。 若要確認 Azure 訂用帳戶可用的計算和網路限制，可透過 Azure 入口網站的配額頁面，或使用 az quota 命令。檢查節點的計算和網路資源 (尤其是 VM vCPU)，以及虛擬機器和虛擬機器擴展集的數量。如果已接近限制，請先要求增加配額再升級。
檢查節點子網路的可用 IP 空間。 更新期間，叢集會建立額外的激增節點，而 Pod 會移至這些節點。監控節點子網路中的 IP 位址空間非常重要，這是為了確保足夠的位址空間來進行這些變更。不同的 Kubernetes 網路設定有不同的 IP 需求。開始操作時，請先審視下列考量：
- 升級期間，節點 IP 數量會根據您的激增值而增加。 (最小激增值為 1。)
- 以 Azure CNI 為基礎的叢集會將 IP 位址指派給個別 Pod，因此需要足夠的 IP 空間才能讓 Pod 移動。
- 您的叢集在升級期間會繼續運作。請確定剩下的 IP 空間足以進行節點調整 (如已啟用)。
設定多個環境。 建議您分別設定環境，例如開發、暫存和生產，以便您先進行測試和驗證，再將變更推出至生產環境。
調整激增升級值。 根據預設，AKS 的激增值為 1，也就是說，升級過程中一次建立一個額外節點。您可以增加此值，藉此增加 AKS 升級的速度。如果工作負載對中斷較敏感，建議將激增值調整至最多 33%。如需詳細資訊，請參閱自訂節點激增升級。
調整節點清空逾時。節點清空逾時會指定叢集嘗試在更新中的節點重新排程 Pod 時，等候的時間上限。此設定的預設值為 30 分鐘。如果工作負載難以重新排程 Pod，調整此預設值很有用。
規劃與安排維護時段。 升級程序可能會影響 Kubernetes 叢集的整體效能。將就地升級程序安排在尖峰使用時段之外，並監控叢集效能，可確保充分調整大小，尤其是更新程序期間。
檢查叢集的其他相依性。 Kubernetes 運算子通常會將其他工具部署至 Kubernetes 叢集當成作業的一部分，例如 KEDA Scaler、Dapr 和服務網格。在規劃升級程序時，針對您用來確保與目標版本相容的任何元件，請檢查版本資訊。

管理節點映像的每週更新

Microsoft 大約每週一次為 AKS 節點建立新的節點映像。節點映像包含最新的作業系統安全性修補程式、OS 核心程序更新、Kubernetes 安全性更新、二進位檔更新版本 (例如 kubelet)，以及列在版本資訊中的元件版本更新。

更新節點映像時，系統會在目標節點集區的節點上觸發隔離和清空動作：

更新映像的節點會加到節點集區中。同一時間，激增值會控管新增的節點數量。
系統會根據激增值，隔離並清空一批現有節點。隔離可確保節點不會排程 Pod。清空則會將 Pod 移除並排程給其他節點。
當這些節點完全清空後，它們就會從節點集區中移除。激增所新增的更新節點會取代這些節點。
節點集區中如果還有剩餘節點需要更新，系統就會對每個批次重複執行此程序。

同樣的程序會在叢集升級期間發生。

自動節點映像升級

一般而言，大部分的叢集都會使用 NodeImage 更新管道。此管道每週都會提供更新的節點映像 VHD，並根據叢集的維護時段進行更新。

下列為可用的管道：

None. 系統不會自動套用任何更新。
Unmanaged. 作業系統會在夜間套用 Ubuntu 和 Azure Linux 更新。您必須另行管理重新開機。對於此程序的步調，AKS 既無法測試也無法控制。
SecurityPatch. 作業系統安全性修補程式係經過 AKS 測試、完全受管，並採用安全部署做法。它不包含任何作業系統錯誤修正，只有安全性更新。
NodeImage. AKS 每週會使用新修補的 VHD 更新節點，該 VHD 中包含安全性修正和 Bug 修正。此程序經過完整測試，且部署時採用安全部署做法。如需即時瞭解目前部署的節點映像，請參閱 AKS 節點映像更新。

若想瞭解未建立維護時段的預設更新步調，請參閱更新擁有權和步調。

如果您選擇 Unmanaged 更新管道，您需要使用 kured 這類工具來管理重新開機過程。 Unmanaged 並不會隨附 AKS 提供的安全部署做法，且在維護期間無法運作。如果您選擇 SecurityPatch 更新管道，每週都可套用更新。您的資源群組需要儲存 VHD 才能使用此修補程式層級，這會產生名義上的費用。設定適當的 aksManagedNodeOSUpgradeSchedule 來配合您的工作負載最合適的步調，藉此控制套用 SecurityPatch 的時機。如需詳細資訊，請參閱建立維護時段。如果您也需要通常會與新節點映像 (VHD) 一並提供的錯誤修正，您需要選擇 NodeImage 管道，而不是 SecurityPatch。

最佳做法是使用 NodeImage 更新管道，並將 aksManagedNodeOSUpgradeSchedule 維護時段設在叢集不在尖峰使用時段的時間。如需瞭解可用來設定叢集維護時段的屬性，請參閱建立維護時段。重要屬性有：

name. 將 aksManagedNodeOSUpgradeSchedule 用於節點作業系統更新。
utcOffset. 設定時區。
startTime. 設定維護時段的開始時間。
dayofWeek. 設定時段內的週間日期。例如： Saturday 。
schedule. 設定時段的頻率。如需 NodeImage 更新，建議使用 weekly。
durationHours. 將此屬性設為至少四小時。

以下範例將每週維護時段設為東部時間週六晚上 8:00：

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

如需更多範例，請參閱使用 Azure CLI 新增維護時段設定。

理想情況下，此設定在叢集中的部署方式是基礎結構即程式碼。

您可以使用 Azure CLI 來檢查已設定的維護時段：

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

您也可以使用 CLI 來檢查特定維護時段的詳細資訊：

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

如未設定叢集維護時段，節點映像更新會每兩週進行一次。在設定的時段內，AKS 維護能執行幾次就會執行幾次，但維護時間則不保證。

重要

如果您的節點集區有大量節點但未設定節點激增，自動升級事件可能就不會觸發。節點集區中的節點映像只會在預估的升級總時間在 24 小時內才會升級。

在此情況下，您可以考慮執行以下其一動作：

如果 vCPU 配額幾乎已滿，且您無法增加 vCPU 配額，請將節點分割成不同的節點集區
如果您的 vCPU 配額足夠，請設定節點激增來減少預估升級時間

您可以透過 Azure 活動記錄或檢查叢集上的資源記錄，藉此確認升級事件的狀態。

您可以訂閱內含 Azure 事件方格的 Azure Kubernetes Service (AKS) 事件，其中就包含 AKS 升級事件。這些事件可在新版 Kubernetes 推出時發出提示，且有助於在升級程序期間追蹤節點狀態變更。

您也可以使用 GitHub Actions 來管理每週更新程序。此方法可更細微地控制更新程序。

手動節點更新程序

您可以使用 kubectl describe nodes 命令來判斷叢集中節點的作業系統核心程序版本和作業系統映像版本：

kubectl describe nodes <NodeName>

範例輸出 (已截斷)：

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

使用 Azure CLI az aks nodepool list 命令來判斷叢集中節點的節點映像版本：

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

範例輸出：

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

使用 az aks nodepool get-upgrades 來判斷特定節點集區最新的可用節點映像版本：

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

範例輸出：

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

叢集升級

Kubernetes 社群大約每隔三個月就會發行 Kubernetes 的次要版本。為了讓您持續得知 AKS 新版和發布資訊，AKS 版本資訊頁面會定期更新。您也可以訂閱 GitHub AKS RSS 摘要，以便即時取得變更和增強功能的更新。

AKS 遵循 N - 2 支援原則，也就是說，最新版 (N) 和前兩個舊的次要版本皆可獲得完整支援。往前第三個舊版的次要版本擁有的平台支援則有限。如需詳細資訊，請參閱 AKS 支援原則。

若要確保 AKS 叢集持續受到支援，您必須建立連續的叢集升級程序。此程序必須在低階環境測試新版，並在新版變成預設之前先規劃如何升級至生產環境。這種方法可以維持升級程序的可預測性，並將應用程式的中斷降到最低。如需詳細資訊，請參閱升級 AKS 叢集。

如果您的叢集需要更長的升級週期，請使用 AKS 版本來支援長期支援 (LTS) 選項。如果您啟用 LTS 選項，Microsoft 為 Kubernetes 版本提供兩年的延長支援，藉此提供更長期且受控的升級週期。如需詳細資訊，請參閱 AKS 支援的 Kubernetes 版本。

叢集升級包含節點升級，且運用類似的隔離和清空程序。

升級之前

最佳做法是一律在低階的環境升級和測試，藉此將生產中斷的風險降到最低。叢集升級需要額外的測試，因為這牽涉到 API 變更，它可能會影響 Kubernetes 部署。下列資源可協助您進行升級程序：

以 AKS 活頁簿檢查已淘汰的 API。 從 Azure 入口網站的叢集概觀頁面，您可以選取 [診斷並解決問題]，前往 [建立、升級、刪除和調整大小] 類別，然後選取 [Kubernetes API 取代]。這麼動作會執行活頁簿，檢查叢集中使用的已淘汰 API 版本。如需詳細資訊，請參閱解除使用已淘汰的 API。
AKS 版本資訊頁面。此頁面提供新版 AKS 和發行的相關完整資訊。請參閱這些備註，以便持續掌握最新的更新和變更。
Kubernetes 版本資訊頁面。此頁面提供最新版 Kubernetes 的詳細深入解析。請特別注意緊急的升級備註事項，內容會強調可能對 AKS 叢集有影響的重要資訊。
AKS 元件各版本的重大變更。下表依照版本提供 AKS 元件重大變更的完整概觀。參考本指南，您就能在升級程序之前主動解決任何潛在的相容性問題。

除了這些 Microsoft 資源之外，也可考慮使用開放原始碼工具來最佳化叢集升級程序。其中一種工具是 Fairwinds pluto，它會掃描您的部署和 Helm 圖表，尋找已淘汰的 Kubernetes API。這些工具可協助您確保應用程式與最新版 Kubernetes 維持相容。

升級程序

若要檢查叢集何時需要升級，請使用 az aks get-upgrades 取得 AKS 叢集的可用升級版本清單。從結果判斷叢集的目標版本。

以下是範例：

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

範例輸出：

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

在節點集區查看節點的 Kubernetes 版本，藉此判斷需要升級的集區：

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

範例輸出：

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

手動升級

若要盡可能減少中斷，並確保 AKS 叢集順暢升級，請遵循以下升級方法：

升級 AKS 控制平面。 先從升級 AKS 控制平面開始。此步驟要升級的控制平面元件專門用於管理和協調叢集。優先升級控制平面再升級個別節點集區，有助於確保相容性和穩定性。
升級您的系統節點集區。 升級控制平面後，再升級 AKS 叢集的系統節點集區。節點集區是由執行應用程式工作負載的虛擬機器執行個體所組成。分別升級節點集區，可讓支援應用程式的基礎結構在升級時受控且有系統性。
升級使用者節點集區。 升級系統節點集區後，請升級 AKS 叢集的任何使用者節點集區。

遵循這種方法，您就能將升級程序期間的中斷降到最低，並維持應用程式的可用性。詳細步驟如下：

執行 az aks upgrade 命令並加上 --control-plane-only 標幟，藉此只升級叢集控制平面，而不是叢集的節點集區：

az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>

執行 az aks nodepool upgrade 將節點集區升級至目標版本：
```
az aks nodepool upgrade \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
   --no-wait --kubernetes-version <KubernetesVersion>
```
在節點集區升級期間，AKS 會建立激增節點、在升級中的節點隔離和清空 Pod、重新安裝節點映像，然後取消隔離 Pod。然後，此程序會針對節點集區中的任何其他節點重複步驟。

您可以執行 kubectl get events 來檢查升級程序的狀態。如需瞭解如何對叢集的升級問題進行疑難排解，請參閱 AKS 疑難排解文件。

在自動升級的發布管道註冊叢集

AKS 也提供自動叢集升級解決方案，讓叢集保持最新狀態。如果使用此解決方案，您應該搭配設定維護時段，藉此控制升級的時機。升級時段必須至少四小時。在發布管道註冊叢集時，Microsoft 會自動管理叢集及其節點集區的版本和升級步調。

叢集自動升級提供不同的發布管道選項。以下是建議的環境和發布管道設定：

Environment	升級管道	描述
生產	`stable`	如需穩定性和版本成熟度，請使用穩定或一般管道來執行生產工作負載。
暫存、測試、開發	和生產環境相同	若要確保測試指出您的生產環境要升級的版本，請使用與生產環境相同的發布管道。
Canary	`rapid`	若要測試最新 Kubernetes 版本和新的 AKS 功能或 API，請使用 `rapid` 管道。 `rapid` 的版本升級到您用於生產環境的管道時，您就可以提升上市時間。

考量

下表說明各種 AKS 升級的特性和修補案例：

案例	使用者起始	Kubernetes 升級	作業系統核心程序升級	節點映像升級
安全性修補	No	No	是，重新開機後	Yes
叢集建立	Yes	可能	是，如果更新的節點映像使用更新的核心程序	是，如有新版可用，則與現有叢集相對
控制平面的 Kubernetes 升級	Yes	是	無	No
節點集區的 Kubernetes 升級	Yes	Yes	是，如果更新的節點映像使用更新的核心程序	是，如有新版可用
節點集區擴大	是	無	無	No
節點映像升級	是	No	是，如果更新的節點映像使用更新的核心程序	Yes
叢集自動升級	No	Yes	是，如果更新的節點映像使用更新的核心程序	是，如有新版可用

將作業系統安全性修補程式套用到節點映像升級中時，安裝的核心程序版本可能比建立新叢集時安裝的版本更新。
節點集區擴大時使用的模型與目前的虛擬機器擴展集有關聯。作業系統核心程序會在套用安全性修補程式並重新啟動節點後升級。

參與者

本文由 Microsoft 維護。原始投稿人如下。

主要作者：

Anthony Nevico | 首席雲端解決方案架構師

其他投稿人：

Rishabh Saha | 首席解決方案架構師
Paolo Salvatori | FastTrack for Azure 首席客戶工程師
Ali Yousefi | 雲端解決方案架構師

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

共用方式為

Azure Kubernetes Service 修補程式和升級指南

背景和更新類型

更新類型

升級前的考量

對整體叢集的影響

AKS 工作負載的最佳做法

管理節點映像的每週更新

自動節點映像升級

手動節點更新程序

叢集升級

升級之前

升級程序

手動升級

在自動升級的發布管道註冊叢集

考量

參與者

下一步

意見反應

其他資源

共用方式為

Azure Kubernetes Service 修補程式和升級指南

背景和更新類型

更新類型

升級前的考量

對整體叢集的影響

AKS 工作負載的最佳做法

管理節點映像的每週更新

自動節點映像升級

手動節點更新程序

叢集升級

升級之前

升級程序

手動升級

在自動升級的發布管道註冊叢集

考量

參與者

下一步

相關資源

意見反應

其他資源