Azure Kubernetes Service (AKS)中的節點中斷原則(預覽)

在管理和維護 AKS 叢集時,某些設定變更需要重新安裝映像節點。 此重映像操作會觸發滾動更新,重新建立節點。 在重新安裝映像操作期間,AKS 會封鎖節點 (防止新的 pod 排程),清空現有的 pod (在遵守 Pod 中斷預算的情況下,將它們驅逐並重新排程到其他可用節點上),然後使用更新的設定重新安裝映像節點。 此程序是重建完整節點,而不是重新啟動——底層虛擬機將以新的作業系統映像重新建立。 雖然正確設定的持久磁碟區(使用 Azure 磁碟、Azure 檔案儲存體 或其他外部儲存)不會受到影響,但節點本地臨時儲存中的任何資料(例如 EmptyDir 卷或本地路徑)都會永久遺失。 這些操作是套用重要更新所必需的,但也可能干擾正在執行的工作負載並影響應用程式可用性。 節點中斷政策讓您能細緻掌控這些干擾性操作何時允許進行,幫助您在更新需求與營運穩定性間取得平衡。

Important

AKS 預覽功能以自助方式提供,並採選擇加入制。 預覽版本係依「現狀」及「可用情況」提供,且不適用於服務等級協定與有限保固。 客戶支援部門會盡最大努力,部分支援 AKS 預覽。 因此,這些功能不適合實際執行用途。 如需詳細資訊,請參閱下列支援文章:

什麼是節點中斷政策?

節點中斷政策是一種叢集層級的配置,規範何時執行需要節點重映像與重新部署的操作。 它充當一個控制閘,讓你能夠:

  • 將中斷性操作安排在維護時段內。
  • 在關鍵業務期間阻擋設定變更,同時允許節點映像升級與安全修補程式繼續進行。
  • 在高流量事件中維持可預測的群聚行為。

此政策適用於使用者發起且需節點重建的設定變更,例如更新自訂憑證授權機構(CA)信任憑證、修改安全設定檔設定,或變更節點作業系統設定。

Note

重要的是,該政策不會阻擋節點映像版本更新(包括SecurityPatchNodeImage升級通道)或 Kubernetes 版本升級。 即使政策設定為 Block,這些操作仍依其配置的排程繼續進行。 詳情請參閱 「升級操作未受節點中斷政策控制」。 此外,某些回收作業並未受此政策控制,以確保群聚的健康與可用性。 詳情請參閱 未受節點中斷政策控制的復原作業。

節點中斷政策的運作方式

你可以透過這個 nodeDisruptionProfile 屬性在叢集層級設定節點中斷政策。 當你嘗試需要節點重映像的操作時,AKS 會檢查目前的政策設定:

  • 政策評估:AKS 根據現行政策評估該行動是否被允許。
  • 維護視窗檢查 (如適用):若使用 AllowDuringMaintenanceWindow,AKS 會驗證目前時間是否落在設定的維護視窗內。
  • 操作執行或阻塞:節點干擾操作若允許則繼續;若阻塞則以錯誤訊息拒絕。

政策選項

節點中斷政策支援三種政策配置:

原則 說明 應用案例
Allow 允許需要將節點重新映像的作業在任何時間進行。 此為預設行為。 當你想快速優先執行更新且能承受工作量中斷時使用。
AllowDuringMaintenanceWindow 阻擋需要節點重映像的操作,除非發生在 aksManagedNodeOSUpgradeSchedule 維護視窗內。 當您希望將中斷限制在與營運時程相符的特定維護時段時,請使用此方法。
Block 封鎖所有需要節點重新映像的作業。 當您需要防止節點中斷時使用,例如關鍵業務期間或高流量事件時。

Note

使用 AllowDuringMaintenanceWindow時,必須設定 aksManagedNodeOSUpgradeSchedule 維護視窗。 欲了解更多關於設定維護視窗的資訊,請參閱「使用計劃性維護來排程及控制您的 Azure Kubernetes Service 叢集升級」。 如果你不設定維護視窗,節點干擾操作是被允許的。

Considerations

使用節點中斷政策時請考慮以下事項:

  • 範圍:本政策適用於由使用者起始且需要重新映像節點的作業,不適用於由 AKS 起始的系統維護。 詳情請參閱 未受節點中斷政策控制的復原作業。
  • 阻塞操作:當破壞性操作被阻擋時,API 呼叫會失敗並出現錯誤訊息。 你需要變更原則,或等待維護時段到來。
  • 緊急維護:Azure 保留執行緊急或關鍵維護操作的權利,無論政策設定為何。
  • 更新規劃:設定政策以防止 Block 某些叢集更新。 詳情請參見 節點中斷政策涵蓋的操作。 請做好規劃,確保在需要時能進行必要的更新。
  • 維護時段相依性:AllowDuringMaintenanceWindow 原則必須設定 aksManagedNodeOSUpgradeSchedule 維護時段。 詳情請參閱「使用計劃性維護來排程及控制您的 Azure Kubernetes Service 叢集升級」。

節點中斷政策涵蓋的操作

群集層級作業

網路原則啟用和 Azure CNI Overlay 升級

若要安裝所需的網路元件,並設定用來保護及管理 Pod 之間通訊的網路規則,您需要重新安裝映像節點。

下表概述會觸發重新映像的網路原則升級:

寄件者 至
無(無網路政策) Azure Network Policy
無(無網路政策) Calico
Azure CNI Azure CNI 覆蓋層
Azure Network Policy 無(無網路政策)
Calico 無(無網路政策)

Note

在 Azure 和 Calico 網路策略已啟用的情況下進行變更,無需重新安裝映像。

Node OS 升級通道 變更

每個通道使用不同的作業系統修補架構和設定,無法在執行中的節點 上修改 。

下表列出了觸發重新安裝映像的節點 OS 升級通道變更:

寄件者 至
未受管理 沒有
未指定 未受管理
SecurityPatch 未受管理
NodeImage 未受管理
沒有 未受管理
未指定 未受管理
未受管理 SecurityPatch
未受管理 NodeImage

IPv6 雙堆疊 啟用

為了支援雙堆疊通訊,節點需要同時具備 IPv4 與 IPv6 IP 設定,以及網路堆疊更新(例如 nftables 規則)。

下表概述會觸發重新映像的 IP 組態與網路堆疊更新:

寄件者 至
僅限 IPv4 IPv4 + IPv6(雙重堆疊)

Cilium 資料平面 變化

你需要安裝或移除處理核心層級封包處理的 eBPF 程式。

下表列出了觸發重新安裝映像的 Cilium 資料平面變更:

寄件者 至
沒有 Cilium
Cilium 沒有

HTTP 代理 設定更新

所有節點元件(containerd、kubelet、系統服務)都需要系統範圍內套用更新的代理設定。 當你更新 HTTP 代理設定時,AKS 會自動重映像叢集中所有節點池。

節點中斷政策會在您修改以下任一 HTTP 代理設定屬性或執行以下操作時 觸發重映像 :

  • httpProxy: HTTP 連線代理 URL
  • httpsProxy: HTTPS 連線的代理網址
  • noProxy:要從代理中排除的目的地清單
  • trustedCa:Base64 編碼的替代 CA 證書
  • 在叢集上啟用 HTTP 代理(使用 --enable-http-proxy)
  • 在叢集上停用 HTTP 代理(使用 --disable-http-proxy)
  • 在先前已停用 HTTP 代理的叢集上重新啟用 HTTP 代理

自訂 CA 憑證 更新

您必須在作業系統信任儲存庫安裝新的 CA 憑證,才能影響內部服務及私人登錄的 TLS 驗證。

節點中斷政策會在新增、移除或更新自訂 CA 憑證時 觸發重映像 。

Kubelet 身份 變更

你必須對節點設定套用新的身份憑證。 這包括初始身份指派、身份更新及服務主體設定檔重置。

當您更新 kubelet 的受控身分識別或使用者指派的受控身分識別時,節點中斷原則會觸發重新安裝映像。

私人 DNS 區域 變更

你必須更新 DNS 解析器設定,才能用新的 DNS 區域解析私有 API 伺服器端點。

節點中斷政策會在修改私有叢集中的私有 DNS 區域設定時 觸發重映像 。

API Server VNet Integration 啟用

你必須重新設定節點,使其透過指派到委派子網中的內部負載平衡器 IP 與 API 伺服器通訊。

當您在先前未使用 API Server VNet 整合的現有叢集上啟用此功能時,Node Disruption Policy 會觸發重新製作映像。 此變更對應於將 apiServerAccessProfile.enableVnetIntegration 屬性(在內部即為 privateConnectProfile.enabled 欄位)從 false(或未設定)變更為 true:

寄件者 至
apiServerAccessProfile.enableVnetIntegration:false 或未設定 apiServerAccessProfile.enableVnetIntegration: true

eBPF 主機路由 變更

你需要安裝或移除提供高效能封包轉發(BpfVeth 加速模式)的 eBPF 程式。

下表概述會觸發重新映像的 eBPF 主機路由變更:

寄件者 至
標準路由 啟用 eBPF 主機路由
啟用 eBPF 主機路由 標準路由

節點集區層級作業

這些操作只影響你做變更的特定節點池。 它們會在這些節點集區中觸發滾動式重新安裝映像:

本地 DNS 設定檔更新

你需要在節點層級對 DNS 快取守護程序和 DNS 轉發規則進行變更。

節點中斷政策會在你修改 LocalDNS 設定檔設定時 觸發重映像 。

信任啟動 安全性變更

你無法更改虛擬機韌體設定和啟動程序設定。 這些變更需要你重新建立虛擬機。

下表概述 會觸發重新安裝映像的可信啟動安全性變更:

Configuration 寄件者 至
vTPM(虛擬可信平台模組) Disabled 已啟用
vTPM(虛擬可信平台模組) 已啟用 Disabled
安全開機 Disabled 已啟用
安全開機 已啟用 Disabled

成品串流變更

您需要安裝或移除成品串流元件,才能透過隨需串流映像層來加速容器映像提取。

下表概述會觸發重新映像的成品串流變更:

寄件者 至
Disabled 已啟用
已啟用 Disabled

Windows GMSA 設定檔更新(僅限 Windows 節點池)

你需要在 Windows 節點上套用新的 GMSA 設定、DNS 伺服器設定,以及網域加入憑證,才能整合 Active Directory。

當 GMSA 變更需要套用新的節點組態時,節點中斷原則會觸發 Windows 節點集區的重新映像:

寄件者 至 觸發重新建立映像
GMSA 已停用 啟用 GMSA Yes
啟用 GMSA(DNS 伺服器/根網域設定或變更) 啟用 GMSA 並更新 DNS 伺服器或根網域 Yes
啟用 GMSA(DNS 伺服器設定) GMSA 已停用 Yes
啟用 GMSA(未設定 DNS 伺服器) GMSA 已停用 沒有(沒有可套用的節點設定)

容量預留群組附加

你需要重建底層虛擬機,讓它們從容量保留群組(CRG)的保留容量中分配。 現有節點並非依 CRG 佈建,因此 AKS 必須重新安裝映像節點集區,才能將其與預留資源建立關聯。

當您將容量預留群組附加到尚未附加容量預留群組的現有節點集區時,節點中斷原則會觸發重新安裝映像。

寄件者 至 觸發重新建立映像
未附加容量預留群組 已附加容量預留群組 Yes

Kubernetes 1.37 及以後版本節點中斷政策涵蓋的操作

在 Kubernetes 1.37 及更新版本中,節點中斷政策涵蓋了以下需要節點重映像檔的設定變更。 在 Kubernetes 1.36 及更早版本,你必須在完成這些設定變更後手動執行az aks nodepool upgrade--node-image-only,才能套用到節點上。

  • SSH 設定變更:更改 SSH 存取方式(停用 SSH、基於 Entra ID 的 SSH 或本地使用者 SSH)或更新節點池的 SSH 公鑰。
  • IMDS 限制 變更:啟用或停用實例元資料服務(IMDS)限制,以阻擋 Pod 對 IMDS 端點的存取。
  • Bootstrap 設定檔變更:變更 Bootstrap 設定檔,例如將 artifactSource 在 Direct 與 Cache 之間切換,或變更 containerRegistryId(用於網路隔離叢集的 Azure Container Registry)。
  • 出站類型 變更:修改叢集的出站連接類型(loadBalancer、userDefinedRouting、managedNATGateway 或 userAssignedNATGateway)。

不受節點中斷政策控制的升級操作

節點中斷政策 無法控制 後續的升級操作。 這些升級操作無論你的政策設定如何,都會持續進行。 升級可由客戶主動發起,或由 AKS 在計畫維護期間內啟動。 為了讓這些操作如期進行,應刻意將它們置於節點中斷政策範圍之外。 此外,若節點中斷政策涵蓋的操作包含在相同的組態變更中並升級,則不會受到節點中斷政策的控制。

  • 節點映像檔版本 更新:手動升級至新的節點作業系統映像版本(手動或透過自動升級管道)。 此操作是最常見的重映像操作,包含安全修補程式、作業系統更新及 AKS 節點映像釋出。
  • Kubernetes 版本 升級:在節點池上升級 Kubernetes 版本,套用新的 Kubernetes 二進位檔、更新的 kubelet 設定及作業系統層級的變更。

未受節點中斷政策控制的復原作業

節點中斷政策 無法控制 以下自動化復原作業。 這些行動無論您的政策設定如何,都能進行以確保群聚的健康與復原。

  • 節點池設定回滾:當節點池更新操作因設定無效或基礎設施問題失敗時,AKS 會自動回滾至最後已知良好狀態,並重新映像節點以還原設定。
  • 管理叢集還原操作:當 Azure 支援 工程師在事件解決時執行管理叢集還原,節點會重新映像,以確保控制平面狀態與節點設定一致。
  • 節點身份憑證更新:AKS 定期更新節點身份憑證以確保安全與合規。 這些系統發起的更新會觸發節點重映像,將新的憑證套用到所有節點池。

與計畫性維護整合

節點中斷原則與 AKS 計畫性維護時段無縫協作。 當您將原則設為 AllowDuringMaintenanceWindow 時,造成中斷的作業會配合您的 aksManagedNodeOSUpgradeSchedule 維護時段,確保:

  • 變更僅在核准的時間窗口內發生。
  • 作業會與其他排定的維護作業協調進行。
  • 團隊能察覺何時可能發生中斷。

此整合提供一套全面的叢集變更管理方法,並減少對執行工作負載的影響。

Note

使用 AllowDuringMaintenanceWindow時,必須設定 aksManagedNodeOSUpgradeSchedule 維護視窗。 使用 default 維護視窗或 aksManagedAutoUpgradeSchedule (叢集自動升級)無法滿足這個需求。 如果您設定了 AllowDuringMaintenanceWindow,但未設定 aksManagedNodeOSUpgradeSchedule 視窗,所有具干擾性的操作都會被允許(因為該原則沒有可用來限制這些操作的視窗)。 欲了解更多關於設定維護視窗的資訊,請參閱「使用計劃性維護來排程及控制您的 Azure Kubernetes Service 叢集升級」。

最佳實務

在實施節點中斷政策時,請考慮以下建議:

  • 將AllowDuringMaintenanceWindow用於生產環境:結合預先規劃的維護時段,控制生產環境中斷發生的時間。
  • 在關鍵時期設定 Block:在高流量活動、產品發布或事件回應期間,暫時封鎖會造成干擾的操作。 不要無限期使用 Block 。 雖然 Block 適合短期凍結 (計畫性事件、事件應變)。
  • 允許非生產環境的彈性:用於 Allow 開發與測試環境中,快速迭代比穩定性更重要。
  • 溝通政策變更:確保您的團隊了解現行政策,並知道何時可能阻礙營運。
  • 妥善規劃維護時段:根據您需要執行的作業,調整維護時段大小。
  • 測試政策行為:在將政策設定套用到生產叢集前,先在非生產環境中驗證。
  • 監控阻塞作業:追蹤作業阻塞時間,以優化維護時程。