這很重要
AKS 平台發起的升級。 自 2027 年 6 月 1 日起，AKS 會在 60 天 平台支援寬限期 結束後，自動升級任何仍維持在不支援 Kubernetes 版本的叢集。 平台發起的升級 不會依循您的維護時段，不會因為已棄用的 API 使用情況而停止，且可能覆寫阻擋節點清空的 Pod 中斷預算，因此工作負載可能會中斷。 在升級月份之前，替換從目標 Kubernetes 版本移除的 API，並更新不相容的自我管理附加元件。 讓叢集維持在受支援的 Kubernetes 版本上，以避免平台主動升級。 欲了解更多資訊，請參閱 AKS 中平台發起升級的準備。
Azure Kubernetes Service （AKS） 會進行滾動升級，以減少對運行中工作負載的干擾。
對於大多數生產工作負載，建議使用 AKS 自動模式（如適用）。 AKS Automatic 包含升級作業的生產預設值，例如自動 Kubernetes 版本升級、自動節點作業系統（OS）映像更新、管理系統節點操作，以及內建的防護措施以降低手動負擔。 如需更多資訊，請參閱 AKS Automatic 簡介。
本文說明 AKS 升級機制，並強調 AKS 自動與 AKS 標準的差異。
先決條件
升級型號：AKS 自動與 AKS 標準型
AKS 自動與 AKS 標準叢集模式使用相同的 Kubernetes 升級基礎，但在預設值與操作擁有權上有所不同。
| 升級疑慮 | AKS 自動化系统 | AKS 標準 |
|---|---|---|
| 生產定位 | 在適用情況下，建議將此預設值用於大多數生產工作負載 | 預設情況下需要較多手動設定的彈性模型 |
| Kubernetes 小版本升級 | 預先設定的自動升級通道 | 預設為手動，選配自動通道 |
| 節點 OS 映像升級作業 | 預先設定的自動節點作業系統映像通道 | 預設為手動，選配自動通道 |
| 系統節點池操作 | 由AKS管理 | 由客戶管理 |
| 計劃性維護時段 | 預設可用 | 選用設定 |
| 工作負載中斷控制 | 由客戶擁有，包括複本策略、整備度行為及中斷原則 | 由客戶擁有，包括複本策略、整備度行為及中斷原則 |
Note
AKS Automatic 可簡化平台營運，但共同責任模式仍然適用。 工作負載層級的可用性設計與驅逐政策行為仍由客戶負責。
AKS 中的滾動升級行為
AKS 透過使用滾動模式升級節點集區，在取代或重新安裝映像節點的同時保持容量。 這種行為在所有 AKS 叢集模式中都是一樣的。
概括來說，AKS：
- 根據升級設定新增暫時性的突增容量。
- 對節點執行封鎖與清空作業，以移動工作負載。
- 將節點重新映像或替換為目標版本。
- 完成後移除臨時擴增容量。
滾動升級範例
這個範例示範將一個雙節點叢集從 Kubernetes 1.30 升級到 1.31，設定 maxSurge 為 1。
第 1 步：初始設置
叢集從兩個執行 1.30 版的節點開始，每個節點都託管應用程式 Pod。
- 節點 1：Pod A、Pod B
- 節點 2：Pod C、Pod D
- 突波節點：空 (DaemonSets 和新 Pod 除外)
步驟 2：封鎖並排空第一個節點
AKS 會封鎖節點 1 以防止新的 Pod 排程，然後清空現有的 Pod。
- Pod A →在擴展節點上被驅逐並替換
- Pod B → 被驅逐並取代於第2節點
步驟 3：升級第一個節點
節點 1 會使用 Kubernetes 1.31 版重新製作映像，而 Pod 會繼續在其他節點上執行。
- 節點 1：升級至 v1.31
- 節點 2：Pod B、Pod C、Pod D
- Surge 節點：Pod A
步驟 4：封鎖並排空第二個節點
AKS 會針對節點 2 重複此程序，Pod 會被驅逐，而排程器會將它們重新分配到適當的可用節點。
- Pod C、B → 在節點 1 上收回並取代
- Pod D → 在突波節點上被驅逐並替換
- 節點 2：封鎖並重新映像至 v1.31
步驟 5：移除突波節點
所有永久節點升級後，激增節點會被封鎖、抽空並刪除。
- Pod A → 在節點 1 上收回並取代
- Pod D → 被驅逐並在節點 2 上被取代
- Surge 節點：已刪除
最終狀態
所有節點現在都執行 Kubernetes 1.31 版，並在整個叢集之間排程工作負載。
- 節點 1 （v1.31）：Pod A、Pod C
- 節點 2 （v1.31）：Pod B、Pod D
嚴格的 Pod 中斷預算 (PDB) 行為
如果限制較嚴格的 PDB 阻擋驅離，節點清空可能會延遲或無法進行。 AKS 可以利用 Cordon 無法排空節點行為，依照設定的行為繼續升級其他符合條件的節點。 被封鎖的節點可能會保留在舊版本，直到阻塞狀況解決。
Note
由平台發起的升級，其行為有所不同。 AKS 會先嘗試正常的清空，但如果清空逾時或失敗，就會覆寫 PDB，使叢集觸達受支援的 Kubernetes 版本。
限制性PDB範例
這個例子展示了將一個雙節點叢集從 Kubernetes 1.30 升級到 1.31，設定 maxSurge 為 ， 2 並用 PDB 阻擋第一個節點的排水操作。
步驟 1：使用限制性 PDB 進行初始設定
叢集從兩個執行 1.30 版的節點開始，其中 PDB 可保護 Pod A 免遭收回。
- 節點 1：Pod A（受 PDB 保護）、Pod B
- 節點 2：Pod C、Pod D
- 浪湧節點：新建的兩個節點
- PDB：防止 Pod A 被驅逐
步驟 2：嘗試清空第一個節點（已封鎖）
AKS 封鎖了節點 1，但因 PDB 限制無法抽空 Pod A。
- 節點 1：封鎖並標記為已隔離（Pod A 停滯）
- Pod B → 在 Surge Node 1 上遭到驅逐並被取代，而 Surge Node 2 暫時不使用
- 狀態：節點 1 升級已封鎖
第 3 步：繼續第二個節點
隔離節點 1 後，AKS 會繼續升級節點 2。
- 節點 1：保持隔離狀態 （v1.30）
- 節點 2：封鎖和排空成功
- Pod C → 在突波節點 2 上被驅逐並替換
- Pod D → 在 Surge Node 2 上驅逐並替換
步驟 4：升級第二個節點
節點 2 已成功重新映像至 Kubernetes 1.31 版。
- 節點 1：仍與 Pod A 隔離 （v1.30）
- 節點 2：升級至 v1.31
- Surge 節點 1：Pod B
- Surge 節點 2：Pod C、Pod D
第 5 步：一個突波節點成為永久替代節點，而另一個節點被移除
由於節點 1 仍被隔離，浪湧節點 1 成為執行 v1.31 的永久替代者，而突波節點 2 則被刪除。
- 節點 1：隔離 （v1.30） — 需要手動介入
- Pod C、Pod D →從 Surge Node 2 被驅逐，並更換至 Node 2
- Surge 節點 1 （v1.31）：Pod B（現已永久）
- 突波節點 2（v1.31）：已刪除
最終狀態
升級在一個隔離節點需要手動介入的情況下完成。
- 節點 1：已隔離 (v1.30)，包含 Pod A - 客戶必須手動解決 (請參閱解決無法排空節點)
- 節點 2 （v1.31）：正常執行
- 前 Surge 節點 （v1.31）：現已永久替換
這很重要
隔離節點（節點1）仍由客戶負責處理。 您必須選擇：
- 調整 PDB，以允許驅逐 Pod A。
- 手動刪除 A 艙。
- 修正阻塞條件後刪除並重新建立該節點。
PDB 封鎖升級的主要考慮
-
無法排空節點行為：節點集區將此設定為
Cordon，才能啟用此隔離行為。 - 客戶責任：隔離節點需要人工介入才能解決。
- 叢集容量：浪湧節點將永久存在，可能影響叢集容量規劃。
- 監控：透過 Azure 監視器 或 Kubectl 追蹤隔離節點，以確保及時解決。
Tip
若要完全避免隔離情況，您可以使用自動 PDB 管理，在清空作業開始前自動擴大部署複本，使 Pod 中斷預算 (PDB) 的限制條件得到滿足。 這使得驅逐程序能夠進行而不被封鎖，免除了手動隔離解決的需求。
藍綠節點集區升級（手動控制）
Blue-Green 升級會先手動建立一整套全新的節點池，再遷移工作負載，藉此提供更易於控管的升級方法。 這種手動方法可讓您完全控制升級過程和時間。
欲了解更多資訊，請參閱 AKS 中的藍綠節點集區升級。
何時使用 Blue-Green 升級
手動藍綠節點集區升級是一種針對特殊需求的進階策略，例如明確的移轉檢查點、自訂驗證閘道或嚴格控制的切換。
在下列情況下，請使用手動 Blue-Green：
- 由操作員控制的遷移階段。
- 在提交前自訂驗證與接受標準。
- 明確的回復編排，與內部執行手冊繫結。
對於大多數適用的生產工作負載，AKS 自動預設升級行為是首選的起點，而手動藍綠升級通常保留用於特殊情況。
重要概念
- 藍色節點池：你現有的節點池，運行目前的 Kubernetes 版本。
- 綠色節點池：你在執行目標 Kubernetes 版本時建立的新節點池。
- 手動控制：你管理遷移流程的所有面向。
- 驗證檢查點：你決定何時繼續、暫停或回滾。
藍綠升級的好處
- 完全掌控：你能精確決定每個步驟發生的時間。
- 自訂驗證：實施您自己的驗證標準與時間安排。
- 漸進式遷移：以你偏好的節奏移動工作負載。
- 輕鬆還原：在你刪除這些原始節點之前，它們會一直可供使用。
藍綠升級的關鍵考量
- 手動操作：需在整個過程中積極管理。
- 配額要求：升級時需要節點容量的 2 倍。
- 規劃：記錄驗證準則與回滾程序。
手動 Blue-Green 升級流程範例
此範例示範如何使用 Blue-Green 部署手動將雙節點叢集從 Kubernetes 1.30 升級至 1.31。
步驟 1：建立綠色節點池
您可以先手動建立新的節點集區，其中包含目標 Kubernetes 版本以及現有的節點集區。
- 藍色節點池（v1.30）：A、B、C、D（現有）
- 綠色節點池（v1.31）：空（由你手動建立）
-
您的動作：
az aks nodepool add使用新的 Kubernetes 版本
步驟 2：手動封鎖藍色節點
封鎖藍色節點，防止新的 pod 排程，同時保持現有 pod 運作。
-
您的動作：
kubectl cordon在每個藍色節點上 - 藍色節點：已封鎖，未排程新 Pod
- 綠色節點：已準備好接收工作負載
步驟 3：手動清空藍色節點 （控制速度）
您可以一次或批次手動清空一個節點來控制移轉速度。
-
您的動作：
kubectl drain在選取的藍色節點上 - Pod 移轉：Pod 自動重新排程至綠色節點
- 驗證：在進行前，先驗證綠色節點的工作負載
第 4 步：驗證並決定
遷移工作負載後，驗證綠色節點的應用程式效能。
在此階段，您可以：
- 監視器：檢查應用程式計量和記錄
- 測試：在綠色節點集區上執行驗證測試
- 決定：承諾綠色或復原至藍色
步驟 5：認可或復原
根據您的驗證，您可以選擇手動完成升級或回退。
選項 A - 提交（成功）：
-
你的操作：透過以下方式刪除藍色節點池
az aks nodepool delete - 結果：綠色節點集區成為主要節點集區
選項B - 回復 (偵測到的問題)：
-
你的操作：使用
kubectl uncordon解除藍色節點的封鎖，使用kubectl drain清空綠色節點，並使用az aks nodepool delete刪除綠色節點集區 - 結果：工作負載回到藍色節點
升級規劃中的生產考量
-
Surge （
maxSurge） 配置：控制升級期間產生的 surge 節點數量。 較高的值會加速升級，但會消耗更多資源。 - Pod 中斷預算（PDB）：配置 PDB 以確保升級過程中應用程式的可用性。
- 節點池升級：每個節點池獨立升級。 相應地規劃您的升級策略。
- 容量與配額：在升級窗口前驗證臨時及穩態容量需求。
- 監控與警示：在升級開始前設置監控與警示。
在 AKS 自動系統中，數個平台層級升級選項已預先配置以達到生產準備。 在 AKS 標準版中，隊伍通常會明確做出這些選擇。