您可以透過推出作業排序功能，管理不同環境中各個 Google Kubernetes Engine (GKE) 叢集的自動升級順序。舉例來說，您可以在升級正式環境叢集之前，先在試產叢集檢驗新版本。GKE 也提供這個功能的舊版「以車隊為基礎的推出順序」，但功能較為有限，不建議用於新環境。
本文假設您已瞭解下列事項：
如要設定推出作業序列，請參閱「使用自訂階段排序推出叢集升級作業」。總覽
透過 GKE 推出作業排序功能，您可以為各環境的叢集升級作業定義特定順序，例如先升級開發環境中的叢集，再升級測試環境，最後升級正式環境。這項漸進式策略提供內建的烘烤時間，讓您在升級影響最重要的系統前，找出並解決潛在問題。
推出作業排序功能是以機群的概念為基礎，機群是與環境 (例如測試) 對應的 GKE 叢集邏輯群組。如要使用這項功能，請定義由機群組成的序列，並設定各群組之間的浸泡時間。GKE 選取新版本後，叢集會依定義的順序升級，讓您在版本完全部署至正式環境前，先驗證工作負載。
機群支援輕量型成員資格，可讓您有條理地將叢集分組，以便依序推出，不必啟用所有機群層級設定和功能。如果您想使用推出順序，但不想受到完整機群管理的其他影響 (例如機群層級的命名空間相同)，輕量型成員資格就是不錯的選擇。詳情請參閱「輕量型會員方案」。
選擇推出順序策略
GKE 提供兩種推出作業排序功能版本。這兩個版本都以相同的原則為基礎，逐步升級車隊，但我們建議在新環境中使用推出作業排序功能和自訂階段：
- 使用自訂階段推出順序 (建議用於新環境)： 這個版本是機群架構的進階版，可提供更精細的控制選項和彈性，但缺少 Cloud de Confiance 控制台支援。使用自訂階段時，您可以透過標籤定義機群內的特定階段，因此適合較複雜的推出策略，例如先在小部分正式環境叢集部署新版本，再大規模推出。此外，您還能進一步控管推出作業，例如針對特定版本啟動推出作業、選擇要在序列中推出的升級類型，以及暫停或取消推出作業。如果您是第一次建立推出順序，請選擇這個選項。
- 以車隊為準的推出順序：是唯一可搭配 Cloud de Confiance 控制台使用的功能版本，但功能較為有限，如果您是第一次建立推出順序，建議不要使用這個版本。
本文其餘內容僅適用於使用自訂階段的推出順序。
使用自訂階段排序推出作業
使用推出作業排序功能和自訂階段時，您可以定義機群升級順序並設定浸泡時間。此外，你也可以執行下列操作：
- 定義具有精細階段的序列，並使用標籤指定機群內的特定叢集子集，因此非常適合階段性推出等策略。
- 透過新的
RolloutSequence和RolloutAPI 物件，進一步控管及監控廣告活動。
這個方法可讓您在叢集升級方面享有最大的彈性和精細控制權。如要指定機群內的特定叢集子集，請使用 label-selector，只指定具有特定 Kubernetes 標籤的叢集。
下圖說明 GKE 如何依據使用自訂階段的推出作業序列，自動升級叢集。階段會以 prod 機群中名為 canary 的label-selector叢集為目標：
GKE 推出新版本時，會先升級測試機群中的叢集，再升級預備機群中的叢集。接著，在 Production 機群中，GKE 會優先處理符合 label-selector 的叢集。由於 prod-cluster-1 標示為 canary:
true，GKE 會優先升級這個叢集。由於這個階段沒有任何標籤選取器，因此在程序結束時，GKE 會升級正式版機群 (位於主要階段) 中的所有其餘叢集。
在設定的階段浸泡時間內，您可以確認工作負載是否在升級的叢集上正常運作。上例顯示生產機群中的一個自訂階段，但您可以為任何機群新增多個階段，或只使用一個機群並新增多個階段。
基本概念
- 浸泡時間：可設定的等待時間，會在階段中的所有叢集升級後發生。這段浸泡時間可讓您在一個環境中驗證新版本，並在升級至下一個環境前，找出潛在問題。您可以在序列的每個階段設定最多 30 天的浸泡時間。前製階段的浸泡時間越長，驗證時間就越充裕。
RolloutSequence：這個物件是定義升級順序的主要資源。RolloutSequence包含一系列依序執行的階段，可確保升級作業進入下一個階段前，先前階段的叢集已完成升級並度過浸泡期。每項RolloutSequence都有一個Rollout，對應每個推出的新版本。Rollout：這個物件可讓您透過序列觀察單一版本升級的進度。您可以使用Rollout查看推出狀態、追蹤進度，以及瞭解是否有任何叢集不符合升級資格，並查看原因。每個Rollout都與特定RolloutSequence相關聯，代表版本推出順序。- 專屬主機專案：建議您使用專屬Cloud de Confiance by S3NS 專案來代管
RolloutSequence物件。將序列放在專案中，可為推出序列提供中立的中央控制點，這與管理 CI/CD 管道的最佳做法類似。
在專屬主機專案中建立及管理 RolloutSequence 資源。
- 階段：階段是推出作業序列中的步驟。每個階段都包含一組會一起升級的叢集。
- 機群：機群是分組叢集的主要方式。推出順序中的階段可以參照一或多個機群。單一推出程序可包含多個機構代管的車隊。 Cloud de Confiance by S3NS
- 標籤選取器：推出順序由一或多個階段組成。每個階段都包含一或多個機群的叢集，您可以使用叢集上的標籤選取器，將機群進一步分割成多個階段。這種做法可支援階段性推出等策略，也就是先升級一小部分生產叢集。
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 經過全面審查，再導入銀行重要的實際執行環境。他們也想先在流量較低的區域逐步升級叢集，然後再移至流量較高的區域，最後再移至最重要的區域。為此，他們使用自訂階段的推出順序，定義漸進式升級策略，包括根據區域標記生產叢集。這樣就能在全面推出新版本前，先以一小部分的實際流量進行驗證。
如要實作這項計畫，管理員會將下列標籤套用至正式版機群中的叢集：
us-west1(流量較低) 中的叢集會標示prod-region: us-west1。europe-west1(流量較高) 中的叢集會標示prod-region: europe-west1。us-east1中的叢集 (最關鍵的流量) 未加上標籤。序列中機群的最後一個階段必須做為所有剩餘叢集的「萬用」階段。因此管理員不需要為這些剩餘的叢集新增標籤。
接著，在用於管理 CI/CD 設定的專屬主機專案中，定義 RolloutSequence 物件。這個新序列包含五個明確階段：
- 測試：這個階段包含
testing機群中的所有叢集。管理員設定了三天的浸泡時間，以便進行徹底驗證。 - 預先發布：這個階段包含
staging機群中的所有叢集，浸泡時間為三天。 - 區域
us-west1中的正式版：這個階段的目標是正式版機群，但會使用label-selector，只納入具有prod-region: us-west1標籤的叢集。管理員可以在這個階段監控一小部分正式版叢集，確認是否有任何問題，並等待三天。 - 區域
europe-west1中的正式環境：這個階段包含production機群中具有prod-region: europe-west1標籤的叢集。管理員將過渡期設為四天，以進行更徹底的驗證。 - 區域
us-east1中的正式環境：這個最後階段包含production機群中的其餘叢集，也就是us-east1中的所有叢集。
這種做法可讓系統管理員精細控管正式環境升級作業，在潛在問題影響整個正式環境前就先找出，大幅提升升級程序的安全性和可靠性。
在例行修補程式升級期間，銀行在預先發布環境中完成自動化測試的速度，遠比預期快。管理員發現新版本穩定，因此認為這類例行更新不需要在升級預先發布群組後，花費三天時間進行浸泡測試。
為加快推出速度，管理員會修改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 就不會升級該推出作業中的叢集。
如要建立叢集，並立即與推出階段的目標版本相符，請在建立叢集時將
--cluster-version旗標設為upgrade-target(預覽版)。如果您在建立叢集時將叢集註冊至推出順序中的特定階段，GKE 會識別該階段的目標版本，並使用該版本建立叢集。如需操作說明，請參閱「建立符合推出階段目標版本的叢集」。
如果將叢集移至不同階段，但未編輯推出順序設定，則會發生下列情況，視叢集移至的階段是否已完成而定：
- 如果將叢集移至已完成推出階段的階段，GKE 不會升級該叢集。
- 如果將已在推出作業中升級的叢集移至後續未完成的階段，GKE 會忽略該叢集，不會中斷推出作業的進度。
如要修改序列中的叢集，請參閱「向機群註冊叢集 Cloud de Confiance by S3NS 」。
限制
使用推出作業排序功能和自訂階段升級叢集時，須遵守下列限制：
- 您無法使用 Cloud de Confiance 控制台建立或查看含有自訂階段的推出序列。
- 推出作業序列參照機群時，必須包含整個機群。這項限制表示，如果您定義階段，只指定機群中的部分叢集
label-selector(例如用於分階段部署)，則也必須定義後續的「全包」階段，納入同一機群中的所有其餘叢集。這個適用於所有叢集的階段會指定相同的機群，但不包含label-selector，因此會自動納入序列中先前階段未選取的所有叢集。 - 如果在推出作業期間修改序列，尤其是會影響參與叢集的變更，GKE 會立即取消所有現有的推出作業。如果只修改序列的浸泡時間，GKE 不會取消推出作業。
- 單一車隊只能在一個推出序列中參照。兩個推出序列不得參照相同車隊。
- 每個主專案只能建立一個 RolloutSequence 物件。
- 如果叢集使用加速修補程式自動升級功能，就無法透過推出作業排序功能升級。
- 您最多可建立 15 個階段的推出序列。
- 機群最多可包含 250 個叢集。如果是輕量型成員資格的叢集，您最多可以要求增加配額，在機群中納入 2,000 個叢集。詳情請參閱「配額與限制」。
- 您最多可為每個序列設定 90 天的浸泡時間。
已知問題
本節說明使用自訂階段推出時的已知問題。
- 如果推出順序中的某個階段不含任何叢集，系統會略過該階段，但仍會經過為該階段定義的浸泡時間，才會繼續推出下一個階段。