升級 Google Distributed Cloud 時,升級程序會涉及多個步驟和元件。為協助監控升級狀態,或診斷及排解問題,瞭解執行 bmctl upgrade
cluster
指令時會發生什麼情況很有幫助。本文件詳細說明叢集升級的元件和階段。
總覽
升級程序會將 Google Distributed Cloud 叢集從目前版本移至較新版本。
這項版本資訊會儲存在管理員叢集中的叢集自訂資源,位置如下:
status.anthosBareMetalVersion
:定義叢集的目前版本。spec.anthosBareMetalVersion
:定義目標版本,並在升級程序開始執行時設定。
升級作業成功後,系統會調解 status.anthosBareMetalVersion
和 spec.anthosBareMetalVersion
,使兩者都顯示目標版本。
叢集版本偏差
叢集版本差異是指管理叢集 (混合或管理員) 與受管理使用者叢集之間的版本差異。新增或升級使用者叢集時,請遵守下列版本規則:
1.30 以上版本
如果使用者叢集是由 1.30 以上版本的管理員叢集或混合式叢集管理,則適用下列規則:
使用者叢集版本不得高於管理叢集 (管理員或混合式) 版本。
使用者叢集版本最多可比管理叢集版本低兩個次要版本。舉例來說,1.30 版管理員叢集可以管理 1.28 版使用者叢集。這項 n-2 版本偏差管理功能已正式發布,可管理 1.30 版的叢集。
如果管理叢集為 1.30 以上版本,使用者叢集不必使用相同的子版本。舉例來說,1.30 版管理員叢集可以管理 1.30 版、1.29 版和 1.28 版使用者叢集。
多版本管理功能可讓您更彈性地規劃機群升級作業。舉例來說,您不必先將所有 1.28 版使用者叢集升級至 1.29 版,才能將管理員叢集升級至 1.30 版。
1.29
如果使用者叢集是由 1.29 版管理叢集或混合式叢集管理,則適用下列規則:
使用者叢集版本不得高於管理叢集 (管理員或混合式) 版本。
(1.29 搶先版) 使用者叢集版本最多可比管理叢集版本低兩個子版本。舉例來說,1.29 版管理員叢集可以管理 1.16 版使用者叢集。這項 n-2 版本偏差管理功能為預先發布功能,可管理 1.29 版的叢集。
(1.29 Preview) 對於特定管理叢集,使用者叢集不必彼此具有相同的子版本。舉例來說,1.29 版管理員叢集可以管理 1.29 版、1.28 版和 1.16 版使用者叢集。這項混合版本偏差管理功能目前為預先發布功能,適用於管理 1.29 版的叢集。
預先發布版多重 SKU 管理功能可讓您更靈活地規劃車隊升級。舉例來說,您不必先將所有 1.16 版使用者叢集升級至 1.28 版,才能將管理員叢集升級至 1.29 版。
1.28 以下版本
如果使用者叢集是由 1.28 版或更早版本的管理員叢集或混合式叢集管理,則適用下列規則:
使用者叢集版本不得高於管理叢集 (管理員或混合式) 版本。
使用者叢集版本最多可比管理叢集版本低一個子版本。舉例來說,1.28 版的管理員叢集無法管理 1.15 版的使用者叢集。
如果是特定管理叢集,所有代管使用者叢集都必須是相同的子版本。
如要瞭解節點集區的版本偏差規則,請參閱節點集區版本管理規則。
版本規則
下載並安裝新版 bmctl
後,您就可以升級以舊版 bmctl
建立或升級的管理員、混合式、獨立和使用者叢集。叢集無法降級至較低版本。
您只能將叢集升級至與所用 bmctl
版本相符的版本。也就是說,如果您使用 bmctl
1.32.100-gke.106 版,就只能將叢集升級至 1.32.100-gke.106 版。
修補程式版本升級
在特定次要版本中,您可以升級至任何較新的修補程式版本。也就是說,只要 Y
大於 X
,您就可以將 1.32.X
版本叢集升級至 1.32.Y
版本。舉例來說,您可以從 1.31.0
升級至 1.31.100
,也可以從 1.31.100
升級至 1.31.300
。建議您盡可能升級至最新修補程式版本,確保叢集採用最新的安全性修正。
子版本升級
無論修補程式版本為何,您都可以將叢集從一個次要版本升級至下一個次要版本。也就是說,您可以從 1.N.X
升級至 1.N+1.Y
,其中 1.N.X
是叢集版本,而 N+1
是下一個可用的次要版本。在這個案例中,修補程式版本 X
和 Y
不會影響升級邏輯。舉例來說,您可以從 1.31.600-gke.85
升級至 1.32.100-gke.106
。
升級叢集時,無法略過次要版本。如果您嘗試升級至比目前叢集版本高出兩個以上次要版本的次要版本,bmctl
會發出錯誤。舉例來說,您無法在單一步驟中,將 1.30.0
版叢集升級至 1.32.0
版。
如先前所述,管理員叢集可以管理相同或較低版本的使用者叢集。使用者叢集與管理叢集之間的版本差異 (有時稱為版本傾斜) 會因叢集版本而異。將管理叢集升級至新的次要版本前,請確認代管使用者叢集的版本仍符合目標升級版本的叢集版本傾斜規則。
節點集區版本控管規則
選擇性升級節點集區時,適用下列版本規則:
1.30 以上版本
叢集版本必須大於或等於工作站節點集區版本。
工作站節點集區和叢集之間的最大版本差異為兩個次要版本。
工作站節點集區可使用相容次要版本的任何修補程式版本。
1.29
叢集版本必須大於或等於工作站節點集區版本。
(1.29 版正式發布) 工作站節點集區與叢集之間的最大版本偏差為兩個次要版本。
工作站節點集區的版本不得晚於叢集版本。舊版缺少新版所需的完整詳細資料,因此無法相容。
舉例來說,1.16.6 版是在 1.28.100-gke.146 版發布後才推出,因此您無法將叢集從 1.16.6 版升級至 1.28.100-gke.146 版,並將工作站節點集區保留在 1.16.6 版。同樣地,如果將叢集升級至 1.28.100-gke.146 版,但選擇將工作站節點集區保留在 1.16.5 版,則在叢集為 1.28.100-gke.146 版時,無法將工作站節點集區升級至 1.16.6 版。
1.28
叢集版本必須大於或等於工作站節點集區版本。
(1.28 預先發布版) 啟用 n-2 版本差異預先發布版功能後,工作節點集區與叢集間的最大版本差異為兩個次要版本。如未啟用這項功能,工作節點集區和叢集之間的最大版本偏差為一個次要版本。
工作站節點集區的版本不得晚於叢集版本。舊版缺少新版所需的完整詳細資料,因此無法相容。
舉例來說,1.16.6 版是在 1.28.100-gke.146 版發布後才推出,因此您無法將叢集從 1.16.6 版升級至 1.28.100-gke.146 版,並將工作站節點集區保留在 1.16.6 版。同樣地,如果將叢集升級至 1.28.100-gke.146 版,但選擇將工作站節點集區保留在 1.16.5 版,則在叢集為 1.28.100-gke.146 版時,無法將工作站節點集區升級至 1.16.6 版。
1.16
叢集版本必須大於或等於工作站節點集區版本。
工作站節點集區與叢集之間的最大版本差異為一個次要版本。
工作站節點集區的版本不得晚於叢集版本。舊版沒有新版的完整詳細資料,而這是相容性規定。
舉例來說,1.16.6 版是在 1.28.100-gke.146 版發布後才推出,因此您無法將叢集從 1.16.6 版升級至 1.28.100-gke.146 版,並將工作站節點集區保留在 1.16.6 版。同樣地,如果將叢集升級至 1.28.100-gke.146 版,但選擇將工作站節點集區保留在 1.16.5 版,則在叢集為 1.28.100-gke.146 版時,無法將工作站節點集區升級至 1.16.6 版。
下表列出特定叢集版本允許使用的支援節點集區版本:
1.30 以上版本
如果是 1.30 以上版本的叢集,節點集區版本最多可低兩個次要版本。相容次要版本中的所有節點集區修補程式版本都相容。
1.29
叢集 (控制層) 版本 | 支援的工作站節點集區版本 (新增版本以粗體標示) | |||
---|---|---|---|---|
1.29.1200-gke.98 |
|
|
|
|
1.29.1100-gke.84 |
|
|
|
|
1.29.1000-gke.93 |
|
|
|
|
1.29.900-gke.180 |
|
|
|
|
1.29.800-gke.111 |
|
|
|
|
1.29.700-gke.113 |
|
|
|
|
1.29.600-gke.105 |
|
|
|
|
1.29.500-gke.162 |
|
|
|
|
1.29.400-gke.86 |
|
|
|
|
1.29.300-gke.185 |
|
|
|
|
1.29.200-gke.243 |
|
|
|
|
1.29.100-gke.251 |
|
|
|
|
1.29.0-gke.1449 |
|
|
|
1.28
叢集 (控制層) 版本 | 支援的工作站節點集區版本 (新增版本以粗體標示) | |||
---|---|---|---|---|
1.28.1400-gke.79 |
|
|
|
|
1.28.1300-gke.59 |
|
|
|
|
1.28.1200-gke.83 |
|
|
|
|
1.28.1100-gke.94 |
|
|
|
|
1.28.1000-gke.60 |
|
|
|
|
1.28.900-gke.112 |
|
|
|
|
1.28.800-gke.111 |
|
|
|
|
1.28.700-gke.150 |
|
|
|
|
1.28.600-gke.163 |
|
|
|
|
1.28.500-gke.120 |
|
|
|
|
1.28.400-gke.77 |
|
|
|
|
1.28.300-gke.131 |
|
|
|
|
1.28.200-gke.118 |
|
|
|
|
1.28.100-gke.146 |
|
|
|
|
1.28.0-gke.425 |
|
|
|
|
1.16
叢集 (控制層) 版本 | 支援的工作站節點集區版本 (新增版本以粗體標示) | |||
---|---|---|---|---|
1.16.12 |
|
|
|
|
1.16.11 |
|
|
|
|
1.16.10 |
|
|
|
|
1.16.9 |
|
|
|
|
1.16.8 |
|
|
|
|
1.16.7 |
|
|
|
|
1.16.6 |
|
|
|
|
1.16.5 |
|
|
|
|
1.16.4 |
|
|
|
|
1.16.3 |
|
|
|
|
1.16.2 |
|
|
|
|
1.16.1 |
|
|
||
1.16.0 |
|
|
升級元件
節點和叢集層級的元件都會升級。在叢集層級,升級的元件如下:
- 叢集元件,用於網路、觀測和儲存空間。
- 管理員、混合式和獨立叢集的生命週期控制器。
gke-connect-agent
。
叢集中的節點會以其中一個角色執行,且不同節點角色升級的元件也不同:
節點的角色 | 函式 | 要升級的元件 |
---|---|---|
工作站 | 執行使用者工作負載 | Kubelet、容器執行階段 (Docker 或 containerd) |
控制層 | 執行 Kubernetes 控制平面、叢集生命週期控制器,以及 Google Kubernetes Engine (GKE) Enterprise 版平台外掛程式 | Kubernetes 控制平面靜態 Pod (kubeapi-server 、kube-scheduler 、kube-controller-manager 、etcd)
生命週期控制器,例如 lifecycle-controllers-manager 和
anthos-cluster-operator Google Kubernetes Engine (GKE) Enterprise 版平台外掛程式,例如 stackdriver-log-aggregator 和
gke-connect-agent |
控制層負載平衡器 | 執行 HAProxy 和 Keepalived,將流量提供給 kube-apiserver ,並執行 MetalLB 揚聲器來宣告虛擬 IP 位址 |
控制層負載平衡器靜態 Pod (HAProxy、Keepalived)
MetalLB speakers |
預期停機時間
下表詳細列出升級叢集時的預期停機時間和潛在影響。這個表格假設您有多個叢集節點和高可用性控制層。如果您執行獨立叢集或沒有 HA 控制平面,預計會發生額外的停機時間。除非另有註明,否則這段停機時間適用於管理員和使用者叢集升級:
元件 | 停機時間預期 | 停機時間 |
---|---|---|
Kubernetes 控制層 API 伺服器 (kube-apiserver )、etcd 和排程器 |
無停機時間 | 不適用 |
生命週期控制器和 ansible-runner 工作 (僅限管理員叢集) |
無停機時間 | 不適用 |
Kubernetes 控制層 loadbalancer-haproxy 和
keepalived |
負載平衡器重新導向流量時,會發生暫時性停機 (不到 1 到 2 分鐘)。 | 升級程序開始。 |
觀測能力 pipeline-stackdriver 和
metrics-server |
作業員已排空並升級。停機時間應少於 5 分鐘。
DaemonSet 會繼續運作,不會停機。 |
控制層節點升級完畢後。 |
容器網路介面 (CNI) | 現有網路路徑不會停機。 DaemonSet 部署作業會以兩兩一組的方式進行,不會造成停機。 運算子已清空並升級。停機時間少於 5 分鐘。 |
控制層節點升級完畢後。 |
MetalLB (僅限使用者叢集) | 作業員已排空並升級。停機時間不到 5 分鐘。
現有服務不會停機 |
控制層節點升級完畢後。 |
CoreDNS 和 DNS 自動配置器 (僅限使用者叢集) | CoreDNS 具有多個副本,並採用自動調度資源功能。通常不會有停機時間。 | 控制層節點升級完畢後。 |
本機磁碟區佈建工具 | 現有佈建的永久磁碟區 (PV) 不會停機。
作業人員可能會停機 5 分鐘。 |
控制層節點升級完畢後。 |
Istio / ingress | Istio 運算子已排空並升級。約 5 分鐘的停機時間。 現有設定的 Ingress 仍可繼續運作。 |
控制層節點升級完畢後。 |
其他系統營運者 | 電量耗盡並升級時,停機時間為 5 分鐘。 | 控制層節點升級完畢後。 |
使用者工作負載 | 取決於設定,例如是否為高可用性。 查看自己的工作負載部署作業,瞭解潛在影響。 |
升級工作站節點時。 |
使用者叢集升級詳細資料
本節詳細說明元件升級順序,以及使用者叢集升級的狀態資訊。下一節將詳細說明管理員、混合或獨立叢集升級的流程差異。
下圖顯示使用者叢集升級的預檢程序:
上圖詳細說明升級期間的步驟:
bmctl upgrade cluster
指令會建立PreflightCheck
自訂資源。- 這項預檢會執行額外檢查,例如叢集升級檢查、網路健康狀態檢查和節點健康狀態檢查。
- 這些額外檢查的結果會合併,以報告叢集是否能順利升級至目標版本。
如果通過飛行前檢查,且沒有任何阻礙問題,叢集中的元件就會按照指定順序升級,如下圖所示:
在上圖中,元件的升級順序如下:
- 升級程序會先更新
spec.anthosBareMetalVersion
欄位。 - 控制層負載平衡器已升級。
- 控制層節點集區已升級。
- 同時升級 GKE Connect、叢集外掛程式和負載平衡器節點集區。
- 負載平衡器節點集區升級完成後,系統會升級工作站節點集區。
所有元件升級完成後,系統會執行叢集健康狀態檢查。
健康狀態檢查會持續執行,直到所有檢查都通過為止。
所有健康狀態檢查通過後,升級作業即完成。
每個元件在叢集自訂資源中都有自己的狀態欄位。您可以查看這些欄位的狀態,瞭解升級進度:
順序 | 欄位名稱 | 意義 |
---|---|---|
1 | status.controlPlaneNodepoolStatus |
狀態會從控制層節點集區狀態複製。這個欄位包含控制層節點集區的節點版本 |
2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
套用至叢集的 lifecycles-controllers-manager 版本。這個欄位僅適用於管理員、獨立或混合叢集。 |
2 | status.anthosBareMetalManifestsVersion |
上次套用資訊清單時的叢集版本。 |
2 | status.controlPlaneLoadBalancerNodepoolStatus |
狀態是從控制層負載平衡器節點集區狀態複製而來。如果 Cluster.Spec 中未指定獨立的控制層負載平衡器,這個欄位就會留空。 |
3 | status.anthosBareMetalVersions |
版本對節點數量的匯總版本對應。 |
4 | status.anthosBareMetalVersion |
升級版本的最終狀態。 |
管理員、混合式和獨立叢集升級詳細資料
從 bmctl
1.15.0 版開始,自行管理的叢集 (管理員、混合或獨立) 預設會就地升級。也就是說,將叢集升級至 1.15.0 以上版本時,升級程序會使用生命週期控制器,而非啟動程序叢集,管理整個升級程序。這項異動可簡化程序並減少資源需求,讓叢集升級更可靠且可擴充。
雖然不建議使用啟動程序叢集進行升級,但您仍可選擇這麼做。如要在升級時使用啟動程序叢集,請執行 bmctl upgrade
指令並加上 --use-bootstrap=true
旗標。升級階段會因使用的方法而異。
直接升級
自助式管理叢集的預設就地升級程序,與使用者叢集升級程序類似。不過,當您使用就地升級程序時,系統會先部署新版 preflightcheck-operator
,再執行叢集預檢和健康狀態檢查:
與升級使用者叢集一樣,升級程序會先將 Cluster.spec.anthosBareMetalVersion
欄位更新為目標版本。如以下圖表所示,更新元件前會先執行兩個額外步驟:lifecycle-controller-manager
會自行升級至目標版本,然後部署目標版本的 anthos-cluster-operator
。這個指令會執行升級程序的其餘步驟:
anthos-cluster-operator
成功後,anthos-cluster-operator
會將目標版本從 spec.anthosBareMetalVersion
調解為 status.anthosBareMetalVersion
。
使用啟動程序叢集升級
升級管理員、混合或獨立叢集的程序,與上一節討論的使用者叢集類似。
主要差異在於 bmctl upgrade cluster
指令會啟動程序,建立啟動叢集。這個啟動叢集是臨時叢集,可在升級期間管理混合、管理員或獨立叢集。
將叢集管理擁有權轉移至啟動叢集的程序稱為「樞紐」。其餘升級程序與使用者叢集升級相同。
升級程序期間,目標叢集中的資源會維持過時狀態。 升級進度只會反映在啟動叢集的資源中。
如有需要,您可以存取啟動程序叢集,監控及偵錯升級程序。您可以透過 bmctl-workspace/.kindkubeconfig
存取啟動程序叢集。
升級完成後,如要將叢集的管理擁有權轉移回來,叢集會將資源從啟動程序叢集轉移至升級後的叢集。在升級過程中,您不需要執行任何手動步驟來調整叢集。叢集升級成功後,系統會刪除啟動叢集。
節點排空
升級 Google Distributed Cloud 叢集時,節點會排空,因此應用程式可能會中斷。這個排空程序會導致節點上執行的所有 Pod 關閉,並在叢集中的其餘節點上重新啟動。
部署作業可用於容許這類中斷。Deployment 可指定要執行的應用程式或服務副本數量。如果應用程式有多個副本,升級期間應該不會發生中斷情況,或只會短暫中斷。
PodDisruptionBudgets
(PDB)
升級叢集時,Google Distributed Cloud 會使用維護模式流程排空節點。
自 1.29 版起,節點會透過 Eviction API 排空,該 API 會遵守 PodDisruptionBudgets
(PDB)。在正常運作條件下,PDB 可確保叢集中一律會執行定義數量的副本。當工作負載的 Pod 需要重新排程時,您可以透過 PDB 限制工作負載的中斷次數。以節點排空為基礎的節點排空功能已在 1.29 版中正式推出。
在 1.28 版和更早版本中,節點在升級期間排空時,Google Distributed Cloud 不會遵守 PDB。節點排空程序會盡量執行,部分 Pod 可能會卡在 Terminating
狀態,拒絕騰空節點。如果節點上的排空程序超過 20 分鐘,即使 Pod 停滯,升級作業仍會繼續進行。
詳情請參閱「將節點設為維護模式」。