您可以透過推出作業排序功能，管理不同環境中各個 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 天，這樣就有整整兩週的時間，可以測試工作負載的執行情況。由於工作負載已在測試環境中執行，因此他們將預備環境的浸泡時間設為 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 天內完成，系統會強制執行觀察期，以便繼續進行後續作業
為確保推出作業序列完成叢集升級，如果控制層或節點升級作業未在最長升級時間 (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狀態，並套用至下游群組。