您可以透過推出作業排序功能，管理不同環境中各個 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 推出新版本時，會先升級測試機群中的叢集，再升級測試環境機群中的叢集。接著，在實際工作環境機群中，GKE 會優先處理符合 label-selector 的叢集。由於 prod-cluster-1 標有 canary:
true，GKE 接下來會升級這個叢集。由於這個階段沒有任何標籤選取器，GKE 會在程序結束時，升級正式環境機群 (主要階段) 中所有剩餘的叢集。
在設定的階段浸泡時間內，您可以確認工作負載在升級後的叢集上正常運作。上述範例顯示 Production 機群中的一個自訂階段，但您可以將多個階段新增至任何機群，或只使用一個具有多個階段的機群。
基本概念
- 浸泡時間：可設定的等待期，在階段中的所有叢集升級後開始。這段浸泡時間可讓您在一個環境中驗證新版本，並在升級作業進入下一個環境前，找出潛在問題。您可以為序列中的每個階段設定最多 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(最重要流量) 中的叢集未加上標籤。序列中機群的最後一個階段必須做為所有剩餘叢集的「catch-all」。因此，管理員不需要為這些剩餘的叢集新增標籤。
接著，在用於管理 CI/CD 設定的專用主機專案中，定義 RolloutSequence 物件。這個新序列包含五個不同階段：
- 測試：這個階段包含
testing機群中的所有叢集。管理員設定三天的浸泡時間，以便進行徹底驗證。 - Staging：這個階段包含
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，並升級前兩個階段的叢集。不過，在第三階段，GKE 不會開始升級至 1.35.5-gke.1163000，直到 1.34.8-gke.1000000 的推出作業完成或取消為止。
如果推出序列有多項推出作業正在進行，而您想全部暫停，則必須逐一暫停。如要防止 GKE 啟動其他推出作業，可以選擇 GKE 在推出作業序列中執行的升級類型。
繼續推出作業
暫停推出後，如果暫停時間未超過 90 天，您可以在調查任何潛在問題並準備好升級後，繼續推出。只有在相同階段沒有其他同類型推出作業 (控制層推出作業或節點推出作業) 同時執行時，才能繼續執行已暫停的推出作業。您也可以恢復因技術或業務原因而由 GKE 自動暫停的推出作業，但建議您謹慎操作。
如果繼續推出，GKE 會啟動新的升級作業，繼續在推出序列的各階段推出新版本。
如要繼續推出，請參閱「繼續推出」。
取消推出作業
您可以取消推出作業，包括進行中或已暫停的推出作業。取消推出作業後，GKE 不會自動建立新的推出作業來升級至相同版本。不過，取消推出作業並不會阻止 GKE 推出後續版本。如要停止 GKE 推出後續版本，請取消所有進行中的推出作業，並限制推出作業序列中的叢集升級範圍。
如要取消推出作業，請參閱「取消推出作業」。
如需推出已取消的相同版本，請推出特定版本。
完成推出階段
如果您確信某個版本的推出作業可以進入推出序列的下一個階段 (例如您已完成該階段的測試)，可以完成該階段，手動推進推出作業。如果您完成階段，GKE 尚未升級的任何叢集都不會納入該推出作業的升級範圍。完成階段也會略過任何剩餘的浸泡時間。這也表示您不必在推出序列層級變更浸泡時間。
如要完成推出階段，請參閱「完成推出階段」。
透過變更推出作業序列來管理推出作業
您也可以採取會影響整個推出序列的操作，藉此管理推出作業。不過，在執行這項操作之前，建議您先採取前幾節所述的行動，例如暫停推出。對推出序列進行某些變更，可能會導致進行中的推出作業取消，並影響序列中日後的推出作業。如果只想變更一個推出作業，請使用提供的工具管理該作業，而不是變更整個序列。
不過，如果您想變更推出作業序列對所有推出作業 (不只是單一新版本的推出作業) 的運作方式，請參閱下一節「管理推出作業序列」。
控管個別叢集升級作業，管理推出作業
如要升級個別叢集，可以使用下列工具管理升級作業：
詳情請參閱「推出順序與其他升級功能的搭配運作方式」。
管理推出作業序列
如要管理推出序列，您可以執行下列基本動作：
- 列出推出作業序列
- 說明推出作業序列
此外，您也可以執行其他動作，例如修改推出序列，以及忽略推出序列中的叢集。以下各小節將說明這些動作。
如要進一步瞭解如何管理單一版本的推出作業，而非整個推出作業序列，請參閱上一節「管理推出作業」。
忽略推出作業序列中的叢集
根據預設，推出序列中屬於機群的任何叢集，都會在推出序列中升級。您可以將叢集新增至特定階段，或是一併升級機群中未加上標籤的任何叢集。
不過，如果您不希望將某個叢集納入推出序列，可以為其加上標籤，讓 GKE 在推出新版本時忽略該叢集。舉例來說，如果您需要更多時間才能升級特定叢集，可能就需要這麼做。您可以忽略推出作業序列中的一或多個叢集。
如果您忽略推出作業序列中的叢集，GKE 在推出新版本時就不會考慮該叢集，也不會對該叢集執行自動升級，但強制自動升級除外，包括支援結束時自動升級，以及針對 90 天內未升級的控制層自動升級。
如要忽略推出作業序列中的叢集，請參閱「忽略推出作業序列中的叢集」。
修改推出作業序列
如要變更現有推出作業序列的推出方式，可以透過下列兩種方式修改序列：
- 如要修改推出序列，請編輯定義序列的 YAML 設定檔。
- 修改序列中的叢集。
修改推出作業序列後，會發生下列情況：
- 如果您在推出序列中新增階段、移除階段、變更階段順序或編輯階段 (例如變更該階段的專案 ID 或標籤選取器)，GKE 會取消所有進行中的推出作業。
- 如果您變更階段的浸泡時間，GKE 不會取消進行中的推出作業。
如要修改推出作業序列，請參閱「修改推出作業序列」。
如果依序修改叢集，會發生下列情況：
- 如果您將叢集從機群中移除，藉此將叢集從推出序列中移除，則進行中的推出作業會繼續執行。GKE 可根據未註冊序列的叢集一般程序，自動升級叢集。
- 如果您在推出作業序列中將叢集新增至機群，GKE 會在尚未通過新增階段的有效推出作業中，升級這個叢集。不過，如果推出作業已完成該階段，GKE 就不會升級該推出作業中的叢集。
如果您將叢集移至其他階段，但未編輯推出序列設定，則會發生下列情況，具體取決於您將叢集移至的階段是否已完成：
- 如果將叢集移至已完成推出作業的階段，GKE 不會在該推出作業中升級叢集。
- 如果您將已在推出作業中升級的叢集移至後續未完成的階段，GKE 會忽略該叢集，且不會中斷推出作業的進度。
如要修改序列中的叢集，請參閱「將 Cloud de Confiance by S3NS 上的叢集註冊至機群」。
限制
使用推出作業排序功能和自訂階段升級叢集時，須遵守下列限制：
- 您無法使用 Cloud de Confiance 控制台建立或修改含有自訂階段的推出序列。不過，您可以使用控制台監控推出作業 (預先發布版)。
- 如果推出作業序列參照機群，您必須納入「整個」機群。這項限制代表，如果您定義的階段只指定機群中具有
label-selector的部分叢集 (例如分階段部署)，則必須定義後續的「catch-all」階段，納入該機群的所有其餘叢集。這個全面涵蓋階段會指定相同的機群，但不包含label-selector，因此會自動納入序列中先前階段未選取的所有叢集。 - 如果您在推出期間修改序列，尤其是會影響參與叢集的變更，GKE 會立即取消所有現有推出作業。如果只修改序列的浸泡時間，GKE 不會取消推出作業。
- 一個階段最多只能參照一個機群。單一階段中不能有多個機群。
- 一個機群只能在一個推出序列中參照。兩個推出序列不得參照同一個機群。
- 如果叢集使用加速修補程式自動升級功能，就無法透過推出作業排序功能升級。
- 您最多可以建立 15 個階段的推出序列。
- 一個機群最多可包含 250 個叢集。如果叢集具有輕量級成員資格，您可以要求提高配額，將機群中的叢集數量增加到最多 2,000 個。詳情請參閱「配額與限制」。
- 您可以為每個序列設定最長 90 天的浸泡時間，涵蓋所有階段。
已知問題
本節概述使用自訂階段推出序列的已知問題。
- 如果推出序列中的某個階段不含任何叢集，系統會略過該階段，但仍會等待該階段定義的浸泡時間結束，再繼續推出下一個階段。