Azure Kubernetes Service （AKS）叢集的升級選項和建議

適用於: ✔️ AKS 自動化 ✔️ AKS 標準

對大多數生產工作負載來說，AKS Automatic 是推薦的預設叢集體驗。它為叢集與節點生命週期作業提供生產準備的預設值，包括受管理升級行為、內建防護措施及降低營運開銷。

AKS 標準仍適用於需要更深入手動控制升級機制、網路選擇或節點池行為的情境。

本文將AKS升級提供技術基礎，涵蓋升級選項、常見情境，以及AKS自動與AKS標準的建議。

本文涵蓋的內容

本技術參考涵蓋：

為什麼 AKS Automatic 是適用於大多數工作負載的建議生產就緒預設選項。
AKS 自動與 AKS 標準版升級行為的差異。
手動升級路徑與自動升級路徑，以及何時使用。
常見的升級案例及具體建議。
效能和最少中斷的最佳化技術。
驗證流程和升級前檢查。

相關指引：

關於 AKS Automatic 概述與預設值，請參閱 Azure Kubernetes Service （AKS） Automatic 簡介。
關於生產導向的AKS升級策略細節，請參見 AKS生產升級策略。
關於有狀態工作負載升級模式，請參見有狀態工作負載升級模式。
關於情境導向的指引，請參見 AKS 升級情境：選擇你的路徑。
如果你是 AKS 升級新手，建議先從升級情境中心開始，獲得指導協助。

您的情況	建議的路徑
新舊生產工作負載，無需特殊客製化需求	建立 AKS 自動叢集
具備嚴格自訂升級控制的生產叢集	生產升級策略
資料庫或具狀態的工作負載	具狀態工作負載模式
首次升級 AKS 標準	基本 AKS 叢集升級
多重環境或艦隊作業	升級案例中樞
節點池或 Windows 節點在 AKS 標準中	節點集區升級
僅限特定的節點集區	單一節點集區升級

升級操作模型

AKS 自動（建議作為生產環境預設值）

AKS Automatic 預設即專為可直接用於生產環境的運作而設計。升級方面，AKS Automatic 提供：

受管理的系統節點集區。
採用平台管理預設值的自動叢集升級行為
以安全為核心的自動節點 OS 映像升級行為。
內建已取代 Kubernetes API 的檢查功能。
計畫性維護排程支援。

當您想要將手動協調升級流程的需求降到最低，並以更少的人工作業讓生產叢集維持在受支援的版本時，請使用 AKS Automatic。

AKS 標準（進階控制模型）

AKS Standard 讓你直接掌控升級順序和調校。你選擇並管理：

手動或自動升級配置。
升級頻道選擇。
節點集區與擴增行為。
有關維護時段與工作負載中斷預算的作業程序。

當你的環境需要超出 AKS 自動預設的自訂時，使用 AKS 標準。

升級選項

執行手動升級

主要適用於 AKS 標準，或專門的作業工作流程。

手動升級可讓您控制叢集何時升級至新的 Kubernetes 版本。這些升級對於測試、分階段部署及目標版本採用都很有用。

設定自動升級

對於 AKS 標準，自動升級有助於將叢集維持在支援版本，同時保留對政策與排程的控制權。在 AKS 自動中，升級自動化與護欄已是預設操作模式的一部分。

跨多個可用性區域的節點集區特殊考量

AKS 在節點集區中使用最佳效力的區域平衡。在升級激增期間，虛擬機器擴展集中的激增節點區域事先未知，這可能會暫時造成不平衡的區域設定。 AKS 會在升級后刪除激增節點，並還原原始區域平衡。

若要保持區域平衡，請將激增設定為三個節點的倍數。使用 Azure 本地備援儲存體磁碟的永續性磁碟區宣告繫結於區域，如果激增節點位於不同的區域，可能會導致停機。使用 Pod 中斷預算 (PDB) 以在清空期間維持高可用性。

最佳化升級以改善效能，並將中斷降至最低

結合計畫維護時段、最大突波、 PDB、節點排水逾時及節點吸收時間，以增加成功且低干擾升級的可能性。

AKS 自動化系统

在 AKS Automatic 中，平台層級的升級行為是預先設定好的。將調整重點放在工作負載韌性與產能準備度：

驗證 Pod 中斷預算與複本計數。
確保配額及子網容量以應付預期成長。
設定與低流量時段相符的計畫性維護時程。
監控升級事件及關鍵工作負載準備度。

AKS 標準

在 AKS Standard 中，可直接調整升級控制：

計劃性維護期間：在低流量期間排程自動升級。至少使用四小時。
最大激增：更高的值可以加快升級速度，但可能會中斷工作負載。將 33% 用於生產。
無法使用上限：當容量有限時使用。
Pod 中斷預算：設定以限制升級期間可被中斷的 Pod 數量。針對您的服務進行驗證。
節點清空逾時：設定 Pod 收回的等候持續時間。預設值為 30 分鐘。
節點浸泡時間：錯開升級以將停機時間降到最低。預設值是 0 分鐘。

升級設定	如何使用額外的節點	預期的行為
`maxSurge=5`、`maxUnavailable=0`	5 個激增節點	激增五個節點來進行升級。
`maxSurge=5`、`maxUnavailable=0`	0-4 個激增節點	升級失敗，因為激增節點數不足。
`maxSurge=0`、`maxUnavailable=5`	N/A	清空五個現有的節點來進行升級。

備註

升級之前，請先檢查 API 是否有重大變更，並檢閱 AKS 發行備註以避免升級中斷。

在升級到 Kubernetes 1.37 前，先驗證 LocalDNS 和自訂 DNS

從 Kubernetes 1.37 開始，AKS 預設一個沒有明確 LocalDNS 設定檔的 AKS Standard 節點池進入 Preferred 模式，當節點池通過相容性檢查時啟用 LocalDNS。此變更會影響工作負載 DNS 路徑，並可能暴露支援 UDP 埠 53 但不支援 TCP 埠 53 的自訂 DNS 或防火牆設定。

在將節點池升級到 Kubernetes 1.37 或更新版本之前：

檢查節點池是否有明確的 LocalDNS 設定檔。
從 AKS 節點透過 UDP 和 TCP 測試自訂虛擬網路 DNS 伺服器。
```
dig +udp @<custom-dns-ip> <fqdn>
dig +tcp @<custom-dns-ip> <fqdn>
```
確認 NSG、防火牆、NVA 和路由是否同時允許 UDP 和 TCP 埠 53。
先升級非生產節點池，並監控 CoreDNS 和 LocalDNS 錯誤。
如果 DNS 路徑還沒準備好支援 LocalDNS，請像升級前一樣明確設定modeDisabled。

關於設定與退出指令，請參見 AKS 中的 LocalDNS。

升級程式中使用的驗證

AKS 會執行升級前驗證，以確保叢集健康情況：

API 重大變更：偵測已被取代的 API。
Kubernetes 升級版本：確保有效的升級路徑。
PDB 設定：檢查是否有設定錯誤的 PDB (例如 maxUnavailable=0)。
配額： 確認有足夠的配額供激增節點使用。
子網路： 驗證 IP 位址是否足夠。
憑證/服務主體：偵測過期的認證。
管理資源鎖定檢查： 對受管理叢集資源群組進行資源鎖定檢查。

這些檢查適用於整個 AKS。在 AKS Automatic 中，它們已整合到受控升級流程中；在 AKS Standard 中，它們是你維運流程的一部分。

常見的升級案例和建議

案例 1：容量限制

如果您的叢集受到產品層級或地區性容量的限制，當無法佈建激增節點時，升級可能會失敗。這種情況在專用產品層級 (例如 GPU 節點) 或資源有限的地區中很常見。如果 SKUNotAvailable 設定太高而無法取得可用容量，可能會發生 AllocationFailed、OverconstrainedAllocationRequest 或 maxSurge 之類的錯誤。

AKS 自動導引

保留既定的維護時段。
在預期升級期間前，驗證訂閱配額與子網餘裕。
讓工作負載擴縮和中斷預算與維護時段保持一致。

AKS 標準指引

使用 maxUnavailable 來升級 (透過使用現有節點，而不是激增新節點)。如需詳細資訊，請參閱在升級期間自訂無法使用的節點。
降低 maxSurge 以降低額外的容量需求。如需詳細資訊，請參閱自定義節點激增升級。
針對僅限安全性的更新，使用不需要激增節點的安全性修補程式重新安裝映像。如需詳細資訊，請參閱將安全性和核心更新套用於 Azure Kubernetes Service (AKS) 中的 Linux 節點 (部分機器翻譯)。

案例 2：節點清空失敗和 PDB

升級需要清空節點 (收回 Pod)。當 Pod 終止速度緩慢或嚴格的 Pod 中斷預算 (PDB) 阻止 Pod 收回時，清空可能會失敗。

錯誤範例：

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

AKS 自動導引

將PDB與複本策略視為主要的信度控制。
在推出到生產環境之前，請先在預備環境中驗證中斷預算。
將關鍵工作負載維持在有利於滾動驅逐成功的設定。

AKS 標準指引

選項一：強制升級，繞過 PDB 限制

警告

強制升級會繞過 Pod 中斷預算 (PDB) 限制，並可能因同時清空所有 Pod 而導致服務中斷。使用此選項之前，請先嘗試修正 PDB 配置錯誤（檢閱 PDB minAvailable/maxUnavailable 設定、確保有足夠的 Pod 複本、確認 PDB 沒有阻止所有的驅逐）。

只有在 PDB 阻止關鍵升級且無法解決時才使用強制升級。此舉會覆蓋 PDB 保護，可能導致升級期間服務完全無法使用。

Requirements： Azure CLI 2.79.0+ 或 AKS API version 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

備註

此 upgrade-override-until 參數會定義驗證略過何時結束（必須是未來的日期/時間）
若未指定，該時間窗口預設為從當前時間起計算三天
Z 表示 UTC/GMT 時區

警告

啟用強制升級時，它會優先於所有其他清空組態。不可清空節點行為設定 (選項 2) 在強制升級啟動時不會套用。

選項 2：在接受 PDB 的同時處理無法清空的節點

使用這種保守的方法來尊重 PDB，同時避免升級失敗。

設定無法清空的節點行為：

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

行為選項：

排程（預設）：刪除阻塞節點並進行補充。
Cordon（建議）：將節點設為 cordon，並將其標示為 kubernetes.azure.com/upgrade-status=Quarantined。

最大阻塞節點數：

指定可容忍清空失敗的節點數量
需要將 undrainable-node-behavior 設為
如果未指定，則預設為 maxSurge 值（通常為 10%）
如同最大突波，若計算值高於當前操作中剩餘升級節點數，則改用剩餘升級節點數

具有最大封鎖節點的組態範例

az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

選項 3：自動 PDB 管理（預覽）

使用自動 PDB 管理擴充功能，主動解決被 PDB 阻塞的排水系統，無需繞過 PDB 保護或手動清理隔離節點。自動 PDB 管理可偵測 PDB 何時封鎖已封鎖節點上的驅逐作業，並暫時擴大部署的複本數，以滿足中斷預算的需求。排空完成後，它會將副本數調整回原始數量。

自動 PDB 管理也能自動為沒有 PDB 的部署建立 PDB，確保您的工作負載在升級清理期間受到保護。如需安裝和設定的詳細資訊，請參閱在 AKS 升級期間自動管理 Pod Disruption Budget。

防止排水故障的建議

在 PDB 中設定 maxUnavailable，以允許至少一個 Pod 逐出
增加 Pod 複本數以符合中斷預算需求
如果工作負載需要更多的時間，請延長清空逾時時間。 (預設值為 30 分鐘。)
使用自動 PDB 管理，在排水作業期間自動建立 PDB 並進行複本縮放。
在預備環境中測試 PDB、監視升級事件，以及針對重要工作負載使用藍綠色部署。如需詳細資訊，請參閱 AKS 叢集的藍綠部署 (部分機器翻譯)。

驗證無法清空的節點

已封鎖的節點會針對 Pod 取消排程，並以標籤 "kubernetes.azure.com/upgrade-status: Quarantined" 標記。
在升級時發生清空節點失敗時，請確認任何已封鎖節點上的標籤：
```
kubectl get nodes --show-labels=true
```

解決無法清空的節點

移除負責任的 PDB：
```
kubectl delete pdb <pdb-name>
```

移除標籤 kubernetes.azure.com/upgrade-status: Quarantined ：

kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status-

選擇性地刪除封鎖的節點：

az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

完成此步驟後，你可以依照 az aks中所述，執行任意更新操作，無需使用可選欄位，來調和叢集狀態。或者，您可以將節點集區調整為與升級節點計數相同的節點數目。此動作可確保節點集區達到其預期的原始大小。 AKS 會優先移除已封鎖的節點。這個指令也會將叢集布建狀態還原至 Succeeded。在以下範例中，2 是已升級節點的總數。
```
# Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2
```

案例 3：升級緩慢

保守的設定或節點層級問題可能會延遲升級，進而影響您保持修補與功能改進更新的能力。

升級緩慢的常見原因包括：

低 maxSurge 或 maxUnavailable 值（限制平行處理的程度）。
高測試時間 (節點升級之間的長時間等候)。
清空失敗 (請參閱節點清空失敗)。

AKS 自動導引

保持維護時間表的更新。
監控升級事件的健康情況與工作負載的就緒狀態。
快速解決阻塞、PDB 或容量問題，以避免長時間延遲。

AKS 標準指引

針對生產環境使用 maxSurge=33%、maxUnavailable=1。
針對開發/測試環境使用 maxSurge=50%、maxUnavailable=2。
使用OS安全性修補程式進行快速且有針對性的修補（避免完整節點重新映像）。
啟用 --undrainable-node-behavior 以避免升級封鎖程式。

案例 4：IP 耗盡

激增節點需要更多的 IP。如果子網路接近容量上限 (可用的 IP 數快用完了)，節點佈建可能會失敗 (例如，Error: SubnetIsFull)。這種情況在 Azure 容器網路介面、高 maxPods 或大量節點數的情況下很常見。

AKS 自動導引

在生產擴展前驗證子網與容量計畫。
監控網路使用率，作為例行作業的一部分。

AKS 標準指引

請確定您的子網路有足夠的 IP 數可供所有節點、激增節點和 Pod 使用。公式為 Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)。
回收未使用的 IP 或擴增子網路可用的 IP 範圍 (例如，從 /24 到 /22)。

如果子網路無法擴展，則會降低 maxSurge 。

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

使用 Azure 監視器或自訂警示監視 IP 使用量。
每個節點減少 maxPods、清理孤立的負載平衡器 IP，以及規劃高規模叢集的子網路大小調整。

常見問題

我應該用 AKS 自動還是 AKS 標準來升級生產？

對於大多數生產工作負載，請使用 AKS Automatic。其設計為可直接用於生產環境的預設選項，具備受控的升級行為和內建防護機制。

當你需要進階手動控制升級順序、基礎設施選擇或節點池操作時，可以使用 AKS 標準。

我可以使用開放原始碼工具來進行驗證嗎？

是的。許多開放原始碼工具可以與 AKS 升級流程良好整合：

Trivy：用於對容器映像和 Kubernetes 組態進行安全性掃描。
Sonobuoy：用於進行 Kubernetes 符合性測試和叢集驗證。
kube-bench：用於依據 Center for Internet Security 標準進行安全性基準檢查。
Polaris：用於驗證 Kubernetes 最佳做法。
kubectl-neat：用於清理 Kubernetes 資訊清單以進行驗證。

如何在升級之前驗證 API 相容性？

使用 kubent 之類的工具執行淘汰檢查：

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

AKS 升級與其他 Kubernetes 平台有何不同？

AKS 提供了幾個唯一的優點：

在 AKS 自動系統中管理操作路徑，以降低升級開銷。
與 Azure 流量管理員、Azure Load Balancer 和網路功能的原生 Azure 整合。
用於協調多叢集升級的 Azure Kubernetes 機群管理員。
自動修補節點映像，無需手動管理節點。
內建配額、網路和認證的驗證功能。
Azure 對升級相關問題的支援。

選擇您的升級路徑

本文為您提供了技術基礎。立即選取您的案例型路徑。

準備好執行了嗎？

如果您有...	那麼請移至...
生產工作負載且無特殊客製化限制	建立 AKS 自動叢集
具備進階自訂升級需求的生產環境	生產升級策略
資料庫或具狀態應用程式	具狀態工作負載模式
多個環境	升級案例中樞
基本 AKS 標準叢集	升級 AKS 叢集

還在猶豫如何做決定嗎？

使用升級案例中樞來取得引導式的決策樹，該決策樹會考慮您的以下因素：

停機容忍度
環境複雜度
風險概況
時間表限制

最終建議

大多數生產工作負載都應使用 AKS Automatic。
在開始任何升級之前，請先檢閱 AKS 修補和升級指導，以了解最佳做法和規劃要訣。
請務必檢查 API 重大變更，並驗證您的工作負載與目標 Kubernetes 版本的相容性。
在預備環境中測試升級設定（例如 maxSurge、 maxUnavailable和 PDB），以將生產風險降到最低。
監視整個程序的升級事件和叢集健康情況。

意見反應

此頁面對您有幫助嗎？

上次更新時間： 2026-09-16

Azure Kubernetes Service （AKS） 叢集的升級選項和建議

本文涵蓋的內容

快速瀏覽

升級操作模型

AKS 自動（建議作為生產環境預設值）

AKS 標準（進階控制模型）

升級選項

執行手動升級

設定自動升級

跨多個可用性區域的節點集區特殊考量

最佳化升級以改善效能，並將中斷降至最低

AKS 自動化系统

AKS 標準

在升級到 Kubernetes 1.37 前，先驗證 LocalDNS 和自訂 DNS

升級程式中使用的驗證

常見的升級案例和建議

案例 1：容量限制

AKS 自動導引

AKS 標準指引

案例 2：節點清空失敗和 PDB

AKS 自動導引

AKS 標準指引

選項一：強制升級，繞過 PDB 限制

選項 2：在接受 PDB 的同時處理無法清空的節點

具有最大封鎖節點的組態範例

選項 3：自動 PDB 管理（預覽）

防止排水故障的建議

驗證無法清空的節點

解決無法清空的節點

案例 3：升級緩慢

AKS 自動導引

AKS 標準指引

案例 4：IP 耗盡

AKS 自動導引

AKS 標準指引

常見問題

我應該用 AKS 自動還是 AKS 標準來升級生產？

我可以使用開放原始碼工具來進行驗證嗎？

如何在升級之前驗證 API 相容性？

AKS 升級與其他 Kubernetes 平台有何不同？

選擇您的升級路徑

準備好執行了嗎？

還在猶豫如何做決定嗎？

最終建議

意見反應

其他資源

Azure Kubernetes Service （AKS）叢集的升級選項和建議