您可以透過推出作業排序功能，管理不同環境中各個 Google Kubernetes Engine (GKE) 叢集的自動升級順序。舉例來說，您可以在升級正式環境叢集之前，先在試產叢集檢驗新版本。GKE 也提供這個功能的最新版本，即自訂階段的推出順序，功能更強大。該版本可更精細地控管叢集升級作業，建議用於新環境。
本文假設您已瞭解下列事項：
如要設定推出作業序列，請參閱「依序推出叢集升級作業」。總覽
透過 GKE 推出作業排序功能，您可以為各環境的叢集升級作業定義特定順序，例如先升級開發環境中的叢集，再升級測試環境，最後升級正式環境。這項漸進式策略提供內建的烘烤時間，讓您在升級影響最重要的系統前，找出並解決潛在問題。
推出作業排序功能是以機群的概念為基礎，機群是與環境 (例如測試) 對應的 GKE 叢集邏輯群組。如要使用這項功能，請定義由機群組成的序列，並設定各群組之間的浸泡時間。GKE 選取新版本後，叢集會依定義的順序升級，讓您在版本完全部署至正式環境前，先驗證工作負載。
機群支援輕量型成員資格，可讓您有條理地將叢集分組，以便依序推出，不必啟用所有機群層級設定和功能。如果您想使用推出順序，但不想受到完整機群管理的其他影響 (例如機群層級的命名空間相同)，輕量型成員資格就是不錯的選擇。詳情請參閱「輕量型會員方案」。
選擇推出順序策略
GKE 提供兩種推出作業排序功能版本。這兩個版本都以相同的原則為基礎，逐步升級車隊，但我們建議在新環境中使用推出作業排序功能和自訂階段：
- 使用自訂階段推出順序 (建議用於新環境)： 這個版本是機群架構的進階版，可提供更精細的控制選項和彈性，但缺少 Google Cloud 控制台支援。使用自訂階段時，您可以透過標籤定義機群內的特定階段，因此適合較複雜的推出策略，例如先在小部分正式環境叢集部署新版本，再大規模推出。此外，您還能進一步控管推出作業，例如針對特定版本啟動推出作業、選擇要在序列中推出的升級類型，以及暫停或取消推出作業。如果您是第一次建立推出順序，請選擇這個選項。
- 以車隊為準的推出順序：是唯一可搭配 Google Cloud 控制台使用的功能版本，但功能較為有限，如果您是第一次建立推出順序，建議不要使用這個版本。
本文其餘內容僅適用於以車隊為基礎的推出順序。
以機群為基礎的推出作業排序
如要使用推出順序自動升級叢集，請使用機群，將具有相同發布管道和子版本的叢集分組到部署階段。定義機群序列，以及各叢集群組之間的過渡時間。接著，當 GKE 在發布管道中選取新版本進行自動升級時，系統會按照您定義的順序升級叢集群組，您可以在升級正式環境叢集之前，先驗證工作負載是否能在新版本中正常運作。
下圖說明 GKE 如何依據按機群排序的推出作業序列，自動升級叢集：
採用機群序列時，如果 GKE 在發布管道中提供新的升級目標，且該管道已註冊此序列中的所有叢集，GKE 就會升級此序列中的叢集機群，上游機群的叢集會為下游機群的叢集限定新版本，最多可升級五個機群。在推出作業序列中，「上游」是指前一個群組，「下游」是指下一個群組。
在機群之間設定的浸泡時間內，您可以確認工作負載在升級的叢集上是否正常運作。
GKE 如何依據推出作業序列升級叢集
GKE 升級叢集時，會先升級控制層，再升級節點。在推出作業序列中，叢集仍會使用這個程序升級，但您也可以控管叢集群組 (機群) 的升級順序。您也可以指定浸泡時間，定義 GKE 暫停升級的時間長度，再從一個群組繼續升級到下一個群組。
推出作業排序功能會依下列步驟升級叢集：
- GKE 會在推出作業序列中啟動新的推出作業。根據預設，當 GKE 為特定發布管道中子版本上的叢集設定新的自動升級目標時，就會開始推出作業。如要使用自訂階段推出序列，也可以觸發新的推出作業，將推出序列中的特定版本發布給所選使用者。
GKE 會開始將第一組叢集的叢集控制層升級至新版本。GKE 升級叢集的控制層後，就會開始升級叢集的節點。在推出作業序列中升級叢集時，GKE 會遵守維護作業可用性。
GKE 會依下列步驟升級控制層：
- 第一組中的所有叢集控制層升級作業完成後，GKE 就會開始控制層升級的過渡期。如果控制層升級作業開始後已超過 30 天，GKE 也會開始過渡期。
第一組叢集控制層升級的浸泡期結束後，GKE 就會開始將第二組的控制層升級至新版本。不過，請注意下列事項：
- 在某些情況下，GKE 可能會先多次升級第一組的叢集控制層，再升級第二組的叢集控制層。發生這種情況時，GKE 會選擇最新版本，且該版本也具備下列屬性：
- 版本由第一個群組決定。
- 版本最多比第二組叢集的控制層版本晚一個子版本。
- 如果第二組叢集的版本比第一組叢集合格的版本新，GKE 就不會升級第二組叢集的控制層。
- 在某些情況下，GKE 可能會先多次升級第一組的叢集控制層，再升級第二組的叢集控制層。發生這種情況時，GKE 會選擇最新版本，且該版本也具備下列屬性：
在升級控制層的同時，GKE 會執行下列節點升級步驟：
- 第一個群組中的所有叢集完成節點升級後，GKE 會開始節點升級的過渡期。如果節點升級作業開始後已超過 30 天，GKE 也會開始過渡期。
- 第一個群組的節點升級完成並經過浸泡期後，GKE 就會開始將第二個群組的節點升級至新版本。不過，請注意下列事項：
- 在某些情況下，GKE 可能會先多次升級第一個群組的叢集節點，再升級第二個群組的叢集節點。發生這種情況時，GKE 會選擇最新版本，且該版本也具備下列屬性：
- 版本由第一個群組決定。
- 版本不晚於第二個群組的叢集控制層版本。
- 如果第二個群組的叢集節點版本高於第一個群組的合格版本，GKE 就不會升級這些節點。
- 在某些情況下，GKE 可能會先多次升級第一個群組的叢集節點，再升級第二個群組的叢集節點。發生這種情況時，GKE 會選擇最新版本，且該版本也具備下列屬性：
GKE 會從第二個群組到第三個群組重複執行這些步驟，直到推出序列中所有群組的叢集都升級至新版本為止。
在每個群組的叢集升級期間，請在浸泡時間內確認工作負載在執行新版 GKE 的叢集上是否正常運作。
此外，維護時段或排除項目、已淘汰的 API 用量或其他原因，也可能導致叢集無法升級。
如何控管推出作業序列中的升級
透過推出作業排序功能升級叢集時，系統會按照您定義的順序升級叢集群組，並在每個群組中浸潤您選擇的時間長度。 升級期間，您可以查看狀態，並視需要管理推出順序。你也可以透過下列方式控管程序：
- 如要為特定版本設定較長或較短的浸泡時間，可以覆寫推出順序中群組的預設浸泡時間。
- 如要個別升級叢集，可以使用下列工具：
範例：社區銀行逐步將變更從測試環境推出至正式環境
舉例來說，社群銀行的平台管理員管理三個主要部署環境：測試、預備和正式環境。每個環境都有一組叢集，並以機群形式整理。根據推出順序規定，管理員已在所有三個機群中，為每個叢集註冊相同的發布管道 (在本例中為一般管道)，且所有叢集都執行相同的子版本。
管理員會使用推出作業排序功能，定義 GKE 在這些環境中升級叢集的順序。管理員可透過推出作業排序功能，先在叢集上驗證工作負載是否能以新版 GKE 正常運作，再將正式環境升級至新版本。如要瞭解這個序列，請參閱以機群為基礎的推出作業序列圖。
管理員會利用機群之間的浸泡時間，確認工作負載在新版 GKE 上正常運作。對於測試機群，管理員將浸泡時間設為 14 天，這樣他們就有整整兩週的時間，測試工作負載的執行情況。對於 Staging，他們將浸泡時間設為 7 天，因為工作負載已在測試中執行，因此不需要額外時間。
管理員也可以針對特定版本升級作業，覆寫預設的浸泡時間。在下列情況中，管理員可能會想這麼做：
- 管理員在浸泡時間結束前完成版本資格認證，並希望升級作業繼續進行至下一個機群，因此將浸泡時間設為零。
- 管理員發現部分工作負載有問題，因此需要更多時間驗證新版本，才能將升級作業移至下一個機群，因此將浸泡時間設為最長 30 天。
管理員會使用維護期間和排除時段，讓 GKE 在對銀行影響最小的時機升級叢集。如果叢集是依推出作業序列升級，GKE 會遵守叢集的維護可用性。
- 系統管理員已為叢集設定維護期間，因此 GKE 只會在營業時間後升級叢集。
- 如果管理員發現叢集工作負載有問題，也可以使用維護作業排除時段，暫時防止叢集升級。
管理員會為節點混合使用突增升級和藍綠升級，並根據節點上執行的工作負載，在速度和風險容許度之間取得平衡。
以車隊為基礎的推出資格
如要透過推出作業排序功能自動升級叢集，推出作業序列中所有機群的所有叢集都必須採用相同的升級目標。叢集必須在同一個發布管道中註冊，且建議叢集執行相同的子版本，因為升級目標是依子版本設定。不過，在某些版本中 (例如以下範例)，多個子版本的叢集會收到相同的目標，也就是說，叢集可以在執行多個子版本的推出序列中成功升級。
您可以依序檢查版本推出狀態，進一步瞭解狀態，以及版本資格問題是否導致升級程序無法繼續。視版本差異而定，您可能需要採取行動，例如手動升級叢集或從群組中移除叢集，才能繼續升級叢集。如果推出作業序列中的叢集沒有符合資格的升級目標，GKE 就不會自動升級叢集，直到叢集現有的子版本終止支援為止。
如要排解推出資格問題，請參閱「排解推出資格問題」。
GKE 發布版本範例
舉例來說，2025-R45 版本為註冊至「一般版」管道的叢集，設定了多個子版本的升級目標。升級目標可以是新的子版本 (1.30 至 1.31)，也可以只是新的修補程式版本 (1.31.x-gke.x 至 1.31.13-gke.1023000)。在此版本中，我們在一般版管道中，為特定子版本的叢集提供下列新版本：
- 1.30 版的叢集已升級至 1.31.13-gke.1023000。
- 1.31 版的叢集已升級至 1.32.9-gke.1108000。
- 1.32 版的叢集已升級至 1.33.5-gke.1162000。
最上游的群組會收到所有升級目標
對於序列中第一個群組的叢集，由於沒有上游群組可限定新版本，因此無論升級目標是否不同，GKE 都會升級任何符合升級目標的叢集。舉例來說，在序列的第一個群組中，如果某些叢集執行的是 1.30，這些叢集可以升級至 1.31.13-gke.1023000，而執行 1.32 的叢集可以升級至 1.33.5-gke.1162000。這是因為對於序列中的第一個群組，GKE 會將所有升級目標視為符合這些叢集的資格，因為沒有上游群組可限定新版本。
上游群組只能限定一個版本
如要開始升級任何下游群組中的叢集，上游群組必須先成功確認單一通用升級目標，且下游群組中的所有叢集都符合資格。如果上游群組的叢集已成功升級至兩個不同版本 (當上游群組是序列中的第一個群組時，可能會發生這種情況)，則上游群組會將兩個版本中較低的那個版本，做為下游群組的共同升級目標。舉例來說，如果上游群組的部分叢集升級至 1.31.13-gke.1023000，其他叢集升級至 1.33.5-gke.1162000，則該群組會將 1.31.13-gke.1023000 設為下游群組的通用升級目標。
如果叢集執行的版本高於升級目標，不會妨礙升級作業
如果下游群組的叢集執行版本比上游群組限定的升級目標更新，GKE 會升級符合升級目標資格的叢集，並忽略已使用更新版本的叢集。只要下游群組中至少有一個叢集符合升級目標的資格，推出作業序列就不會受到影響。
舉例來說，如果上游群組將升級資格限定為 1.32，而下游群組有執行 1.31 和 1.33 的叢集，GKE 會將執行 1.31 的叢集升級至 1.32，並忽略執行 1.33 的叢集。
上游群組必須限定與下一個群組叢集相符的版本
如果上游群組中的叢集限定的版本，與下一個群組中叢集適用的版本不同，GKE 也無法自動升級任何下游群組中的叢集。
舉例來說，如果第一個群組中的所有叢集都已升級至 1.31.13-gke.1023000，但第二個群組中的叢集執行的是較新版本 (例如 1.32.9-gke.1108000)，則第二個群組的叢集不會自動升級。第一個群組已符合 1.31.13-gke.1023000 的資格，但第二個群組 (目前為 1.32) 中的叢集只符合升級目標 1.33.5-gke.1162000 的資格，因此 GKE 無法自動升級這些叢集。如要在這種情況下繼續升級，請參閱「修正群組間的資格問題」。
上游群組為下游群組限定多個升級目標
如果 GKE 在升級下游群組中的叢集前，多次升級上游群組中的叢集，GKE 會將下游群組中的叢集升級至上游群組限定的最新版本，且下游群組中的叢集必須符合資格。如果是控制層升級，這個版本最多只能比下游群組中叢集的控制層版本晚一個子版本。如果是節點升級，這個版本可以與下游群組中叢集的控制層版本相同，但不得晚於控制層版本。
舉例來說，如果您已設定維護作業排除時段，暫時禁止下游群組 (包括正式環境叢集) 升級，就適用這個情境。不過，您的上游群組 (包括前置製作叢集) 並未一併使用維護作業排除時段，因此升級作業仍會進行。因此，上游群組已升級多次，符合多個潛在升級目標的資格，但下游群組尚未升級。
如未在 30 天內完成升級，系統會強制進行 Soak 測試，以解除序列封鎖
為確保推出作業序列完成叢集升級，如果控制層或節點升級作業未在最長升級時間 (30 天) 內完成，GKE 會開始群組的過渡期。在浸泡期間，群組中其餘叢集的升級作業仍可繼續進行。詳情請參閱「推出順序表格的狀態資訊」中的 FORCED_SOAKING 列。
以機群為基礎的推出作業排序功能如何搭配其他升級功能運作
推出順序是其中一項功能，可讓您控管叢集生命週期的升級作業。本節說明這項功能如何與叢集升級相關的其他可用功能搭配運作。
以機群為基礎的推出作業排序功能如何搭配維護期間和排除時段運作
使用推出作業排序功能升級叢集時，GKE 會遵守維護期間和維護作業排除時段。GKE 只會在叢集的維護期間內啟動叢集升級作業。您可以暫時排除維護作業，避免叢集升級。如果 GKE 無法升級叢集 (因為有維護期間或排除條件)，這類情況可能會導致群組中的叢集無法完成升級。如果因維護時段或排除項目，導致叢集升級作業無法在 30 天內完成，無論所有叢集是否已完成升級，該群組都會進入浸潤階段。
您可以暫時使用維護排除項目，避免序列完成向群組推出版本，並移至下一個群組。詳情請參閱「延後完成群組版本推出作業」一文。
如何搭配使用以機群為基礎的推出作業排序功能與淘汰項目使用情況偵測功能
GKE 偵測到使用特定已淘汰的 API 和功能時，會暫停叢集升級作業。如果叢集位於推出作業順序的群組中，系統也會暫停自動升級作業。詳情請參閱「Kubernetes 淘汰項目在 GKE 中的運作方式」。
推出作業排序功能如何搭配節點升級策略運作
在推出程序中升級節點時，系統會使用設定的節點升級策略。與不使用推出作業排序功能的叢集升級作業相同，GKE 會對 Autopilot 節點使用升級作業。詳情請參閱「自動節點升級」。
如果節點升級無法在 30 天內完成，無論所有叢集是否已完成升級，群組都會進入浸泡階段。如果節點升級策略導致 Standard 叢集的節點升級作業需要較長時間才能完成，就可能發生這種情況，尤其是大型節點集區。如果維護期間不夠長，無法完成節點升級，也可能導致問題更加嚴重。
發布版本如何搭配推出作業排序功能運作
如要使用推出作業排序功能，必須使用發布管道。發布序列中所有群組的所有叢集，都必須位於同一個發布管道。
在序列中收到多個升級要求
如果叢集升級至先前升級目標的作業仍在推出序列中進行，但新版本已成為發布管道的升級目標，上游群組可以開始推出新版本，而下游群組仍會接收先前的升級。舉例來說，如果序列中的第三個群組要推出 1.31.12-gke.1265000，序列中的第一個群組可以同時推出 1.31.13-gke.1008000。
選擇以車隊為準的推出作業排序功能時的注意事項
如要管理叢集升級作業，先在一個環境中檢驗新版本，再推出至其他環境，建議使用推出作業排序功能。
不過，如果符合下列任一條件，這項策略可能就不適合您的環境：
- 您在同一個正式環境中，有發布管道或子版本不同的叢集。
- 您需要自動升級無法對應至五個部署階段的項目，因為您最多只能建立五組叢集的推出作業順序。您無法連結多個發布序列中的群組，建立超過五個群組的發布序列。以機群為基礎的序列最多可包含五個機群。
- 您經常執行手動升級，導致某個群組中的叢集自動升級目標版本不同。
以機群為基礎的推出作業排序限制
如要使用推出作業排序功能順利升級叢集，請遵守下列限制：
- 請確認推出順序中的所有叢集都已加入相同的發布管道，且未使用加速修補程式自動升級。此外，我們也建議所有叢集都執行相同的子版本，以便符合升級目標的資格。詳情請參閱「推出資格」。
- 建立不含週期 (群組的下游群組是自己的上游群組) 或分支版本 (群組有多個下游群組) 的線性推出作業序列。
- 在同一機構的叢集之間建立推出作業序列。您無法使用多個機構的叢集建立序列。
車隊推出作業排序功能的已知問題
- 如果群組包含來自不同位置的叢集，由於新版本會逐步推出，因此叢集升級功能可能暫時只適用於部分叢集。第一組叢集較有可能發生這種情況，但應該會在 1 週內解決。
- 如果推出順序中有空白群組，這會如何影響版本資格，取決於下列條件：
- 如果空白群組沒有上游群組，叢集升級作業就不會繼續進行至下游群組，因為空白群組無法限定版本。
- 如果空白群組有上游群組，所有待處理的叢集升級都會進入
COMPLETE狀態，並傳播至下游群組。
後續步驟
- 依序推出叢集升級作業。
- 瞭解如何使用自訂階段排序推出作業。