總覽
Google Distributed Cloud 以 Kubernetes 和許多其他相關技術為基礎,這些技術會持續更新及改良,提供更優異的擴充性、效能、安全性和整合功能。因此,Google Distributed Cloud 會不斷調整及改善。
在 1.30 版中,變更和更新已達到一定程度,因此我們強烈建議您遷移舊版部署項目,以充分利用重大改善。本頁面說明從過時功能遷移至最新建議功能的好處。
每個功能區都有下列選項:
| 功能區域 | 建議選項 | 原始選項 |
|---|---|---|
| 容器網路介面 (CNI) |
|
|
| 負載平衡器 |
|
|
| 管理員叢集控制層 |
|
|
| 使用者叢集控制層 |
|
|
1 整合式 F5 BIG-IP 是指叢集設定檔中 loadBalancer.f5BigIP 區段的 loadBalancer.kind: "F5BigIP" 和相關設定。
下表列出管理員和使用者叢集中這些功能的支援矩陣:
| 叢集類型 | 過時功能 | 新增叢集 | 允許叢集升級 | 遷移至新功能 |
|---|---|---|---|---|
| 1.32 以上版本 | ||||
| 管理員 | 非高可用性 | 否 | 否 | 不適用 |
| Seesaw | 否 | 否 | 不適用 | |
| 整合式 F5 BIG-IP | 否 | 否 | 不適用 | |
| 使用者 | Kubeception | 否 | 否 | 不適用 |
| Seesaw | 否 | 否 | 不適用 | |
| 整合式 F5 BIG-IP | 否 | 否 | 不適用 | |
| Dataplane V1 | 否 | 否 | 不適用 | |
| 1.30 和 1.31 版 | ||||
| 管理員 | 非高可用性 | 否 | 是 | 是 |
| Seesaw | 否 | 是 | 是 | |
| 整合式 F5 BIG-IP | 否 | 是 | 是 | |
| 使用者 | Kubeception | 否 | 是 | 是 |
| Seesaw | 否 | 是 | 是 | |
| 整合式 F5 BIG-IP | 否 | 是 | 是 | |
| Dataplane V1 | 否 | 是 | 是 | |
| 1.29 版 | ||||
| 管理員 | 非高可用性 | 否 | 是 | 是 (預先發布版) |
| Seesaw | 否 | 是 | 是 | |
| 整合式 F5 BIG-IP | 是 | 是 | 是 (預先發布版) | |
| 使用者 | Kubeception | 是 | 是 | 是 (預先發布版) |
| Seesaw | 是 | 是 | 是 | |
| 整合式 F5 BIG-IP | 是 | 是 | 是 (預先發布版) | |
| Dataplane V1 | 是 | 是 | 否 | |
| 1.28 版 | ||||
| 管理員 | 非高可用性 | 否 | 是 | 否 |
| 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,可簡化叢集管理和疑難排解作業,因為您可以使用一組一致的工具和說明文件。
進階網路功能:EgressNAT 和其他進階網路功能僅支援 Dataplane V2。日後所有網路要求都會在 Dataplane V2 層中實作。
| 遷移之前 | 遷移之後 | |
|---|---|---|
| kube-proxy | 必要且自動部署 | 非必要且未部署 |
| 轉送 | kube-proxy + iptables | eBPF |
確認從 Calico 遷移至 Dataplane V2 的作業已完成,且不需要復原至 Calico 後,請從 OnPremUserCluster 自訂資源和 OnPremAdminCluster 自訂資源 (如果管理員叢集是在從 1.29 版升級至 1.30 版期間從 Calico 遷移) 中移除 features.onprem.cluster.gke.io/dpv2-migration 註解。在調度資源或升級叢集前移除這個註解,叢集控制器就能永久刪除休眠的 calico-node 和 calico-route-daemon DaemonSet。如果叢集建立時已啟用 Dataplane V2,則不必執行這個步驟。詳情請參閱「移除閒置的 Calico DaemonSet」。
遷移負載平衡器類型
建議的負載平衡器類型 (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 控制器 (
pod prefix: load-balancer-f5):將 LoadBalancer 類型的 Kubernetes 服務,協調為 F5 Common Controller Core Library (CCCL) ConfigMap 格式。 - F5 BIG-IP CIS 控制器 1.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,並將管理員叢集遷移至高可用性
建議您使用 Controlplane V2 做為使用者叢集的控制層。使用 Controlplane V2 時,控制層會在使用者叢集本身的一或多個節點上執行。使用舊版控制層 (稱為 kubeception) 時,使用者叢集的控制層會在管理員叢集中執行。如要建立高可用性 (HA) 管理員叢集,使用者叢集必須啟用 Controlplane V2。
自 1.30 版起,新的使用者叢集必須啟用 Controlplane V2,新的管理員叢集則會採用高可用性架構。我們仍支援升級採用舊版控制層的使用者叢集,以及非高可用性管理員叢集。
將使用者叢集遷移至 Controlplane V2
使用者叢集過去採用 kubeception 架構,1.13 版推出 Controlplane V2 做為預先發布版功能,並在 1.14 版正式發布。自 1.15 版起,Controlplane V2 已成為建立使用者叢集的預設選項,且在 1.30 版中,Controlplane V2 是唯一選項。
相較於 kubeception,Controlplane V2 的優點包括:
- 架構一致性:管理員叢集和使用者叢集使用相同的架構。
- 故障隔離:管理員叢集故障不會影響使用者叢集。
- 作業區隔:升級管理員叢集不會導致使用者叢集停機。
- 部署作業區隔:您可以將管理員和使用者叢集放在不同的拓撲網域或多個位置。舉例來說,在邊緣運算部署模型中,使用者叢集可能位於與管理員叢集不同的位置。
遷移期間,現有使用者叢集工作負載不會停機。視基礎 vSphere 環境而定,在切換至 Controlplane V2 期間,控制層的停機時間會降至最低。遷移程序會執行下列操作:
- 在使用者叢集中建立新的控制層。
- 從舊控制層複製 etcd 資料。
- 將現有節點集區節點 (也稱為 worker 節點) 轉換至新的控制層。
| 遷移之前 | 遷移之後 | |
|---|---|---|
| 控制層 Kubernetes 節點物件 | 管理員叢集節點 | 使用者叢集節點 |
| Kubernetes 控制層 Pod | 管理員叢集 Statefulset/Deployment (使用者叢集命名空間) | 使用者叢集靜態 Pod (kube-system 命名空間) |
| 其他控制層 Pod | 管理員叢集 Statefulset/Deployment (使用者叢集命名空間) | 使用者叢集 Statefulsets/Deployments (kube-system 命名空間) |
| 控制層 VIP | 管理員叢集負載平衡器服務 | keepalived + haproxy (使用者叢集靜態 Pod) |
| Etcd 資料 | 管理員叢集永久磁碟區 | 資料磁碟 |
| 控制層機器 IP 管理 | IPAM 或 DHCP | IPAM |
| 控制層網路 | 管理員叢集 VLAN | 使用者叢集 VLAN |
遷移至高可用性管理員叢集
過去,管理員叢集只能執行單一控制層節點,因此存在單點故障的固有風險。除了控制層節點外,非高可用性管理員叢集還有兩個外掛程式節點。高可用性管理員叢集有三個控制層節點,沒有外掛程式節點,因此新管理員叢集所需的 VM 數量不變,但可用性大幅提升。從 1.16 版開始,您可以使用高可用性 (HA) 管理員叢集,這在 1.28 版中成為建立新叢集的唯一選項。
遷移至高可用性管理員叢集有下列好處:
- 提升可靠性和運作時間:高可用性設定可消除單點故障,即使其中一個控制層節點發生問題,管理員叢集仍可正常運作。
- 升級和更新體驗更完善:升級和更新管理員叢集的所有必要步驟,現在都會在叢集內執行,而非在獨立的管理員工作站中執行。這樣一來,即使管理員工作站的初始工作階段中斷,升級和更新作業仍可繼續進行。
- 可靠的叢集狀態資訊來源:非高可用性管理員叢集仰賴頻外「檢查點檔案」來儲存管理員叢集狀態。相較之下,高可用性管理員叢集會將最新的叢集狀態儲存在管理員叢集本身,為叢集狀態提供更可靠的可靠資料來源。
您可以選擇將非高可用性管理員叢集遷移至高可用性管理員叢集,使用者工作負載不會因此停機。這項程序會造成最短的停機時間,並盡可能減少對現有使用者叢集的干擾,主要與控制層切換有關。遷移程序會執行下列作業:
- 建立新的高可用性控制層。
- 從現有的非高可用性叢集還原 etcd 資料。
- 將使用者叢集轉換至新的高可用性管理員叢集。
| 遷移之前 | 遷移之後 | |
|---|---|---|
| 控制層節點備用資源數量 | 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。
確認 Dataplane V2 遷移作業已完成,且不需要復原至 Calico 後,請從
OnPremUserCluster自訂資源中移除features.onprem.cluster.gke.io/dpv2-migration註解 (如果管理員叢集是在從 1.29 版升級至 1.30 版期間從 Calico 遷移,則也請從OnPremAdminCluster中移除)。在調度資源或升級叢集前移除這個註解,叢集控制器就能永久刪除休眠的calico-node和calico-route-daemonDaemonSet。如需操作說明,請參閱「移除休眠的 Calico DaemonSet」。
將每個使用者叢集從舊版負載平衡器 (LB) 和舊版控制層 (CP) 遷移,改用建議的負載平衡器和 Controlplane V2。
- 變更設定,改用建議的負載平衡器 (
MetalLB或ManualLB)。 - 變更設定,啟用 Controlplane V2。
- 更新使用者叢集,遷移負載平衡器和控制層。
- 變更設定,改用建議的負載平衡器 (
遷移管理員叢集,改用建議的負載平衡器,並提高控制層的高可用性。
- 變更設定,改用建議的負載平衡器 (
MetalLB或ManualLB)。 - 變更設定,將管理員叢集的控制層從非高可用性遷移至高可用性。
- 更新管理員叢集,遷移負載平衡器和控制層。
- 變更設定,改用建議的負載平衡器 (
執行選用的清除步驟,例如清除非高可用性控制層 VM。
下圖說明遷移步驟:
如果管理員叢集和所有使用者叢集都採用 1.30 以上版本,您可以使用群組遷移程序。如需詳細步驟,請參閱下列指南: