規劃叢集遷移至建議功能

總覽

Google Distributed Cloud 以 Kubernetes 和許多其他相關技術為基礎,並持續更新和改良,以提供更優異的擴充性、效能、安全性和整合功能。因此,Google Distributed Cloud 會不斷調整和改進。

在 1.30 版中,變更和更新已達到一個階段,我們強烈建議您遷移舊版部署作業,以充分利用重大改善項目。本頁說明從過時功能遷移至最新建議功能的優點。

每個功能領域都有下列選項:

特色區域 建議選項 原始選項
容器網路介面 (CNI)
  • Dataplane V2
    (enableDataplaneV2: true)
  • Dataplane V1 (Calico)
    (enableDataplaneV2: false)
負載平衡器
  • ManualLB (適用於 F5 Big IP 代理程式)
    (loadBalancer.kind: "ManualLB")
  • MetalLB
    (loadBalancer.kind: "MetalLB")
  • 整合式 F5 Big IP1
    (loadBalancer.kind: "F5BigIP")
  • Seesaw
    (loadBalancer.kind: "Seesaw")
管理員叢集控制層
  • 高可用性 (HA) 管理員叢集
    (adminMaster.replicas: 3)
  • 非高可用性管理員叢集
    (adminMaster.replicas: 1)
使用者叢集控制層
  • Controlplane V2
    (enableControlplaneV2: true)
  • Kubeception 使用者叢集
    (enableControlplaneV2: false)

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),包括 CalicoDataplane 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 控制器
  • OSS CIS 控制器
  • F5 控制器 (無變更)
  • OSS CIS 控制器 (無變更)
升級 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。之後,您就可以將負載平衡器和控制層的遷移作業分組。分組遷移有以下好處:

  • 簡化程序:如果您需要遷移控制層和負載平衡器,通常只要更新叢集一次即可。您也不必決定要先遷移哪些功能。
  • 減少整體停機時間:部分遷移作業會導致控制層停機,因此將這些遷移作業分組為單一更新作業,與依序個別更新相比,可減少整體停機時間。

程序會因叢集設定而異。總而言之,請按照下列步驟,為每個叢集執行遷移作業:

  1. 將每個使用者叢集遷移至建議使用的 CNI Dataplane V2。

    1. 進行設定變更並更新使用者叢集,觸發使用者叢集從舊版 CNI (Calico) 遷移至 Dataplane V2。

  2. 將每個使用者叢集從舊版負載平衡器 (LB) 和舊版控制層 (CP) 遷移至建議的負載平衡器和 Controlplane V2。

    1. 變更設定,使用建議的負載平衡器 (MetalLBManualLB)。
    2. 變更設定以啟用 Controlplane V2。
    3. 更新使用者叢集,遷移負載平衡器和控制層。
  3. 將管理員叢集遷移至建議的負載平衡器,並確保控制層具備高可用性。

    1. 變更設定,使用建議的負載平衡器 (MetalLBManualLB)。
    2. 進行設定變更,將管理員叢集的控制層從非高可用性遷移至高可用性。
    3. 更新管理員叢集,遷移負載平衡器和控制層。
  4. 執行選用的清除步驟,例如清除非高可用性控制層 VM。

下圖說明遷移步驟:

遷移至建議功能的步驟

如果管理員叢集和所有使用者叢集都採用 1.30 以上版本,即可使用群組遷移程序。如需詳細步驟,請參閱下列指南: