您可以透過推出作業排序功能，管理不同環境中各個 Google Kubernetes Engine (GKE) 叢集的自動升級順序。舉例來說，您可以在升級正式環境叢集之前，先在試產叢集檢驗新版本。GKE 也提供正式發布版本的推出順序，採用更線性的模型，不含自訂階段。
本文假設您瞭解下列項目：
如要設定推出作業序列，請參閱「依序推出叢集升級作業」。總覽
透過 GKE 推出作業排序功能，您可以為各環境的叢集升級作業定義特定順序，例如先升級開發環境中的叢集，然後是測試環境，最後是正式環境。這項漸進式策略提供內建的烘烤時間，讓您在升級影響最重要的系統前，找出並解決潛在問題。
推出作業排序功能是以機群的概念為基礎建構而成，機群是與環境 (例如測試) 對應的 GKE 叢集邏輯群組。如要使用這項功能，請定義由機群組成的序列，並設定各群組之間的過渡時間。GKE 選取新版本後，叢集會依定義的順序升級，讓您在版本完全部署至正式環境前，先驗證工作負載。
機群支援輕量型成員資格，可讓您有條理地將叢集分組，以便依序推出，不必啟用所有機群層級設定和功能。如果您想使用推出順序，但不想受到完整機群管理的其他影響 (例如機群層級的命名空間相同)，輕量型成員資格就是不錯的選擇。詳情請參閱「輕量型成員資格」。
選擇推出順序策略
GKE 提供兩種推出作業排序功能。這兩個版本都以相同的核心原則為基礎，提供以車隊為單位的漸進式升級，但靈活度不同。本節可協助您判斷哪一個版本最適合您的用途。
以車隊為基礎的推出順序 (正式發布)：這個版本已正式發布，建議用於大多數實際工作環境用途。以機群為基礎的推出作業排序功能，提供穩定且受支援的方法，可逐步在各個環境 (例如測試、預備和正式環境) 中推出升級作業，並使用機群的線性序列。
透過自訂階段推出序號 (搶先體驗版)：這個版本是車隊式模型的進階版，可提供更精細的控制和彈性。使用自訂階段，您可以透過標籤定義機群內的特定階段，因此非常適合用於更複雜的推出策略，例如在全面推出新版本前，先在小部分正式環境叢集上部署新版本。如要享有更多彈性，或想預先體驗最新的推出順序功能，請選擇這個選項。
本文其餘內容僅適用於使用自訂階段的推出順序。
使用自訂階段排序推出作業
使用推出作業排序功能和自訂階段時，您可以定義機群升級順序並設定浸潤時間。此外，您也可以執行下列操作：
- 定義具有精細階段的序列，即可使用標籤指定機群內的特定叢集子集，因此非常適合用於階段性推出等策略。
- 透過新的
RolloutSequence和RolloutAPI 物件，進一步控管及監控。
這個方法可讓您最靈活地精細控管叢集升級作業。如要指定機群內的特定叢集子集，請使用 label-selector，只指定具有特定 Kubernetes 標籤的叢集。
下圖說明 GKE 如何依據使用自訂階段的推出作業序列，自動升級叢集。階段會以 prod 機群中名為 canary 的 label-selector 為目標：
當這個序列中的所有叢集都已註冊的發布管道，有新的升級目標時，GKE 會先升級測試機群中的叢集，再升級預備機群中的叢集。接著，在 Production 機群中，GKE 會優先處理符合 label-selector 的叢集。由於 prod-cluster-1 標示為 canary: true，GKE 會優先升級這個叢集。由於這個階段沒有任何標籤選取器，因此在程序結束時，GKE 會升級 Production 叢集 (位於 Main 階段) 中的所有其餘叢集。
在設定的階段過渡期內，您可以確認工作負載在升級的叢集上正常運作。上述範例顯示 Production 叢集中的一個自訂階段，但您可以為任何叢集新增多個階段，或只使用一個叢集並包含多個階段。
基本概念
- 浸泡時間：這段時間是可設定的等待期，會在階段中的所有叢集升級後發生。這段時間可讓您在一個環境中驗證新版本，並在升級至下一個環境前找出潛在問題。您可以為序列中的每個階段設定最多 30 天的等待時間。在預先發布階段延長浸泡時間，可讓您有更多時間進行驗證。
RolloutSequence：這是您用來定義升級順序的主要資源。RolloutSequence包含一系列依序執行的階段，可確保升級作業進入下一個階段前，前一階段的叢集已完成升級並經過浸泡期。Rollout：這個物件可讓您觀察序列中單一版本升級的進度。您可以使用Rollout查看發布狀態、追蹤進度，以及查看是否有任何叢集不符合升級資格，並瞭解原因。- 專屬主機專案：建議您使用專屬專案來代管
RolloutSequence物件。 Google Cloud將序列放在專案中，可為推出序列提供中立的中央控制點，這與管理 CI/CD 管道的最佳做法類似。
在專屬主機專案中建立及管理 RolloutSequence 資源。
- 階段：階段是推出作業序列中的步驟。每個階段都包含一組叢集，這些叢集會一起升級。
- 機群：機群是叢集的主要分組方式。推出順序中的階段只能參照一個車隊。
- 標籤選取器：推出順序是由一或多個階段組成。每個階段都包含一個機群的叢集，您可以在叢集上使用標籤選取器，將機群進一步分割成多個階段。這個方法可讓您採用階段性推出等策略，先升級一小部分的正式環境叢集。
GKE 如何依據推出作業序列升級叢集
GKE 升級叢集時，會先升級控制層，再升級節點。在推出作業序列中，叢集仍會使用這個程序升級，但您也可以控管叢集群組 (機群) 的升級順序。您也可以指定浸泡時間，定義 GKE 從一個群組升級到下一個群組之前暫停的時間長度。
推出作業序列中的叢集升級作業會依下列步驟進行：
- GKE 會在特定發布版本中，為叢集設定次要版本的新自動升級目標，並發布類似下列訊息的發布說明：「啟用自動升級功能的控制層和節點，將透過這個版本從 1.29 版升級至 1.30.14-gke.1150000 版。」
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 時建立 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 無法在維護期間或排除時段升級叢集，叢集升級作業可能無法在階段內完成。如果維護期間或排除項目導致叢集升級無法在 30 天內完成，無論所有叢集是否已完成升級，階段都會進入浸潤期。控制層和節點集區的推出作業可以在特定階段中平行執行。
節點升級策略：推出順序不會影響您設定的節點升級策略 (例如藍綠升級)。與沒有推出順序的叢集升級類似，GKE 會對 Autopilot 節點使用節點數擴充升級功能。詳情請參閱「自動節點升級」。
如果節點升級作業無法在 30 天內完成，無論所有叢集是否已完成升級，群組都會進入浸泡階段。如果節點升級策略導致 Standard 叢集的節點升級作業需要較長時間才能完成，就可能發生這種情況，尤其是大型節點集區。如果維護期間不夠長，無法完成節點升級，情況可能會更加嚴重。
發布管道：建議您在同一個發布管道中，註冊推出順序中的所有叢集。
淘汰項目使用情況偵測：GKE 的淘汰項目使用情況偵測功能仍可正常運作，可能會暫停使用已淘汰 API 的叢集升級作業。
手動升級：手動升級序列第一階段的叢集，本身不會限定該版本，也不會觸發推出作業繼續進行。自動推出程序會根據發布版本設定的官方自動升級目標進行。手動升級會更新叢集，但只有在該版本成為指定的自動升級目標後，序列才會開始推進。
在整個序列中收到多項升級
發布版本會為叢集選取升級目標。如果升級至先前目標的作業仍在進行中，但有新版本可用，即使後續階段仍會收到先前的升級版本，第一階段仍可開始推出新版本。舉例來說，如果序列中的第三個群組推出 1.31.12-gke.1265000 版，序列中的第一個群組可以同時推出 1.31.13-gke.1008000 版。
選擇推出作業排序功能時的注意事項
如要管理叢集升級作業，先在一個環境中驗證新版本，再推出至其他環境，不妨考慮使用推出作業排序功能。
不過，如果符合下列任一情況，這個策略可能不適合您的環境：
- 您在同一個正式環境中，有發布管道或子版本不同的叢集。
- 您經常執行手動升級，導致某個群組中的叢集自動升級目標版本不同。
限制
使用自訂階段的推出順序升級叢集時，請注意下列限制：
- 您無法使用 Google Cloud 控制台建立或查看含有自訂階段的推出順序。
- 推出作業序列參照機群時，必須包含整個機群。這項限制表示，如果您定義的階段只會以機群中的部分叢集為目標 (例如用於分階段部署)，則也必須定義後續的「全包」階段，納入同一機群中的所有其餘叢集。
label-selector這個適用於所有叢集的階段會以相同機群為目標，但不包含label-selector，因此會自動納入序列中先前階段未選取的所有叢集。 - 如果在推出期間修改序列，尤其是會影響參與叢集的變更，GKE 會立即取消所有現有的推出作業。如果只修改序列的浸泡時間，GKE 不會取消推出作業。
- 您無法手動加快特定版本的推出速度。在推出順序定義中修改浸泡時間後，系統會更新所有現有和日後推出的預設浸泡時間。
- 如果叢集已達支援期限，GKE 會自動將叢集升級至支援的版本，但這項升級作業可能不會按照定義的推出順序進行。
- 一個階段最多只能參照一個車隊。單一階段中無法有多個車隊。
- 單一車隊只能在一個推出順序中參照。兩個推出程序不得參照相同的車隊。
已知問題
本節說明使用自訂階段推出時的已知問題。
- 如果發布序列中的某個階段不含任何叢集，系統會略過該階段，但仍會經過為該階段定義的浸泡時間，才會繼續發布至下一個階段。