規劃叢集遷移至建議功能

總覽

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)，包括 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 控制器
  • 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. 變更設定，使用建議的負載平衡器 (MetalLB 或 ManualLB)。
    2. 變更設定以啟用 Controlplane V2。
    3. 更新使用者叢集，遷移負載平衡器和控制層。

  3. 將管理員叢集遷移至建議的負載平衡器，並確保控制層具備高可用性。

    1. 變更設定，使用建議的負載平衡器 (MetalLB 或 ManualLB)。
    2. 進行設定變更，將管理員叢集的控制層從非高可用性遷移至高可用性。
    3. 更新管理員叢集，遷移負載平衡器和控制層。

  4. 執行選用的清除步驟，例如清除非高可用性控制層 VM。

下圖說明遷移步驟：

遷移至建議功能的步驟

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