在 1.29 以上版本中,Google Distributed Cloud 允許使用者叢集的控制層比叢集中的節點集區高出最多兩個子版本。舉例來說,如果使用者叢集的控制層位於 1.29,叢集中的節點集區可以位於 1.16、1.28 或 1.29 版。此外,升級節點集區時,Google Distributed Cloud 可讓您略過一個子版本。以前述範例為例,您可以將 1.16 版的節點集區直接升級至 1.29 版,略過 1.28 版。升級節點集區時略過子版本,稱為「略過版本升級」。
本頁說明跳過版本升級的優點,並提供相關步驟,說明如何透過變更設定檔及執行 gkectl upgrade cluster
,跳過版本升級。
本頁面適用於負責管理基礎技術架構生命週期的 IT 管理員和作業人員。如要進一步瞭解內容中提及的常見角色和範例工作,請參閱「常見的 GKE Enterprise 使用者角色和工作」。 Google Cloud 本頁面假設您已大致瞭解如何規劃及執行 Google Distributed Cloud 升級,如以下所述:
限制
跳過版本升級有下列限制:
Ubuntu 和 COS 節點集區支援略過版本升級,但 Windows 節點集區不支援。
1.31 版:這項功能不適用於進階叢集。
1.32 以上版本:這項功能適用於進階叢集。
由於 Kubernetes 限制,使用者叢集的控制層一次只能升級一個次要版本。不過請注意,只升級控制層所需的時間較少,風險也比升級工作負載執行的節點集區低。
略過版本升級的好處
本節將說明使用跳過版本升級的優點。
更輕鬆地將叢集維持在支援版本
Google Distributed Cloud 每四個月會發布一個新的子版本,每個子版本有一年的支援期限。如要確保叢集維持在支援期限內,您必須大約每四個月執行一次次要版本升級,如下所示:
12 月 |
1 月 |
2 月 |
3 月 |
4 月 |
5 月 |
6 月 |
7 月 |
8 月 |
9 月 |
10 月 |
11 月 |
12 月 |
1 月 |
2 月 |
3 月 |
4 月 |
5 月 |
6 月 |
7 月 |
8 月 |
9 月 |
10 月 |
11 月 |
12 月 |
1 月 |
2 月 |
3 月 |
1.14 | 升級 | ||||||||||||||||||||||||||
1.15 | 升級 | ||||||||||||||||||||||||||
1.16 | 升級 | ||||||||||||||||||||||||||
1.28 | 升級 | ||||||||||||||||||||||||||
1.29 | 升級 |
如果您需要較長的驗證時間來驗證新的次要版本,但維護時間較短,無法將叢集升級至新的次要版本,這項規定就會造成困難。為克服這些挑戰,您可以採用跳過版本升級的方式,每八個月升級一次叢集,而非每四個月一次,讓叢集維持在支援期限內。下表顯示略過 1.15 版升級後,您只需要在八個月後升級,而不是四個月後。
12 月 |
1 月 |
2 月 |
3 月 |
4 月 |
5 月 |
6 月 |
7 月 |
8 月 |
9 月 |
10 月 |
11 月 |
12 月 |
1 月 |
2 月 |
3 月 |
4 月 |
5 月 |
6 月 |
7 月 |
8 月 |
9 月 |
10 月 |
11 月 |
12 月 |
1 月 |
2 月 |
3 月 |
1.14 | 升級 | ||||||||||||||||||||||||||
1.15 | |||||||||||||||||||||||||||
1.16 | 升級 | ||||||||||||||||||||||||||
1.28 | |||||||||||||||||||||||||||
1.29 |
升級節點集區時,如果跳過一個子版本,就能減少維持在支援版本所需的升級次數。此外,您不需要限定略過的次要版本,因為控制層只會暫時使用該版本。
縮短維護期間
使用跳過版本升級時,您不需要擴大維護時段。升級節點集區時,如果略過次要版本,所需時間與升級至下一個次要版本相同,因為節點集區中的每個節點都會排空並重新建立一次。因此,略過版本升級可節省整體時間,並減少工作負載中斷。
摘要
總而言之,略過版本升級具有下列優點:
將叢集升級至支援的版本:Google Distributed Cloud 支援最新的三個子版本。如果叢集使用不支援的版本,視叢集版本而定,升級節點集區時略過子版本,可讓叢集以較少的升級次數達到支援版本。
節省時間:升級節點集區時,略過子版本與升級至下一個子版本所需的時間相同。因此,跳過版本升級所需的時間,大約是節點集區升級兩次的一半。同樣地,如果採用跳過版本升級,您只有一個驗證視窗,一般升級則有兩個。
減少中斷:升級間隔時間越長,升級和驗證所花的時間越少,工作負載就能運作更久,中斷次數也越少。
在升級期間控管控制層和節點集區版本
在使用者叢集設定檔中,nodePools[i].gkeOnPremVersion 欄位可讓特定節點集區使用與頂層 gkeOnPremVersion 欄位不同的版本。變更 nodePools[i].gkeOnPremVersion
欄位的值,即可在執行 gkectl upgrade cluster
時控制節點集區的升級時間。如果設定檔中未加入 nodePools[i].gkeOnPremVersion
,或將該欄位設為空字串,節點集區就會升級至您在 gkeOnPremVersion
中指定的相同目標版本。
版本規則
升級規則取決於叢集次要版本。
如果是 1.30 以下版本,使用者叢集的子版本必須大於或等於管理員叢集的子版本。修補程式版本無關緊要。舉例來說,如果使用者叢集版本為 1.30.1,管理員叢集可以升級至較高的修補程式版本,例如 1.30.3。
如果是 1.31 以上版本,管理員叢集版本 (包括修補程式版本) 必須大於或等於使用者叢集版本。舉例來說,如果管理員叢集是 1.31.1 版,使用者叢集最高只能升級至 1.31.1 版。
如要將叢集升級至 1.31 版,請先將所有叢集升級至 1.30 版。所有叢集都升級至 1.30 版後,即可將管理員叢集升級至 1.31 版。完成後,即可將使用者叢集升級至與管理員叢集相同的 1.31 修補程式版本。
略過版本升級順序
升級管理員和使用者叢集的順序,取決於您要升級的叢集版本 (即目標版本):
1.32 以上版本
如果目標版本為 1.32 以上,請使用這個序列。假設使用者叢集控制層和所有節點集區都處於子版本 1.N
。使用跳過版本升級功能,將叢集從 1.N
升級至 1.N+2
的大致流程如下:
- 將管理員叢集從
1.N
版升級至中繼版本1.N+1
。 - 將管理員叢集從中繼版本
1.N+1
升級至目標版本1.N+2
。 - 只將使用者叢集控制層從來源版本
1.N
升級至中繼版本1.N+1
。將節點集區保留在來源版本。由於控制層一次只能升級一個子版本,因此需要使用中繼版本。 - 將控制層和節點集區升級至目標版本「
1.N+2
」。
1.31
如果使用者叢集為 1.29 版,請使用這個特殊序列,這表示目標版本為 1.31 版。如果使用者叢集為 1.29 版,管理該叢集的管理員叢集可以是 1.27、1.28 或 1.29 版。
- 如果管理員叢集是 1.27 版,請升級至 1.28 版。
- 如果管理員叢集是 1.28 版,請升級至 1.29 版。
- 只將使用者叢集控制層從來源版本 1.29 升級至中繼版本 1.30。將節點集區保留在來源版本。由於控制層一次只能升級一個子版本,因此需要中繼 1.30 版。
- 將管理員叢集從 1.29 版升級至中繼版本 1.30。
- 將管理員叢集升級至目標版本 1.31。
- 將使用者叢集控制層和節點集區升級至目標版本 1.31。
1.30 以下版本
如果目標版本為 1.30 以下,請使用這個序列。
假設使用者叢集控制層和所有節點集區都處於子版本 1.N
。使用跳過版本升級功能,將叢集從 1.N
升級至 1.N+2
的大致流程如下:
- 只將控制層從來源版本
1.N
升級至中繼版本1.N+1
。將節點集區保留在來源版本。由於控制層一次只能升級一個子版本,因此需要使用中繼版本。 - 將控制層和節點集區升級至目標版本
1.N+2
。
執行跳過版本的升級
本節說明如何執行跳過版本的升級。
事前準備
請確認叢集的目前版本 (來源版本) 為 1.16 以上。請務必檢查控制層 (
gkeOnPremVersion
) 和所有節點集區 (nodePools[i].gkeOnPremVersion
) 的版本。在 1.29 以上版本中,伺服器端預檢預設為啟用。請務必檢查防火牆規則,並視需要進行變更。
如要升級至 1.28 以上版本,您必須啟用
kubernetesmetadata.googleapis.com
,並將kubernetesmetadata.publisher
IAM 角色授予記錄與監控服務帳戶。詳情請參閱「Google API 和 IAM 規定」。
執行升級
1.31
如果使用者叢集為 1.29 版,請使用這個特殊序列,也就是目標版本為 1.31 版。這是因為版本 1.31 的版本規則有所變更,因此需要這個序列。
如果使用者叢集為 1.29 版,管理使用者叢集的管理員叢集可以是 1.27、1.28 或 1.29 版。
如果管理員叢集為 1.27 版,請按照步驟升級管理員工作站,並將管理員叢集升級至 1.28 版。
如要節省管理員工作站的空間,請移除已下載的套件:
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz
管理員叢集和所有使用者叢集都升級至 1.29 版後,即可開始略過版本升級。
在下列預留位置變數中,定義來源版本 (1.29)、中間版本 (1.30) 和目標版本 (1.31)。所有版本都必須是完整版本號碼,格式為
x.y.z-gke.N
,例如1.29.700-gke.110
。版本 取得目前使用者叢集的 1.29 版。這是來源版本。 SOURCE_VERSION
挑選中繼 1.30 版本。 INTERMEDIATE_VERSION
選擇 1.31 目標版本。從 1.31 次要版本中選取建議的修補程式。 TARGET_VERSION
將管理員工作站升級至中繼 1.30 版,
INTERMEDIATE_VERSION
。等待系統顯示升級成功訊息。安裝對應的套裝組合:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
再次升級管理員工作站,但這次請升級至目標 1.31 版,
TARGET_VERSION
。等待系統顯示升級成功訊息。安裝對應的套裝組合:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
只將使用者叢集控制層升級至中繼版本,步驟如下:
在使用者叢集設定檔中進行下列變更:
將
gkeOnPremVersion
欄位設為中間版本INTERMEDIATE_VERSION
。將
nodePools[i].gkeOnPremVersion
中的所有節點集區版本設為來源版本SOURCE_VERSION
。
更新設定檔後,應與下列內容類似:
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
升級控制層:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
將
USER_CLUSTER_CONFIG
替換為使用者叢集設定檔的路徑。
將管理員叢集設定檔中的
bundlePath
欄位設為套件的中繼 1.30 版:bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"
將管理員叢集升級至中繼 1.30 版:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE
將管理員叢集設定檔中的
bundlePath
欄位設為目標 1.31 版套件:bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"
Upgrade the admin cluster to the target 1.31 version:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE
請按照下列步驟,將控制層和節點集區升級至目標版本:
在使用者叢集設定檔中進行下列變更:
將
gkeOnPremVersion
欄位設為目標版本TARGET_VERSION
。將所有
nodePools[i].gkeOnPremVersion
設為空字串。
更新設定檔後,內容應與下列範例類似:
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
升級控制層和節點集區:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
1.30 以下版本
如果目標版本為 1.30 以下,請使用這個序列。
在下列預留位置變數中,定義來源版本 (
1.N
)、中繼版本 (1.N+1
) 和目標版本 (1.N+2
)。所有版本都必須是完整版本號碼,格式為x.y.z-gke.N
,例如1.16.11-gke.25
。版本 取得目前的叢集版本。這是來源版本 ( 1.N
)。SOURCE_VERSION
挑選中間版本 ( 1.N+1
)。INTERMEDIATE_VERSION
挑選目標版本 ( 1.N+2
)。從目標次要版本中選取建議的修補程式。TARGET_VERSION
將管理員工作站升級至中繼版本
INTERMEDIATE_VERSION
。等待系統顯示升級成功訊息。安裝對應的套裝組合:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
將
ADMIN_CLUSTER_KUBECONFIG
替換為管理員叢集kubeconfig
檔案的路徑。再次升級管理員工作站,但這次要升級至目標版本
TARGET_VERSION
。 等待系統顯示升級成功訊息。安裝對應的套裝組合:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
請按照下列步驟,將控制層升級至中繼版本:
在使用者叢集設定檔中進行下列變更:
將
gkeOnPremVersion
欄位設為中間版本INTERMEDIATE_VERSION
。將
nodePools[i].gkeOnPremVersion
中的所有節點集區版本設為來源版本SOURCE_VERSION
。
更新設定檔後,應與下列內容類似:
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
升級控制層:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
將
USER_CLUSTER_CONFIG
替換為使用者叢集設定檔的路徑。
請按照下列步驟,將控制層和節點集區升級至目標版本:
在使用者叢集設定檔中進行下列變更:
將
gkeOnPremVersion
欄位設為目標版本TARGET_VERSION
。將所有
nodePools[i].gkeOnPremVersion
設為空字串。
更新設定檔後,內容應與下列範例類似:
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
升級控制層和節點集區:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
如果沒有其他使用者叢集要升級,請從管理員工作站移除套件組合,以節省空間:
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz