您可以透過推出作業排序功能，管理多個環境中各個 Google Kubernetes Engine (GKE) 叢集的自動升級順序。舉例來說，您可以在升級正式環境叢集之前，先在試產叢集檢驗新版本。GKE 也提供這個功能的舊版「以車隊為基礎的推出順序」，但功能較為有限，不建議用於新環境。
本文假設您瞭解下列項目：
如要設定推出作業序列，請參閱「使用自訂階段，依序推出叢集升級作業」。總覽
透過 GKE 推出作業排序功能，您可以為各環境的叢集升級作業定義特定順序，例如先升級開發環境中的叢集，然後是測試環境，最後是正式環境。這項漸進式策略提供內建的烘烤時間，讓您在升級影響最重要的系統前，找出並解決潛在問題。
推出作業排序功能是以機群的概念為基礎建構而成，機群是與環境 (例如測試) 對應的 GKE 叢集邏輯分組。如要使用這項功能，請定義由機群組成的序列，並設定各群組之間的浸泡時間。GKE 選取新版本後，叢集會依定義的順序升級，讓您在版本完全部署至正式環境前，先驗證工作負載。
機群支援輕量型成員資格，可讓您有條理地將叢集分組，以便依序推出，不必啟用所有機群層級設定和功能。如果您想使用推出順序，但不想受到完整機群管理的其他影響 (例如機群層級的命名空間相同)，輕量型成員資格就是不錯的選擇。詳情請參閱「輕量型成員資格」。
選擇推出順序策略
GKE 提供兩種推出作業排序功能。這兩個版本都以相同的核心原則為基礎，也就是以車隊為基礎的漸進式升級，但我們建議為新環境使用自訂階段的推出順序：
- 透過自訂階段推出 (建議用於新環境)：這個版本是機群架構的進階版，可提供更精細的控制和彈性，但缺少 Google Cloud 控制台支援。使用自訂階段時，您可以透過標籤定義機群內的特定階段，因此適合較複雜的推出策略，例如在全面推出新版本前，先在小部分正式環境叢集上部署新版本。此外，您還能進一步控管推出作業，例如針對特定版本啟動推出作業、選擇要在序列中推出的升級類型，以及暫停或取消推出作業。如果這是你第一次建立推出順序，請選擇這個選項。
- 以車隊為準的推出順序： 這是唯一可透過 Google Cloud 管理中心使用的功能版本，但功能較為有限。如果您是第一次建立推出順序，建議不要使用這個版本。
本文其餘內容僅適用於使用自訂階段的推出順序。
使用自訂階段排序推出作業
使用推出作業排序功能和自訂階段時，您可以定義機群升級順序並設定浸泡時間。此外，您也可以執行下列操作：
- 定義具有精細階段的序列，即可使用標籤指定機群內的特定叢集子集，因此非常適合用於階段性推出等策略。
- 透過新的
RolloutSequence和RolloutAPI 物件，進一步控管及監控廣告活動。
這個方法可讓您最靈活地精細控管叢集升級作業。如要指定機群內的特定叢集子集，請使用 label-selector，只指定具有特定 Kubernetes 標籤的叢集。
下圖說明 GKE 如何依據使用自訂階段的推出作業序列，自動升級叢集。階段會以 prod 叢集中的 label-selector 為目標，並命名為 canary：
GKE 推出新版本時，會先升級測試機群中的叢集，再升級預備機群中的叢集。接著，在 Production 機群中，GKE 會優先處理符合 label-selector 的叢集。由於 prod-cluster-1 標示為 canary:
true，GKE 會優先升級這個叢集。由於這個階段沒有任何標籤選取器，因此在程序結束時，GKE 會升級 Production 機群 (位於 Main 階段) 中的所有其餘叢集。
在設定的階段過渡期內，您可以確認工作負載在升級的叢集上正常運作。上述範例顯示 Production 叢集中的一個自訂階段，但您可以為任何叢集新增多個階段，或只使用一個叢集並包含多個階段。
基本概念
- 浸泡時間：可設定的等待時間，會在階段中的所有叢集升級後發生。這段時間可讓您在一個環境中驗證新版本，並在升級至下一個環境前找出潛在問題。您可以為序列中的每個階段設定最多 30 天的緩衝期。前製階段的浸泡時間越長，驗證時間就越充裕。
RolloutSequence：這個物件是定義升級順序的主要資源。RolloutSequence包含一系列依序執行的階段，可驗證升級作業是否已完全完成，且叢集是否已完成浸泡期，再繼續下一個階段。每個RolloutSequence都有一個Rollout，對應每個推出的新版本。Rollout：這個物件可讓您透過序列觀察單一版本升級的進度。您可以使用Rollout查看發布狀態、追蹤進度，以及查看是否有任何叢集不符合升級資格，並瞭解原因。每個Rollout都與特定RolloutSequence相關聯，代表版本發布的順序。- 專屬主機專案：建議您使用專屬Google Cloud 專案來代管
RolloutSequence物件。將序列放在專屬專案中，可為推出序列提供中立的中央控制點，這與管理 CI/CD 管道的最佳做法類似。
在專屬主機專案中建立及管理 RolloutSequence 資源。
- 階段：階段是推出作業序列中的步驟。每個階段都包含一組叢集，這些叢集會一起升級。
- 機群：機群是叢集的主要分組方式。推出順序中的階段只能參照一個機群。
- 標籤選取器：推出順序是由一或多個階段組成。每個階段都包含一個機群的叢集，您可以使用叢集上的標籤選取器，將機群進一步分割成多個階段。這種做法可採用階段性推出等策略，先升級一小部分生產叢集。
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 經過徹底審查，再導入銀行重要的正式環境。他們也希望先在流量較低的區域逐步升級叢集，然後再移至流量較高的區域，最後再移至最重要的區域。為此，他們使用自訂階段的推出順序，定義漸進式升級策略，包括根據區域標記生產叢集。這樣一來，他們就能在全面推出新版本前，先對一小部分的實際工作環境流量進行驗證。
如要實作這項計畫，管理員會將下列標籤套用至 Production 艦隊中的叢集：
us-west1(流量較低) 中的叢集會標示prod-region: us-west1。europe-west1(流量較高) 中的叢集會標示prod-region: europe-west1。us-east1(最重要流量) 中的叢集未加上標籤。序列中機群的最後一個階段必須做為所有剩餘叢集的「萬用」階段。因此管理員不需要為這些剩餘的叢集新增標籤。
接著，他們會在用於管理 CI/CD 設定的專屬主機專案中，定義 RolloutSequence 物件。這項新序列包含五個明確階段：
- 測試：這個階段包含
testing機群中的所有叢集。管理員設定了 3 天的浸泡時間，以便進行徹底驗證。 - 預先發布：這個階段包含
staging叢集中的所有叢集，浸泡時間為三天。 - 區域
us-west1中的正式版：這個階段的目標是正式版機群，但會使用label-selector，只納入具有prod-region: us-west1標籤的叢集。在這個階段，管理員可以監控一小部分正式叢集是否有任何問題，並等待三天。 - 區域
europe-west1中的正式環境：這個階段包含具有prod-region: europe-west1標籤的production機群中的叢集。管理員將浸泡時間延長至四天，以進行更徹底的驗證。 - 在
us-east1地區中進行生產：這個最後階段包含production機群中的其餘叢集，也就是us-east1中的所有叢集。
這種做法可讓管理員精細控管生產環境升級作業，在潛在問題影響整個生產環境前就先找出，大幅提升升級程序的安全性和可靠性。
在例行修補程式升級期間，銀行的自動化測試在預先發布環境中順利完成，速度比預期快得多。管理員發現新版本穩定，因此認為這類例行更新不需要在升級 Staging 叢集後等待三天。
為加快推出速度，管理員會修改RolloutSequence定義，並縮短正式版機群us-west1階段的浸泡時間。由於這項 RolloutSequence 定義變更會更新所有現有和未來推出作業的預設浸泡時間，因此管理員會記下，在完成這項特定修補程式推出作業後，將浸泡時間還原為原本的三天。這種做法可確保日後進行次要版本升級時，能採用標準且更謹慎的浸泡時間。
管理員使用維護期間和排除項目，讓 GKE 在對銀行影響最小的時段升級叢集。GKE 會尊重按推出作業序列升級的叢集維護可用性：
- 系統管理員為叢集設定維護期間，因此 GKE 只會在下班後升級叢集。
- 如果管理員發現叢集工作負載有問題，也可以使用維護作業排除時段，暫時防止叢集升級。
此外，管理員可以管理推出程序，例如偵測到問題時暫停推出程序，或對該階段的變更有信心，且準備好立即繼續時，完成該階段。
管理員會為節點混合使用突波升級和藍綠升級，並根據節點上執行的工作負載，在速度和風險容許度之間取得平衡。
GKE 如何開始推出新版本
根據預設，設定新的自動升級目標時，GKE 會建立新的推出作業。GKE 選擇推出的版本取決於序列中叢集的子版本和發布版本。舉例來說，如果叢集在「一般」管道中執行 GKE 1.35 版，且 GKE 將自動升級目標設為 1.35.5-gke.1000000，GKE 就會建立新的 Rollout。
不過，您也可以選擇要 GKE 推出哪個版本。
推出特定版本
舉例來說，如果您想快速修補安全漏洞，或修正 GKE 叢集的重大問題，也可以啟動特定版本的發布作業。這項動作會建立 Rollout 物件，並啟動推出作業，在推出作業序列中進行推出作業，與 GKE 設定自動升級目標時相同。如要推出新版本，請參閱「推出特定版本」。
如要盡快將新版本推出至叢集，您也可以對個別叢集執行手動叢集升級。手動升級叢集時，作業會在叢集層級執行。
選擇 GKE 在推出作業序列中執行的升級類型
根據預設，GKE 會將所有類型的叢集升級作業，包括控制層和節點的修補程式版本和子版本升級，都納入推出順序。
升級主要分為四種類型：
- 控制層的修補程式版本升級
- 節點的修補程式版本升級
- 控制層的次要版本升級
- 節點的子版本升級
您可以限制推出順序中的叢集升級範圍，只執行特定類型的升級。舉例來說，如果您希望 GKE 只推出控制層升級，而非節點升級，可以在推出作業順序中指定這項設定。
如果限制推出作業序列的叢集升級範圍，GKE 就不會為推出作業序列中的任何叢集執行該類型的自動升級，但必要時仍會執行強制自動升級。詳情請參閱「強制自動升級的推出時間」。限制叢集升級範圍不會取消進行中的推出作業，只會防止 GKE 在未來建立這類推出作業。
由於 GKE 不會將叢集的節點升級至比控制層更新的版本，因此限制控制層升級範圍也能限制節點升級。
如要限制推出作業序列中的自動升級範圍，請參閱「選擇 GKE 在推出作業序列中執行的升級類型」。
限制推出順序的範圍與維護排除時段類似，但維護排除時段是針對個別叢集或叢集內的節點集區設定。
強制自動升級的推出時間
無論叢集是否已加入推出作業序列，GKE 都會自動升級叢集，確保安全性和相容性。如果推出順序中的叢集控制層在 90 天內未升級，或叢集執行的子版本已終止支援，GKE 會建立強制性推出作業，執行自動升級。這些推出作業可確保叢集維持高效能、可用性和安全性。無論推出範圍的限制、維護排除項目或任何其他延遲原因為何，GKE 都會為這些情況建立推出作業。
這類推出作業無法暫停或取消。無論是否已註冊推出作業序列，GKE 都會執行這類叢集升級。
如要進一步瞭解這些政策，請參閱以下各節：
推出作業資格
如要透過使用自訂階段的序列推出版本，叢集必須符合從發布管道升級目標的資格。當有新的 GKE 版本可用時，如果序列中的叢集符合新版本資格，系統就會建立 Rollout 物件。雖然建議所有叢集都加入同一個發布版本，但如果不是，GKE 會從序列中最保守的管道選取版本。舉例來說，如果叢集混合使用穩定版和一般版，GKE 會選擇穩定版中的版本。
Rollout 接著會依序完成 RolloutSequence 中定義的階段。在特定階段中，控制層推出作業和節點集區推出作業可以平行執行。這項進展的主要規則是，當階段處於 SOAKING 狀態且使用特定版本時，該階段不符合開始新 Rollout 的資格，因此無法使用新版本。這麼做可確保版本在下一次升級前經過完整驗證。您可以監控 Rollout 物件，觀察每個叢集的進度和資格。如果發現版本差異導致叢集不符合資格，您可能需要採取行動，例如手動升級叢集或在推出作業序列中忽略叢集，才能繼續進行推出作業。如果叢集不符合任何推出作業的資格，GKE 就不會自動升級叢集，直到需要為強制自動升級建立推出作業為止 (如上一節所述)。
如果叢集執行的版本高於升級目標，不會妨礙升級
如果序列中的某個階段包含執行版本較發布目標版本更新的叢集，GKE 會升級符合目標版本資格的叢集，並忽略已使用較新版本的叢集。但這不會妨礙推出作業進入下一階段。
舉例來說，如果某個階段的推出作業目標版本為 1.32，且該階段有執行 1.31 和 1.33 的叢集，則 GKE 會將 1.31 版的叢集升級至 1.32 版，並忽略已是 1.33 版的叢集。
前一階段已為後續階段選出多個升級目標
如果後續階段暫停 (例如因維護作業排除)，或仍在處理先前的升級作業，序列中的前一階段可能會完成多個新版本的推出作業。在這種情況下，當後續階段準備好接受新升級時，GKE 會將該階段升級至符合資格的最新版本。如要升級控制層，這個版本最多只能比後續階段的叢集控制層版本晚一個次要版本。如果是節點升級，這個版本可以等於後續階段叢集的控制層版本，但不得晚於該版本。
舉例來說，如果您設定維護作業排除時段，暫時禁止升級正式環境叢集，就適用這個情境。如果預先發布叢集沒有相同的維護排除項目，這些叢集可能會升級多次，符合多個新版本的資格，但生產階段不會升級。
30 天後強制浸泡
為確保推出作業序列完成叢集升級，如果控制層或節點升級作業未在最長升級時間 (30 天) 內完成，GKE 會開始為群組進行浸泡期。在浸泡期間，群組中其餘叢集的升級作業仍可繼續進行。
推出作業排序功能如何與其他升級功能搭配運作
推出作業排序功能可搭配其他 GKE 升級功能使用：
維護期間和排除時段：您仍可使用維護期間和排除時段，控管叢集升級時間。GKE 只會在叢集的維護期間內啟動叢集升級作業。您可以暫時禁止叢集升級，方法是設定維護排除期。下列兩種方法都能限制 GKE 執行特定類型的升級：
- 叢集或節點集區層級：維護作業排除時段
- 推出作業序列層級：選擇 GKE 在推出作業序列中執行的升級類型
不過，這兩種限制叢集升級範圍的方法，都無法避免強制自動升級。如果 GKE 無法在維護期間或排除時段升級叢集，叢集升級作業可能無法在某個階段完成。如果因維護時段或排除項目，導致叢集升級作業無法在 30 天內完成，無論所有叢集是否已完成升級，階段都會進入浸潤期。
節點升級策略：推出順序不會影響您設定的節點升級策略 (例如藍綠升級)。與沒有推出作業排序功能的叢集升級類似，GKE 會對 Autopilot 節點使用節點數擴充升級功能。詳情請參閱「自動升級節點」。
如果節點升級作業無法在 30 天內完成，無論所有叢集是否已完成升級，群組都會進入浸泡階段。如果節點升級策略導致 Standard 叢集的節點升級作業需要較長時間才能完成，就可能發生這種情況，尤其是在大型節點集區中。如果維護期間不夠長，無法完成節點升級，情況可能會更加嚴重。
發布版本：建議您在同一個發布版本中，為所有叢集註冊推出順序。
淘汰項目使用情況偵測：GKE 的淘汰項目使用情況偵測功能仍可正常運作，可能會暫停使用已淘汰 API 的叢集升級作業。
手動升級：手動升級序列第一階段的叢集，本身不會限定該版本，也不會觸發推出作業繼續進行。自動推出程序會根據發布版本設定的官方自動升級目標進行。手動升級會更新叢集，但只有在該版本成為指定的自動升級目標後，序列才會開始推進。
叢集通知：除了其他可用的叢集通知，GKE 也提供推出作業排序通知。詳情請參閱「推出順序通知」。
在整個序列中收到多項升級
發布版本會選取叢集的升級目標。如果升級至先前目標的作業仍在進行中，但有新版本可用，即使後續階段仍會收到先前的升級版本，第一階段仍可開始推出新版本。舉例來說，如果序列中的第三個群組推出 1.31.12-gke.1265000 版，序列中的第一個群組可以同時推出 1.31.13-gke.1008000 版。
選擇推出作業排序功能時的注意事項
如要管理叢集升級作業，先在一個環境中檢驗新版本，再推出至其他環境，建議使用推出作業排序功能。
不過，如果符合下列任一條件，這項策略可能不適合您的環境：
- 您在同一個正式環境中，有發布管道或子版本不同的叢集。
- 您經常執行手動升級，導致某個群組中的叢集自動升級目標版本不同。
推出作業排序通知
GKE 會傳送叢集通知，提供叢集層級的叢集升級重要資訊。此外，GKE 也會提供通知，說明具有自訂階段的推出作業序列，以及透過這些推出作業序列進行的推出作業。舉例來說，GKE 會在推出階段開始、完成或遭到封鎖時傳送通知。或者，如果您設定的推出順序有誤，GKE 也會傳送通知。詳情請參閱「叢集通知」文件，以及 RolloutEvent 和 RolloutSequenceEvent 的相關章節。
管理推出作業
當 GKE 在推出順序中的叢集推出新版本時，您可以採取下列動作來控管程序，同時評估叢集和工作負載對變更的反應。此外，您也可以建立新的推出作業，推出特定版本。
升級作業進行期間，你可以查看狀態。您可以根據升級進度，使用下列小節說明的動作。
暫停推出作業
您可以暫停進行中的推出作業。舉例來說，如果您發現叢集和新版本可能存在問題，可以暫時暫停推出程序。GKE 不會啟動升級至這個版本的新作業，讓您視需要調查任何問題。GKE 不會停止進行中的升級作業，但不會啟動新的升級作業，包括後續階段的作業。
如要暫停推出，請參閱「暫停推出」一文。
暫停發布作業後，您可以繼續或取消發布作業。推出作業最多可暫停 90 天。90 天後，GKE 會取消推出作業。
暫停推出作業後，後續的推出作業仍會照常啟動。不過，這些推出作業不會取代已暫停的推出階段。舉例來說，如果 GKE 已在第一和第二階段推出 1.34.8-gke.1000000，且您在第三階段暫停推出作業，GKE 就能開始推出 1.35.5-gke.1163000，並升級前兩個階段的叢集。不過，在 1.34.8-gke.1000000 版在第三階段推出完畢或取消之前，GKE 不會在第三階段開始升級至 1.35.5-gke.1163000 版。
如果發布序列有多個發布作業正在進行，且您想全部暫停，則必須個別暫停每個發布作業。如要防止 GKE 啟動其他推出作業，可以選擇 GKE 在推出作業序列中執行的升級類型。
繼續推出作業
如果暫停發布的時間未超過 90 天，您可以在調查完所有潛在問題後恢復發布，讓升級作業繼續進行。只有在同一階段沒有執行其他相同類型 (控制平面推出或節點推出) 的推出作業時，才能繼續執行已暫停的推出作業。如果 GKE 基於技術或業務原因自動暫停推出作業，您也可以恢復作業，但建議先謹慎評估再採取行動。
如果繼續推出作業，GKE 會啟動新的升級作業，繼續在推出作業序列的各個階段推出新版本。
如要繼續發布，請參閱「繼續發布」。
取消推出作業
您可以取消推出作業，包括處於有效或暫停狀態的推出作業。取消發布後，GKE 不會自動建立新發布作業，將相同版本發布至相同節點集區。不過，取消推出作業不會阻止 GKE 推出後續版本。如要停止 GKE 推出任何後續版本，請取消所有進行中的推出作業，並限制推出作業序列中的叢集升級範圍。
如要取消推出作業，請參閱「取消推出作業」。
如要推出已取消的相同版本，請推出特定版本。
完成發布階段
如果您確信某個版本可以進入發布順序的下一個階段 (例如您已完成該階段的測試)，即可完成該階段，手動推進發布程序。如果您完成階段，GKE 尚未升級的叢集就不會升級。完成此階段後，系統也會跳過剩餘的浸泡時間。這項動作也表示您不必在推出順序層級變更浸泡時間。
如要完成推出階段，請參閱「完成推出階段」。
透過變更推出作業序列管理發布作業
您也可以採取影響整個推出順序的動作，管理推出作業。不過，建議您先採取前幾節所述的行動 (例如暫停推出)，再執行這項操作。如果對推出順序進行部分變更，可能會導致進行中的推出作業取消，也會影響日後在該順序中推出的作業。如要變更其中一個推出版本，請使用提供的工具管理該版本，而非變更整個序列。
不過，如果您想變更所有推出作業的推出作業序列功能 (不只是推出新版本)，請參閱下一節「管理推出作業序列」。
控管個別叢集的升級作業，管理發布程序
如要升級個別叢集，可以使用下列工具管理升級作業：
詳情請參閱「如何搭配其他升級功能使用推出順序」。
管理推出作業序列
如要管理推出順序，您可以執行下列基本動作：
- 列出推出作業序列
- 說明推出作業序列
此外，您也可以執行修改推出順序、在推出順序中忽略叢集等動作。以下各小節將說明這些動作。
如要進一步瞭解如何管理單一版本推出作業，而非整個推出作業序列，請參閱上一節「管理推出作業」。
忽略推出作業序列中的叢集
根據預設，推出順序中的任何叢集都會在推出順序中升級。您可以將叢集新增至特定階段，或是升級機群中未標記的任何叢集。
不過，如果您不想將某個叢集納入推出順序，可以為該叢集加上標籤，讓 GKE 在推出新版本時忽略該叢集。舉例來說，如果您需要更多時間才能升級特定叢集，可能就需要這麼做。您可以忽略推出作業序列中的一或多個叢集。
如果忽略推出作業序列中的叢集，GKE 推出新版本時不會將其納入考量，也不會為該叢集執行自動升級 (強制自動升級除外)，包括支援期限結束時的自動升級，以及控制層在 90 天內未升級時的自動升級。
如要略過推出作業序列中的叢集，請參閱「略過推出作業序列中的叢集」。
修改推出作業序列
如要變更現有推出作業序列的推出方式，可以透過下列兩種方式修改序列：
- 如要修改推出順序，請編輯定義順序的 YAML 設定檔。
- 修改序列中的叢集。
修改推出作業序列時，會發生下列情況：
- 如果您在推出程序中新增、移除、變更階段順序或編輯階段 (例如變更該階段的專案 ID 或標籤選取器)，GKE 會取消所有進行中的推出作業。
- 如果您變更階段的浸泡時間，GKE 不會取消進行中的推出作業。
如要修改推出作業序列，請參閱「修改推出作業序列」。
如果依序修改叢集，會發生下列情況：
- 如果從機群中移除叢集，藉此從推出序列中移除叢集， 系統會繼續推出。 如果叢集未註冊序列，GKE 會根據叢集的典型程序自動升級。
- 如果您在推出作業序列中將叢集新增至機群，GKE 會在任何尚未通過新增階段的有效推出作業中，升級這個叢集。不過，如果推出作業的階段已完成，GKE 就不會升級該推出作業中的叢集。
如果將叢集移至不同階段，但未編輯推出順序設定，則會發生下列情況 (視叢集移至的階段是否已完成而定)：
- 如果將叢集移至已完成推出作業的階段，GKE 不會升級該叢集。
- 如果將已在推出作業中升級的叢集移至後續未完成的階段，GKE 會忽略該叢集，不會中斷推出作業的進度。
如要修改序列中的叢集，請參閱「向機群註冊叢集 Google Cloud 」。
限制
使用自訂階段的推出順序升級叢集時，請注意下列限制：
- 您無法使用 Google Cloud 控制台建立或查看含有自訂階段的推出順序。
- 推出作業序列參照機群時，您必須納入整個機群。這項限制表示，如果您定義的階段只會以機群中的部分叢集為目標 (例如用於分階段部署)，則也必須定義後續的「全包」階段，納入同一機群中的所有其餘叢集。
label-selector這個適用於所有叢集的階段會以相同機群為目標，但不包含label-selector，因此會自動納入序列中先前階段未選取的所有叢集。 - 如果在推出期間修改序列，尤其是影響參與叢集的變更，GKE 會立即取消所有現有的推出作業。如果只修改序列的浸泡時間，GKE 不會取消推出作業。
- 一個階段最多只能參照一個車隊。單一階段中無法有多個車隊。
- 單一車隊只能在一個推出順序中參照。兩個推出程序不得參照相同的車隊。
- 如果叢集使用加速修補程式自動升級功能，就無法透過推出作業排序功能升級。
- 您最多可以建立 15 個階段的推出序列。
- 機群最多可包含 250 個叢集。如果是輕量型成員資格的叢集，您可以申請提高配額，在車隊中最多可有 2,000 個叢集。詳情請參閱「配額與限制」。
- 您最多可以為每個序列設定 90 天的浸泡時間。
已知問題
本節說明使用自訂階段推出時的已知問題。
- 如果推出順序中的某個階段不含任何叢集，系統會略過該階段，但仍會經過為該階段定義的浸泡時間，才會繼續推出下一個階段。