您可以透過推出作業排序功能，管理不同環境中各個 Google Kubernetes Engine (GKE) 叢集的自動升級順序。舉例來說，您可以在升級正式環境叢集之前，先在試產叢集檢驗新版本。如要使用這項功能，您應熟悉叢集升級、發布管道和機群管理。
如要開始，請參閱「依序推出叢集升級作業」。
術語
本文使用「群組」一詞，同時指稱車隊或團隊範圍，因為您可以建立以任一分組方法整理的推出順序。
在各個環境中驗證升級
如要使用推出順序自動升級叢集，請使用機群或團隊範圍，將具有相同發布管道和次要版本的叢集分組，並部署至不同階段。選擇機群順序或團隊範圍順序，並設定每個叢集群組之間的浸泡測試時間。接著，當 GKE 選擇透過發布版本自動升級的新版本時，叢集群組就會按照您定義的順序升級，您可以在升級正式環境叢集之前，先驗證工作負載是否能以新版本正常運作。
以車隊為基礎的推出作業序列
下圖說明 GKE 如何依據按機群排序的推出作業序列，自動升級叢集：
採用機群序列時，如果 GKE 在發布版本中提供新的升級目標，且該序列中的所有叢集都已註冊，GKE 就會升級這些叢集機群。上游機群的叢集會為下游機群的叢集限定新版本，最多可有五個機群。在推出作業序列中，「上游」是指前一個群組，「下游」是指下一個群組。
在車隊之間設定過渡期時，上游車隊升級完成後，下游車隊升級開始前，您可以確認升級後的叢集是否正常執行工作負載。
以團隊為準的推出作業序列
如果您已依團隊或應用程式進一步細分機群中的叢集，可以在團隊範圍之間建立推出順序。團隊範圍是企業機群層級的建構體，可將部分機群叢集與特定應用程式團隊建立關聯，並用於啟用一系列以團隊為基礎的功能，包括存取權控管、團隊範圍的可觀測性，以及推出作業排序。
透過團隊範圍，您可以在機群中建立多個推出作業序列，每個序列都有自己的發布管道、升級目標和獨立的浸潤時間。團隊式推出序列的功能與機群式推出序列相同，但升級作業會在每個機群中特定團隊的叢集之間進行，而不是在機群之間進行。對於想在自家團隊的叢集中管理升級作業的應用程式運算子來說，這項功能特別實用。
GKE 如何依據推出作業序列升級叢集
GKE 升級叢集時，會先升級控制層，再升級節點。在推出作業序列中，叢集仍會使用這個程序升級，但您也可以控管叢集群組 (機群或範圍) 的升級順序，並指定浸泡時間，選擇 GKE 在從一個群組升級到下一個群組前暫停多久。
推出作業序列中的叢集升級作業會依下列步驟進行：
- GKE 會在特定發布版本中，為叢集設定新的子版本自動升級目標，且發布說明會提及類似下列訊息的內容：「啟用一般版自動升級功能的控制層和節點，將透過這個版本從 1.21 版升級至 1.22.15-gke.1000 版。」
- GKE 會開始將第一組叢集的叢集控制層升級至新版本。GKE 升級叢集的控制層後，就會開始升級叢集的節點。在推出作業序列中升級叢集時，GKE 會遵守維護作業可用性。
- GKE 會執行下列控制層升級後續步驟：
- 第一個群組中的所有叢集控制層升級作業完成後，或控制層升級作業開始 30 天後，GKE 就會開始控制層升級過渡期。
- 第一個群組的叢集控制層升級過渡期結束後，GKE 會開始升級第二個群組的控制層。
- 在升級控制層的同時，GKE 會執行下列節點升級的後續步驟：
- 如果第一個群組中的所有叢集節點升級作業都已完成，或節點升級作業開始後已過 30 天，GKE 就會開始節點升級過渡期。
- 如果叢集的控制層已升級，GKE 會在第一組節點升級過渡期結束後，開始升級第二組的節點。
- GKE 會從第二個群組到第三個群組重複執行這些步驟，直到推出順序中的所有群組叢集都升級至新的升級目標為止。
在每個群組的叢集升級期間，請在過渡期內確認工作負載是否能在執行新版 GKE 的叢集上正常運作。
此外，維護時段或排除項目、已淘汰的 API 用法或其他原因，也可能導致叢集無法升級。詳情請參閱「如何搭配其他升級功能使用推出順序」。
如何控管推出作業序列中的升級作業
在更新階段中，叢集升級會按照您定義的順序升級叢集群組，並在每個群組中浸潤您選擇的時間長度。升級作業進行期間，您可以查看推出順序的狀態，並視需要管理推出順序。你也可以透過下列方式控管程序：
- 對於推出順序中的群組，如果特定版本需要更多或更少的浸泡時間，您可以覆寫預設浸泡時間。
- 如要升級個別叢集，可以繼續使用下列工具：
詳情請參閱如何搭配其他升級功能使用推出順序。
示例：社區銀行逐步將變更從測試環境推出至正式環境
舉例來說，社群銀行的平台管理員管理三個主要部署環境，每個環境都是以機群形式組織的叢集群組：測試、預備和正式環境。為符合推出順序規定，管理員已在所有三個機群中，為每個叢集註冊相同的發布管道 (在這些機群中為一般管道)，且所有叢集都執行相同的子版本。
管理員會使用推出作業排序功能，定義 GKE 在這些環境中升級叢集的順序。管理員可藉由排序推出作業，在正式環境升級至新版本前，先驗證工作負載是否能在新版 GKE 叢集上正常運作。以機群為基礎的推出作業順序圖說明瞭這個順序。
管理員會利用這段時間，確認工作負載在 GKE 新版叢集上是否正常運作。對於測試機群，管理員將浸泡時間設為 14 天，以便有整整兩週的時間測試工作負載的執行情況。對於 Staging，他們將浸泡時間設為 7 天，因為工作負載已在測試中執行，因此不需要額外時間。
管理員也可以覆寫特定版本升級的預設浸泡時間，這可能適用於下列情況：
- 管理員在浸泡時間結束前完成版本資格認證，並希望升級程序繼續進行至下一個機群，因此將浸泡時間設為零。
- 管理員發現部分工作負載有問題，因此需要更多時間驗證新版本，才能將升級作業移至下一個機群，因此將過渡期設為最長 30 天。
管理員會使用維護期間和排除時段，確保 GKE 在最不會對銀行造成干擾的時段升級叢集。GKE 會尊重在推出作業序列中升級的叢集維護可用性。
- 管理員已為叢集設定維護時間範圍，確保 GKE 只會在營業時間過後升級叢集。
- 如果管理員發現叢集的工作負載有問題，也可以使用維護排除時段，暫時防止叢集升級。
管理員會為節點混合使用突增升級和藍綠升級，並根據節點上執行的工作負載，在速度和風險容許度之間取得平衡。
管理員切換為以團隊為準的推出作業序列
如果管理員決定要進一步依據應用程式將叢集分組，並讓應用程式團隊管理員更妥善地控管叢集升級作業，可以使用團隊範圍。應用程式團隊管理員可透過團隊範圍，使用指派給團隊的叢集群組建立獨立的推出順序，這些叢集可能在不同的發布管道上執行，或有不同的浸泡時間。
舉例來說，假設資料庫團隊希望叢集使用穩定版管道和較長的浸泡時間，而前端網站團隊的叢集使用快速版管道和較短的浸泡時間，他們可以使用團隊範圍建立個別的推出順序。以團隊為單位的推出順序圖表說明瞭這類順序。如要為環境執行這項操作，請按照這篇文章的指示，在以機群和團隊為準的推出作業序列之間切換。
請注意，使用這項功能需要單一租戶叢集，也就是說，每個叢集只能與一個團隊建立關聯。推出順序不支援共用叢集 (一般車隊團隊管理功能支援共用叢集)。如要進一步瞭解如何管理團隊的叢集，請參閱「機群團隊管理」。
推出資格
如要透過推出作業排序功能自動升級叢集，推出作業序列中所有群組 (機群或範圍) 的所有叢集，都必須採用相同的升級目標。叢集必須在同一個發布管道中註冊，且建議叢集執行相同的子版本，因為升級目標是依子版本設定。不過，對於某些版本 (例如以下範例中的版本)，多個子版本的叢集會收到相同的目標，也就是說，叢集可以在執行多個子版本的推出序列中成功升級。
您可以依序檢查版本推出作業的狀態，進一步瞭解狀態，以及版本資格問題是否導致升級作業無法繼續。視版本差異而定，您可能需要採取手動升級叢集或從群組中移除叢集等動作，才能繼續升級叢集。如果推出作業序列中的叢集沒有符合資格的升級目標，GKE 就不會自動升級叢集，直到叢集的現有子版本終止支援為止。
如要排解推出資格問題，請參閱「排解推出資格問題」。
範例 GKE 版本
舉例來說，2022-R25 版本為註冊「一般」管道的叢集，設定了多個次要版本的升級目標。升級目標可以是新的次要版本 (1.20 至 1.21)，也可以只是新的修補程式版本 (1.21.x-gke.x 至 1.21.14-gke.4300)。在此版本中，我們在一般發布版中，為特定次要版本的叢集提供下列新版本：
- 1.20 和 1.21 版的叢集已升級至 1.21.14-gke.4300。
- 1.22 版的叢集已升級至 1.23.8-gke.1900。
- 1.24 版的叢集已升級至 1.24.5-gke.600。
最上游的群組會收到所有升級目標
對於序列中第一個群組的叢集，由於沒有上游群組可限定新版本，因此無論升級目標是否不同，GKE 都會升級任何具有合格升級目標的叢集。舉例來說，在序列的第一個群組中，如果部分叢集執行的是 1.20 版，這些叢集可以升級至 1.21.14-gke.4300 版，而執行 1.24 版的叢集則可升級至 1.24.5-gke.600 版。這是因為對於序列中的第一個群組，GKE 會將所有升級目標視為符合這些叢集的資格，因為沒有上游群組可限定新版本。
上游群組只能限定一個版本
在任何下游群組中，GKE 是否能升級叢集，取決於上游群組是否符合升級目標的資格，且該群組中的所有叢集都符合資格。通常這表示所有叢集都從同一個子版本開始。不過，從範例版本來看，1.20 和 1.21 版的叢集有相同的升級目標，因此執行這兩個版本的叢集可以在同一個群組中，升級至 1.21.14-gke.4300。
如果一個群組中的所有叢集升級目標不一致，這個群組就無法為下一個群組設定升級目標。在這種情況下，GKE 無法自動升級下游群組中的叢集。舉例來說，如果第一個群組中，部分叢集升級至 1.21.14-gke.4300，其他叢集升級至 1.23.8-gke.1900，則第二個群組的叢集無法自動升級，因為該群組未收到符合資格的版本。如要在此情況下繼續升級，請參閱「修正群組的資格問題」。
上游群組必須限定與下一個群組叢集相符的版本
如果上游群組中的叢集符合的資格與下一個群組中的叢集不同，GKE 也無法自動升級任何下游群組中的叢集。
舉例來說，如果第一個群組中的所有叢集都已升級至 1.21.14-gke.4300，但第二個群組中的叢集執行的是 1.22 版 (升級目標為 1.23.8-gke.1900)，則第二個群組的叢集不會自動升級。第一個群組符合 1.21.14-gke.4300 的資格，但第二個群組中的叢集 (目前為 1.22) 僅符合升級目標 1.23.8-gke.1900 的資格，因此 GKE 無法自動升級這些叢集。如要在這種情況下繼續升級，請參閱「修正群組間的資格問題」。
推出作業排序功能如何與其他升級功能搭配運作
推出順序是其中一項功能，可讓您控管叢集生命週期的升級作業。本節說明這項功能如何與其他可用的叢集升級相關功能搭配運作。
維護期間和排除時段如何影響發布順序
使用推出作業排序功能升級叢集時，GKE 會遵守維護期間和維護作業排除時段。GKE 只會在叢集的維護期間內啟動叢集升級作業。您可以暫時使用維護排除功能，避免叢集升級。如果 GKE 無法在維護期間或排除時間升級叢集，可能會導致群組中的叢集無法完成升級。如果因維護時段或排除項目，導致叢集升級無法在 30 天內完成，無論所有叢集是否已完成升級，群組都會進入浸潤階段。
您可以暫時使用維護排除項目，避免序列完成向群組發布作業，並移至下一個群組。詳情請參閱「延後完成群組版本推出作業」。
淘汰使用情況偵測功能如何搭配推出作業排序功能運作
如果 GKE 偵測到叢集使用特定已淘汰的 API 和功能，就會暫停升級。如果叢集位於推出順序中的群組，自動升級也會暫停。詳情請參閱「Kubernetes 淘汰項目在 GKE 中的運作方式」。
推出作業排序功能如何搭配節點升級策略運作
在推出順序中升級節點時，系統會使用已設定的節點升級策略。與不使用推出作業排序功能的叢集升級作業相同，GKE 會對 Autopilot 節點使用突增升級。詳情請參閱「自動節點升級」。
如果節點升級作業無法在 30 天內完成，無論所有叢集是否已完成升級，群組都會進入浸泡階段。如果節點升級策略導致標準叢集的節點升級作業需要較長時間才能完成 (尤其是大型節點集區)，就可能發生這種情況。如果維護期間不夠長，無法完成節點升級，也可能導致問題更加嚴重。詳情請參閱「設定維護期間時的注意事項」。
如何搭配發布版本使用推出作業排序功能
如要使用推出作業排序功能，必須使用發布版本。推出順序中所有群組的所有叢集，都必須位於同一個發布管道。
在一個序列中收到多項升級
如果叢集升級至先前的升級目標時，發布版本中的新版本成為升級目標，上游群組可以開始推出新版本，而下游群組仍會接收先前的升級。舉例來說，如果序列中的第三個群組正在推出 1.24.2-gke.100，序列中的第一個群組可以同時推出 1.24.3-gke.500。
選擇推出作業排序功能時的注意事項
如要管理叢集升級作業，先在一個環境中驗證新版本，再推出至其他環境，不妨使用推出作業排序功能。
不過，如果符合下列任一條件，這可能就不是適合您環境的選擇：
- 您在同一個正式環境中，有不在相同發布管道或子版本的叢集。
- 您需要自動升級無法對應至五個部署階段的項目，因為您最多只能建立五個叢集群組的推出作業順序。您無法連結多個發布序列中的群組，建立超過五個群組的發布序列。以機群為基礎的序列最多可包含五個機群，以團隊為基礎的序列最多可包含三個團隊範圍。
- 您無法使用車隊管理。
- 您經常執行手動升級，導致某個群組中的叢集自動升級目標版本不同。
如要建立以團隊為準的推出順序，您也必須能夠在機群主機專案中啟用 GKE Enterprise。
限制
如要使用推出作業排序功能順利升級叢集，請務必遵守下列限制：
- 確認推出順序中的所有叢集都已註冊相同的發布版本，並執行相同的子版本。
- 如果您使用以團隊為準的推出作業排序功能，請只在一個團隊範圍內註冊叢集。如果叢集已註冊多個團隊範圍，GKE 無法在以團隊為基礎的推出作業序列中自動升級叢集。
- 不支援在同一車隊中，建立以團隊為準的推出順序，並包含多個團隊範圍。
- 建立不含週期 (群組的下游群組是自己的上游群組) 或分支版本 (群組有多個下游群組) 的線性推出作業序列。
- 在團隊範圍之間建立推出作業序列，或在機群之間建立推出作業序列。 您無法在同一個序列中，建立同時包含車隊和團隊範圍的混合序列。
- 在同一機構的叢集之間建立推出作業序列。您無法使用多個機構的叢集建立序列。
已知問題
- 如果群組包含不同位置的叢集，由於新版本會逐步推出，因此叢集升級功能可能暫時只適用於部分叢集。第一批叢集較有可能發生這種情況，但應該會在 1 週內解決。
- 如果發布序列中有空群組，這會如何影響版本資格，取決於下列條件：
- 如果空白群組沒有上游群組，叢集升級作業就不會繼續進行至下游群組，因為空白群組無法限定版本。
- 如果空白群組有上游群組，所有待處理的叢集升級都會進入
COMPLETE狀態，並傳播至下游群組。
- 由於 GKE 追蹤修補程式和子版本升級的方式，您在檢查範圍狀態時，可能會看到兩個相同類型和版本的升級，但狀態不同。