維護期間與排除時段

本頁面說明維護期間和維護排除事項。這些政策可控管 Google Kubernetes Engine (GKE) 叢集執行部分叢集維護作業 (例如自動升級) 的時間。舉例來說，零售業商家可以限制維護作業只能在平日晚上進行，並防止在重要產業銷售活動期間自動進行維護作業。

關於 GKE 維護政策

您可以透過 GKE 維護政策 (包括維護期間和排除項目)，控管叢集自動維護作業的執行時間，包括叢集升級、節點設定變更，或叢集網路拓撲變更。

「維護期間」是指可以自動維護 GKE 的週期性時間範圍。

「維護作業排除項目」是指禁止自動維護 GKE 的一次性時間範圍。

如果維護期間已開始，而且您未設定維護作業排除時段，GKE 就會自動變更叢集，並遵守叢集的維護政策。您可以為每個叢集設定一個定期維護時段和多個維護排除時段。

其他類型的維護作業不依賴 GKE 維護政策，包括控制層修復作業，以及 GKE 所依附服務 (例如 Compute Engine) 的維護作業。詳情請參閱「自動維護作業不會遵守維護政策」。

哪些變更會遵守 GKE 維護政策，哪些不會

設定 GKE 維護政策 (維護期間和排除項目) 前，請先詳閱下列各節，瞭解 GKE 和相關服務如何遵守這些政策。

自動維護作業，會遵守 GKE 維護政策

透過 GKE 維護政策，您可以控管下列事件的發生時間，避免叢集暫時中斷服務：

其他類型的自動維護作業不依維護政策而定。 詳情請參閱「不遵守維護政策的自動維護作業」。

自動維護作業未遵守 GKE 維護政策

GKE 維護期間和排除項目不會封鎖所有類型的自動維護作業。設定 GKE 叢集的維護政策前，請務必瞭解哪些類型的變更不會遵守維護時段和排除項目。

其他 Google Cloud 維護作業

GKE 維護時間範圍和排除項目不會阻止基礎 Google Cloud 服務 (主要是 Compute Engine) 的自動維護作業，也不會阻止將應用程式安裝至叢集的服務 (例如 Cloud Deploy) 進行維護。

舉例來說，GKE 節點是 Compute Engine VM，由 GKE 為叢集管理。Compute Engine VM 有時會發生主機事件，包括維護事件或主機錯誤。VM 在這些事件期間的行為取決於 VM 的主機維護政策，而大多數 VM 的預設政策是即時遷移。這通常表示節點幾乎不會停機，而且對於大多數工作負載而言，預設政策就已足夠。對於部分 VM 機器系列，您可以監控及規劃主機維護事件，並觸發主機維護事件，以便配合 GKE 維護政策。

部分 VM (包括搭載 GPU 和 TPU 的 VM) 無法執行即時遷移。如果您使用這些加速器，請參閱這篇文章或這篇文章，瞭解如何處理節點維護作業造成的 GPU 或 TPU 中斷問題。

建議您查看主機事件和主機維護政策的相關資訊，並確認工作負載已準備好因應中斷，尤其是工作負載在無法執行即時遷移的節點上執行時。

自動修復和調整大小

GKE 會對控制層執行自動修復作業。包括將控制層擴展至適當大小，或重新啟動控制層來解決問題。大多數修復作業都會忽略維護期間和排除時段，因為如果無法執行修復作業，叢集可能會無法運作。

您無法停用控制層修復功能。不過，大多數類型的叢集 (包括 Autopilot 叢集和 標準區域叢集) 都有多個控制層副本，因此即使在維護期間，Kubernetes API 伺服器也能維持高可用性。標準區域叢集只有單一控制層，因此在控制層設定變更和叢集維護期間，無法修改這類叢集。包括部署工作負載。

節點也具備自動修復功能，您可以為標準叢集停用這項功能。

修補重大安全漏洞

維護期間和排除時段可能會導致安全性修補程式延遲發布。 不過，如果出現重大安全漏洞，GKE 保留覆寫維護政策的權利。

維護以 Spanner 為基礎的叢集狀態資料庫

部分 GKE 叢集會使用 Spanner 鍵值資料庫儲存 Kubernetes API 資源的狀態。這個資料庫的維護作業會忽略所有有效的維護期間和排除時段。不過，以 Spanner 為基礎的叢集狀態資料庫會進行複製，在維護事件期間仍可使用。

遵守 GKE 維護政策的手動變更

如要套用新的節點或網路設定，必須重新建立節點，包括以下部分變更：

這些變更會遵守 GKE 維護政策，也就是說，GKE 會等待開放維護期間，並等待沒有任何有效的維護作業排除時段，防止節點維護作業。如要手動將變更套用至節點，請使用 Google Cloud CLI 呼叫 gcloud container clusters upgrade 指令，並傳遞 --cluster-version 標記，其中包含節點集區已執行的相同 GKE 版本。

手動變更，但未遵守 GKE 維護政策

部分手動變更會立即使用節點升級策略重建節點，而不會遵守維護政策。詳情請參閱「手動變更：使用節點升級策略重建節點，但不遵守維護政策」。

維護期間

您可以透過維護期間控管控制層和節點的自動升級時間，降低工作負載暫時中斷服務的可能性。維護期間適用於下列類型的情境：

  • 離峰時段：安排在流量較小的離峰時段自動升級，盡可能降低停機機率。
  • 值班待命：一定要在工作時間內進行升級，以利相關人員監控升級作業並管理突發狀況。
  • 多叢集升級：按照指定的間隔，逐一升級分佈在不同地區的多個叢集。

除了自動升級，Google 有時也需要執行其他維護工作，並盡可能遵守叢集的維護期間。

如果執行工作的時間超出維護期間，GKE 會嘗試暫停工作，並在下個維護期間繼續執行。

GKE 保留在維護期間之外，導入非預定緊急升級的權利。此外，系統可能會在維護期間之外自動強制升級已淘汰或過舊的軟體。

如要瞭解如何為新的或現有叢集設定維護期間，請參閱「設定維護期間」。

維護期間的時區

設定及查看維護期間時，時間的顯示方式會因您使用的工具而異：

設定維護期間時

時間一律以世界標準時間儲存。不過，設定維護時段時，您可以使用世界標準時間或當地時區。

使用較通用的 --maintenance-window 旗標設定維護時段時，無法指定時區。使用 gcloud CLI 或 API 時，系統會採用世界標準時間，而 Google Cloud 控制台則會以當地時區顯示時間。

使用更精細的旗標 (例如 --maintenance-window-start) 時，您可以將時區指定為值的一部分。如果省略時區，系統會使用當地時區。

查看維護期間時

查看叢集相關資訊時，維護時段的時間戳記可能會以世界標準時間或當地時區顯示，視您查看資訊的方式而定：

  • 使用 Google Cloud 控制台查看叢集相關資訊時，時間一律會以您所在時區為準。
  • 使用 gcloud CLI 查看叢集相關資訊時，時間一律會以世界標準時間顯示。

無論是哪種情況，RRULE 一律以世界標準時間為準。也就是說，如果指定星期幾，則這些日期會以世界標準時間為準。

維護作業排除時段

您可以透過維護作業排除項目，避免系統在特定時段自動執行維護作業。舉例來說，許多零售業商家都有業務指南，禁止在年終節慶期間變更基礎架構。再舉一例，如果公司使用的 API 預計將淘汰，可以透過維護排除條件暫停次要升級，爭取時間遷移應用程式。

如果是已知的高影響事件，建議您將任何內部變更限制與維護排除項目相符，該排除項目應在事件發生前一週開始，並持續到事件結束為止。

排除條件不會重複發生。請改為分別建立每個週期性排除條件的執行個體。

如果排除時段與維護期間重疊，系統會優先處理排除時段。

如要瞭解如何為新叢集或現有叢集設定維護作業排除時段，請參閱「設定維護作業排除時段」。

要排除的維護範圍

您不僅可以指定時間，防止叢集自動進行維護作業，還可以限制可能發生的自動更新範圍。維護排除範圍適用於下列類型的情境：

  • 不升級 - 避免任何維護作業：您想在特定時間內暫時避免叢集發生任何變更。這是預設範圍。
  • 不升級子版本 - 維護目前的 Kubernetes 子版本：您想暫時維持叢集的子版本，避免 API 變更，或驗證下一個子版本。
  • 不執行任何次要或節點升級作業 - 防止節點中斷：您想暫時避免因節點升級而導致工作負載遭到驅逐及重新排程。

下表列出各範圍如何限制叢集控制層或節點的微幅或修補程式升級。

GKE 升級叢集時，控制層和節點的 VM 會重新啟動。對於控制層，Autopilot 和區域標準叢集會維持 Kubernetes API 伺服器可用性。在單一控制層節點的區域叢集中，VM 重新啟動會導致控制層暫時無法使用。對於節點，VM 重新啟動會觸發 Pod 重新排程，這可能會暫時中斷現有工作負載。您可以設定工作負載中斷容許度，方法是使用 Pod 中斷預算 (PDB)。

範圍 控制層 節點
自動次要升級 自動升級修補程式 自動次要升級 自動升級修補程式
不升級 (預設) 不允許 不允許 不允許 不允許
不執行任何次要升級作業 不允許 允許 不允許 允許
不執行任何次要或節點升級作業 不允許 允許 不允許 不允許

如要瞭解次要版本和修補程式版本的定義，請參閱版本管理機制。

多項排除條件

您可以在叢集上設定多個排除條件。這些排除條件可能具有不同範圍，且時間範圍可能重疊。年終節慶假期使用案例是重疊排除條件的例子，其中「不升級」和「不進行次要升級」範圍都在使用中。

如果排除時段重疊，且有任何有效排除時段 (也就是目前時間在排除時段內) 阻礙升級，系統就會延後升級。

以年終節慶假期使用案例為例，叢集指定了下列排除條件：

  • 不執行任何次要升級作業：9 月 30 日至 1 月 15 日
  • 不執行任何升級作業：11 月 19 日至 12 月 4 日
  • 不升級：12 月 15 日至 1 月 5 日

由於這些排除時段重疊，叢集將無法進行下列升級：

  • 11 月 25 日升級節點集區的修補程式 (因「不執行任何升級作業」排除時段而遭拒)
  • 12 月 20 日控制層的次要升級 (因「不執行任何次要升級作業」和「不執行任何升級作業」排除條件而遭拒)
  • 12 月 25 日將控制層升級至修補程式版本 (因「不升級」排除條件而遭拒)
  • 1 月 1 日對節點集區進行子版本升級 (因「不執行任何次要升級作業」和「不執行任何升級作業」排除條件而遭拒)

叢集可進行下列維護作業：

  • 11 月 10 日將控制層升級至修補程式版本 (「不執行任何升級作業」排除時段允許此作業)
  • 12 月 10 日因 GKE 維護作業導致 VM 中斷 (「不得執行子版本升級作業」排除項目允許)

排除期限

當排除項目到期 (也就是說，目前時間已超過排除項目指定的結束時間)，該排除項目將不再阻止 GKE 更新。其他仍有效的排除項目 (未過期) 會繼續阻止 GKE 更新。

如果沒有任何排除項目或其他因素會阻礙叢集升級，GKE 會逐步將叢集升級至符合自動升級條件的目標版本。

如果叢集因排除時段而錯過多次子版本升級，GKE 會安排每月升級一次子版本，包括叢集控制層和節點，確保叢集執行支援的版本。您隨時可以手動升級，讓叢集更快升級至特定次要版本。

設定維護作業排除時段的限制

維護作業排除時段有下列限制：

  • 只有在發布版本中註冊的叢集，才能透過維護排除項目限制自動升級的範圍。對於未在發布版本中註冊的叢集，您只能建立預設「不得執行升級作業」範圍的維護作業排除時段。
  • 您最多可以新增三個維護作業排除時段，排除所有升級作業 (也就是「不執行任何升級作業」的範圍)。設定這些排除項目時，必須在每 32 天的滾動週期中保留至少 48 小時的維護時間。
  • 每個叢集最多可有 20 個維護排除條件。
  • 如果您未在排除項目中指定範圍，範圍預設為「不升級」。
  • 您可以根據範圍設定不同長度的維護排除時段。詳情請參閱「設定維護排除項目」一節中的「維護排除項目長度」列。
  • 您無法設定維護作業排除時段，使其包含或超過與叢集發布管道註冊相應的次要版本支援結束日期。請參閱下列範例：
    • 叢集在穩定版管道中執行子版本，而 GKE 發布時間表指出該版本的標準支援服務終止日期為 2025 年 6 月 5 日。維護作業排除時段的結束時間必須設為 2025-06-05T00:00:00Z 或更早。
    • 叢集在延長版通道中執行子版本，而 GKE 發布時間表指出延長版支援服務將於 2026 年 4 月 5 日結束。維護作業排除時段的結束時間必須設為 2026-04-0500:00:00Z 或更早。如要將叢集的發布管道變更為其他管道，如果維護排除時間超過標準支援期結束時間，則必須變更維護排除時間的結束時間。詳情請參閱「將叢集從 Extended 管道變更」。

維護作業排除時段不會影響手動升級和新節點的版本

維護作業排除項目可防止現有控制層和節點自動升級，具體取決於維護作業排除項目的範圍。不過，維護排除項目無法防止下列變更：

  • 手動升級叢集的控制層或節點。
  • 建立新版 Standard 節點集區，版本比現有 Standard 節點集區更新，且維護排除項目會阻止自動升級。
  • 如果維護作業排除項目會阻止自動升級，節點自動佈建功能可能會建立下列資源，但版本會比現有節點新：
    • 新的標準節點集區。
    • Autopilot 叢集中的新節點。

假設您為叢集建立維護作業排除時段，並設定範圍，讓 GKE 自動將控制層升級至後續修補程式版本，但節點除外。在這種情況下，GKE 可能會建立新的節點集區，或透過自動佈建建立節點，這些節點會執行控制層的後續修補程式版本。

叢集節點只能執行與控制層相同或較舊的 GKE 版本。維護作業排除項目可防止現有節點自動升級。如果控制層的版本比現有節點新，新建立或手動升級的節點可能會執行較新版本的 GKE，而受維護排除項目限制而無法自動升級的節點則不會。

使用範例

以下列舉幾個限制可發生更新範圍的用途範例。

示例：零售商為年底節慶檔期做準備

在這個例子中，零售業商家不希望在銷售量最高的時期 (即黑色星期五到網購星期一這四天，以及 12 月到新年開始前) 發生中斷情形。為迎接購物季，叢集管理員會設定下列排除條件：

  • 不執行任何次要升級作業：在 9 月 30 日至 1 月 15 日期間，只允許控制層和節點進行修補程式更新。
  • 不執行任何升級作業：11 月 19 日至 12 月 4 日期間，凍結所有升級作業。
  • 不執行任何升級作業：12 月 15 日至 1 月 5 日期間，凍結所有升級作業。

如果維護作業排除時段到期時，沒有其他排除時段適用，且 9 月 30 日至 1 月 6 日之間有新的 GKE 次要版本發布，叢集就會升級至該版本。

範例：公司在 Kubernetes 中使用即將移除的 Beta 版 API

在這個範例中，某公司使用 CustomResourceDefinition apiextensions.k8s.io/v1beta1 API，但該 API 將在 1.22 版中移除。 如果公司執行的版本低於 1.22，叢集管理員會設定下列排除項目：

  • 不執行任何次要升級作業：將客戶應用程式從 apiextensions.k8s.io/v1beta1 遷移至 apiextensions.k8s.io/v1 時，暫停三個月的次要升級作業。

範例：公司舊版資料庫無法因應節點集區升級

在這個範例中，某公司執行的資料庫無法妥善回應節點集區升級期間發生的 Pod 驅逐和重新排程作業。叢集管理員會設定下列排除項目：

  • 不執行任何次要或節點升級作業：凍結節點升級作業三個月。當公司準備好接受資料庫停機時，就會觸發手動節點升級。

後續步驟