總覽
Google Distributed Cloud 以 Kubernetes 和許多其他相關技術為基礎,並持續更新和改良,以提供更優異的擴充性、效能、安全性和整合功能。因此,Google Distributed Cloud 會不斷調整和改進。
在 1.30 版中,變更和更新已達到一個階段,我們強烈建議您遷移舊版部署作業,以充分利用重大改善項目。本頁說明從過時功能遷移至最新建議功能的優點。
每個功能領域都有下列選項:
特色區域 | 建議選項 | 原始選項 |
---|---|---|
容器網路介面 (CNI) |
|
|
負載平衡器 |
|
|
管理員叢集控制層 |
|
|
使用者叢集控制層 |
|
|
1 整合式 F5 BIG-IP 是指叢集設定檔中 loadBalancer.f5BigIP
區段的 loadBalancer.kind: "F5BigIP"
和相關設定。
下表列出管理員和使用者叢集中這些功能的支援矩陣:
叢集類型 | 過時功能 | 新增至新叢集 | 允許叢集升級 | 遷移至新功能 |
---|---|---|---|---|
1.30 以上版本 | ||||
管理員 | non-HA | 否 | 是 | 是 |
Seesaw | 否 | 是 | 是 | |
整合式 F5 Big IP | 否 | 是 | 是 | |
使用者 | Kubeception | 否 | 是 | 是 |
Seesaw | 否 | 是 | 是 | |
整合式 F5 Big IP | 否 | 是 | 是 | |
Dataplane V1 | 否 | 是 | 是 | |
1.29 版 | ||||
管理員 | non-HA | 否 | 是 | 是 (預覽版) |
Seesaw | 否 | 是 | 是 | |
整合式 F5 Big IP | 是 | 是 | 是 (預覽版) | |
使用者 | Kubeception | 是 | 是 | 是 (預覽版) |
Seesaw | 是 | 是 | 是 | |
整合式 F5 Big IP | 是 | 是 | 是 (預覽版) | |
Dataplane V1 | 是 | 是 | 否 | |
1.28 版 | ||||
管理員 | non-HA | 否 | 是 | 否 |
Seesaw | 否 | 是 | 是 | |
整合式 F5 Big IP | 是 | 是 | 否 | |
使用者 | Kubeception | 是 | 是 | 否 |
Seesaw | 是 | 是 | 是 | |
整合式 F5 Big IP | 是 | 是 | 否 | |
Dataplane V1 | 是 | 是 | 否 |
重點:
- 從 1.30 版開始,所有遷移解決方案都可將叢集遷移至建議的替代方案。
建立新叢集時,下列版本不允許使用原始功能:
管理員叢集:
- 非高可用性控制層:1.28 以上版本
- Seesaw 負載平衡:1.28 以上版本
- 整合式 F5 Big IP:1.30 以上版本
使用者叢集:
- Kubeception:1.30 以上版本
- Seesaw:1.30 以上版本
- 整合式 F5 Big IP:1.30 以上版本
- Dataplane V1:1.30 以上版本
您仍可使用原始功能升級現有叢集。
將使用者叢集遷移至 Dataplane V2
您可以選擇提供容器網路功能的容器網路介面 (CNI),包括 Calico 或 Dataplane V2。Dataplane V2 是 Google 的 CNI 實作項目,以 Cilium 為基礎,適用於 Google Kubernetes Engine (GKE) 和 Google Distributed Cloud。
Dataplane V2 採用最佳化設計,可有效運用資源,進而提升網路效能及擴充性,特別適合大型叢集或網路流量需求高的環境。強烈建議您將叢集遷移至 Dataplane V2,以使用最新功能、網路創新技術和功能。
從 1.30 版開始,Dataplane V2 是建立新叢集的唯一 CNI 選項。
從 Calico 轉換至 Dataplane V2 需要規劃和協調,但設計上不會造成現有工作負載停機。主動遷移至 Dataplane V2,即可享有下列優點:
提升效能和擴充性:Dataplane V2 的最佳化設計和有效率的資源用量,可提升網路效能和擴充性,尤其是在大型叢集或網路流量需求高的環境中。這是因為叢集使用 EBPF 而非 IPTables,因此可透過 BPF 對應進行擴充。
簡化管理和支援:在 Google Distributed Cloud 和 GKE 中採用 Dataplane V2 標準,可簡化叢集管理和疑難排解作業,因為您可以使用一致的工具和文件集。
進階網路功能: 只有 Dataplane V2 支援 EgressNAT 和其他進階網路功能。 日後所有網路要求都會在 Dataplane V2 層實作。
遷移之前 | 遷移之後 | |
---|---|---|
kube-proxy | 必要且會自動部署 | 未部署且非必要 |
轉送 | kube-proxy + iptables | eBPF |
遷移負載平衡器類型
建議的負載平衡器類型 (loadBalancer.kind
) 為 "ManualLB"
和 "MetalLB"
。如果您使用第三方負載平衡器 (例如 F5 BIG-IP 或 Citrix),請使用 "ManualLB"
。使用 "MetalLB"
進行套裝組合負載平衡,解決方案是使用 MetalLB 負載平衡器。
從 1.30 版開始,這些是建立新叢集的唯一選項。對於使用整合式 F5 Big IP 或套裝組合 Seesaw 負載平衡器的現有叢集,我們提供遷移指南,協助您將 "F5BigIP"
設定遷移至 "ManualLB"
,並將套裝組合負載平衡器從 Seesaw 遷移至 MetalLB。
遷移 F5 BIG-IP 負載平衡器的設定
請規劃將使用整合式 F5 Big IP 的叢集遷移至 ManualLB
。整合式 F5 Big IP 使用 F5 BIG-IP 和負載平衡器代理程式,包含下列兩個控制器:
- F5 控制器 (
pod prefix: load-balancer-f5
):將 LoadBalancer 類型的 Kubernetes 服務協調為 F5 Common Controller Core Library (CCCL) ConfigMap 格式。 - F5 BIG-IP CIS 控制器 v1.14 (
pod prefix: k8s-bigip-ctlr-deployment
): 將 ConfigMap 轉換為 F5 負載平衡器設定。
原始整合式 F5 Big IP 有下列限制:
- 表達能力有限:整合 F5 Big IP 後,Service API 的表達能力會受到限制,導致 F5 BIG-IP 的完整潛力無法發揮。這可能會導致您無法根據特定需求設定 BIG-IP 控制器,或運用對應用程式至關重要的進階 F5 功能。
- 舊版元件:目前的實作方式採用較舊的技術,例如 CCCL ConfigMap API 和 1.x CIS。這些舊版元件可能與 F5 最新產品的進展不相容,導致您錯失提升效能和強化安全性的機會。
從整合式 F5 BIG-IP 遷移至 ManualLB
後,變更包括:
遷移之前 | 遷移之後 | |
---|---|---|
F5 代理程式元件 |
|
|
升級 F5 元件版本 | 您必須先升級叢集,才能升級 F5 元件。如先前所述,可用的元件版本有限。 | 您可以視需要升級 F5 元件版本。 |
建立服務 | 由 F5 服務專員處理 | 由 F5 服務專員處理 (無變更) |
從 Seesaw 遷移至 MetalLB
與 Seesaw 相比,MetalLB 具有下列優點:
- 簡化管理作業並減少資源:與 Seesaw 不同,MetalLB 會直接在叢集節點上執行,因此可動態使用叢集資源進行負載平衡。
- 自動指派 IP:MetalLB 控制器會管理 Service 的 IP 位址,因此您不必為每個 Service 手動選擇 IP 位址。
- 在 LB 節點之間分配負載:不同服務的 MetalLB 現用執行個體可以在不同節點上執行。
- 強化功能並確保未來相容性:MetalLB 積極開發中,並與更廣泛的 Kubernetes 生態系統整合,因此與 Seesaw 相比,是更具未來性的解決方案。使用 MetalLB 可確保您能充分運用負載平衡技術的最新進展。
遷移之前 | 遷移之後 | |
---|---|---|
LB 節點 | 額外的 Seesaw VM (叢集外部) | 由客戶選擇的叢集內 LB 節點 |
保留用戶端 IP | 可透過 externalTrafficPolicy: Local 達成 |
可透過 DataplaneV2 DSR 模式達成 |
建立服務 | 手動指定的 Service IP | 從位址集區自動指派 Service IP |
將使用者叢集遷移至 Controlplane V2,並將管理員叢集遷移至 HA
建議使用者叢集使用 Controlplane V2 控制層。啟用 Controlplane V2 後,控制層會在使用者叢集的一或多個節點上執行。使用舊版控制層 (稱為「kubeception」) 時,使用者叢集的控制層會在管理員叢集中執行。如要建立高可用性 (HA) 管理員叢集,使用者叢集必須啟用 Controlplane V2。
從 1.30 版開始,新使用者叢集必須啟用 Controlplane V2,新管理員叢集則會採用 HA。系統仍支援升級具有舊版控制層的使用者叢集,以及升級非高可用性管理叢集。
將使用者叢集遷移至 Controlplane V2
過去,使用者叢集會使用 kubeception。1.13 版推出 Controlplane V2 預先發布版功能,並在 1.14 版正式發布。自 1.15 版起,Controlplane V2 已成為建立使用者叢集的預設選項,且在 1.30 版中是唯一選項。
相較於 kubeception,Controlplane V2 的優點包括:
- 架構一致性:管理員叢集和使用者叢集使用相同的架構。
- 故障隔離:管理員叢集發生故障時,不會影響使用者叢集。
- 運作分離:管理員叢集升級不會導致使用者叢集停機。
- 部署項目分離:您可以將管理員和使用者叢集放在不同的拓撲網域或多個位置。舉例來說,在邊緣運算部署模型中,使用者叢集可能與管理員叢集位於不同位置。
在遷移期間,現有使用者叢集工作負載不會有任何停機時間。視基礎 vSphere 環境而定,控制層在切換至 Controlplane V2 時,停機時間會縮到最短。遷移程序會執行下列作業:
- 在使用者叢集中建立新的控制層。
- 從舊版控制平面複製 etcd 資料。
- 將現有節點集區節點 (也稱為工作站節點) 遷移至新的控制層。
遷移之前 | 遷移之後 | |
---|---|---|
控制層 Kubernetes 節點物件 | 管理員叢集節點 | 使用者叢集節點 |
Kubernetes 控制層 Pod | 管理員叢集 Statefulset/Deployment (使用者叢集命名空間) | 使用者叢集靜態 Pod (kube-system 命名空間) |
其他控制層 Pod | 管理員叢集 Statefulset/Deployment (使用者叢集命名空間) | 使用者叢集 Statefulset/Deployment (kube-system 命名空間) |
控制層 VIP | 管理員叢集負載平衡器服務 | keepalived + haproxy (使用者叢集靜態 Pod) |
Etcd 資料 | 管理員叢集永久磁碟區 | 資料磁碟 |
控制層機器 IP 管理 | IPAM 或 DHCP | IPAM |
控制層網路 | 管理員叢集 VLAN | 使用者叢集 VLAN |
遷移至高可用性管理員叢集
過去,管理員叢集只能執行單一控制層節點,因此存在單一故障點的固有風險。除了控制層節點,非 HA 管理員叢集也有兩個外掛程式節點。高可用性管理員叢集有三個控制層節點,沒有任何附加節點,因此新管理員叢集所需的 VM 數量並未改變,但可用性大幅提升。自 1.16 版起,您可以使用高可用性 (HA) 管理員叢集,而 1.28 版的新叢集只能使用這項功能。
遷移至高可用性管理員叢集有下列優點:
- 提升穩定性和正常運作時間:高可用性設定可避免單點故障,即使其中一個控制層節點發生問題,管理員叢集仍可正常運作。
- 升級和更新體驗更完善:升級及更新管理員叢集的所有必要步驟,現在都會在叢集內執行,而非在個別的管理員工作站執行。即使管理員工作站的初始工作階段可能中斷,這項設定也能確保升級和更新作業持續進行。
- 叢集狀態的可靠真值來源:非高可用性管理員叢集會依賴頻外「檢查點檔案」儲存管理員叢集狀態。相較之下,高可用性管理員叢集會在管理員叢集本身儲存最新的叢集狀態,為叢集狀態提供更可靠的真實來源。
您可以選擇將非高可用性管理員叢集遷移至高可用性管理員叢集,使用者工作負載不會因此停機。這個程序造成的停機時間和現有使用者叢集的中斷情形極少,主要與控制層切換相關。遷移程序會執行下列操作:
- 建立新的高可用性控制平面。
- 從現有的非高可用性叢集還原 etcd 資料。
- 將使用者叢集轉換至新的 HA 管理員叢集。
遷移之前 | 遷移之後 | |
---|---|---|
控制層節點備用資源數量 | 1 | 3 |
加購節點 | 2 | 0 |
資料磁碟大小 | 100GB * 1 | 25GB * 3 |
資料磁碟路徑 | 由管理員叢集設定檔中的 vCenter.dataDisk 設定 | 目錄下自動產生:
/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk |
控制層 VIP | 由管理員叢集設定檔中的 loadBalancer.kind 設定 | keepalived + haproxy |
管理員叢集控制層節點的 IP 位址分配 | DHCP 或靜態,視 network.ipMode.type 而定 | 3 個靜態 IP 位址 |
群組負載平衡器和控制層遷移作業
一般而言,更新叢集時,建議一次只更新一項功能或設定。不過,在 1.30 以上版本中,您可以將負載平衡器和控制層的設定變更分組,然後更新叢集一次,即可完成兩項變更。
如果使用者叢集使用舊版 CNI,請先遷移至 DataPlane V2。之後,您就可以將負載平衡器和控制層的遷移作業分組。分組遷移有以下好處:
- 簡化程序:如果您需要遷移控制層和負載平衡器,通常只要更新叢集一次即可。您也不必決定要先遷移哪些功能。
- 減少整體停機時間:部分遷移作業會導致控制層停機,因此將這些遷移作業分組為單一更新作業,與依序個別更新相比,可減少整體停機時間。
程序會因叢集設定而異。總而言之,請按照下列步驟,為每個叢集執行遷移作業:
將每個使用者叢集遷移至建議使用的 CNI Dataplane V2。
進行設定變更並更新使用者叢集,觸發使用者叢集從舊版 CNI (Calico) 遷移至 Dataplane V2。
將每個使用者叢集從舊版負載平衡器 (LB) 和舊版控制層 (CP) 遷移至建議的負載平衡器和 Controlplane V2。
- 變更設定,使用建議的負載平衡器 (
MetalLB
或ManualLB
)。 - 變更設定以啟用 Controlplane V2。
- 更新使用者叢集,遷移負載平衡器和控制層。
- 變更設定,使用建議的負載平衡器 (
將管理員叢集遷移至建議的負載平衡器,並確保控制層具備高可用性。
- 變更設定,使用建議的負載平衡器 (
MetalLB
或ManualLB
)。 - 進行設定變更,將管理員叢集的控制層從非高可用性遷移至高可用性。
- 更新管理員叢集,遷移負載平衡器和控制層。
- 變更設定,使用建議的負載平衡器 (
執行選用的清除步驟,例如清除非高可用性控制層 VM。
下圖說明遷移步驟:
如果管理員叢集和所有使用者叢集都採用 1.30 以上版本,即可使用群組遷移程序。如需詳細步驟,請參閱下列指南: