规划将集群迁移到推荐功能

概览

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 IP^1 (loadBalancer.kind: "F5BigIP") Seesaw (loadBalancer.kind: "Seesaw")
管理员集群控制平面	高可用性 (HA) 管理员集群 (adminMaster.replicas: 3)	非 HA 管理员集群 (adminMaster.replicas: 1)
用户集群控制平面	Controlplane V2 (enableControlplaneV2: true)	Kubeception 用户集群 (enableControlplaneV2: false)

^{1 集成式 F5 BIG-IP 是指集群配置文件中 loadBalancer.f5BigIP 部分中的 loadBalancer.kind: "F5BigIP" 和相关设置。}

下表显示了管理员集群和用户集群中这些功能的支持矩阵：

集群类型	过时的功能	为新集群添加	允许集群升级	迁移到新功能
版本 1.30
管理员	非 HA	否	是	是
	Seesaw	否	是	是
	集成式 F5 Big IP	否	是	是
用户	Kubeception	否	是	是
	Seesaw	否	是	是
	集成式 F5 Big IP	否	是	是
	Dataplane V1	否	是	是
版本 1.29
管理员	非 HA	否	是	是（预览版）
	Seesaw	否	是	是
	集成式 F5 Big IP	是	是	是（预览版）
用户	Kubeception	是	是	是（预览版）
	Seesaw	是	是	是
	集成式 F5 Big IP	是	是	是（预览版）
	Dataplane V1	是	是	否
版本 1.28
管理员	非 HA	否	是	否
	Seesaw	否	是	是
	集成式 F5 Big IP	是	是	否
用户	Kubeception	是	是	否
	Seesaw	是	是	是
	集成式 F5 Big IP	是	是	否
	Dataplane V1	是	是	否

要点：

• 从 1.30 版开始，所有迁移解决方案都可以将集群迁移到推荐的替代方案。

• 创建新集群时，以下版本不允许使用原始功能：

  • 管理员集群：

    • 非 HA 控制平面：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 版开始，数据平面 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

迁移负载均衡器类型

建议使用的负载均衡器类型 (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 通用控制器核心库 (CCCL) ConfigMap 格式。
• F5 BIG-IP CIS Controller 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 代理处理（无变化）

注意：迁移后，您可以继续以相同的方式创建服务，因为 F5 代理仍将在集群中作为工作负载运行。唯一的区别在于，迁移后，您需要管理 F5 代理的生命周期。

从 Seesaw 迁移到 MetalLB

与 Seesaw 相比，MetalLB 具有以下优势：

• 简化管理并减少资源：与 Seesaw 不同，MetalLB 直接在集群节点上运行，可动态使用集群资源进行负载均衡。
• 自动 IP 分配：MetalLB 控制器为 Service 进行 IP 地址管理，因此您无需为每个 Service 手动选择 IP 地址。
• 在 LB 节点之间进行负载分布：不同 Service 的 MetalLB 的活跃实例可以在不同的节点上运行。
• 增强的功能和面向未来的解决方案：与 Seesaw 相比，MetalLB 的活跃开发和与更广泛的 Kubernetes 生态系统的集成使其成为更具前瞻性的解决方案。使用 MetalLB 可确保您能够利用负载均衡技术的最新进展。

	迁移前	迁移后
LB 节点	额外的 Seesaw 虚拟机（集群外）	具有客户选择的集群内 LB 节点
保留客户端 IP	可通过 externalTrafficPolicy: Local 实现	可通过 DataplaneV2 DSR 模式实现
服务创建	手动指定的服务 IP	从地址池自动分配的服务 IP

将用户集群迁移到 Controlplane V2，并将管理员集群迁移到高可用集群

我们建议为用户集群使用 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 版中，Controlplane V2 是唯一的选项。

与 kubeception 相比，Controlplane V2 的优势包括：

• 架构一致性：管理员集群和用户集群使用相同的架构。
• 故障隔离：管理员集群故障不会影响用户集群。
• 操作分离：管理员集群升级不会导致用户集群停机。
• 部署隔离：您可以将管理员集群和用户集群放在不同的拓扑域或多个位置。例如，在边缘计算部署模型中，用户集群可能与管理员集群位于不同的位置。

在迁移期间，现有用户集群工作负载不会出现停机时间。在切换到 Controlplane V2 期间，控制平面将经历最短的停机时间，具体取决于您的底层 vSphere 环境。迁移过程会执行以下操作：

• 在用户集群中创建新的控制平面。
• 从旧的控制平面复制 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 管理员集群还有两个插件节点。HA 管理员集群有三个控制平面节点，没有插件节点，因此新管理员集群所需的虚拟机数量没有变化，但可用性显著提高。从 1.16 版开始，您可以使用高可用性 (HA) 管理员集群，该集群在 1.28 版中成为创建新集群的唯一选项。

迁移到高可用性管理员集群可提供以下优势：

• 提高了可靠性和正常运行时间：高可用性配置消除了单点故障，即使其中一个控制平面节点遇到问题，管理员集群也能保持运行。
• 增强的升级和更新体验：升级和更新管理员集群所需的所有步骤现在都在集群中运行，而不是在单独的管理员虚拟机中运行。这样可以确保即使与管理员虚拟机的初始会话可能会中断，升级和更新也会继续进行。
• 可靠的集群状态可信来源：非 HA 管理员集群依赖于带外“检查点文件”来存储管理员集群状态。相比之下，HA 管理员集群会将最新的集群状态存储在管理员集群本身中，为集群状态提供更可靠的真实来源。

您可以选择将非高可用性管理员集群迁移到高可用性管理员集群，这不会导致用户工作负载停机。此过程会对现有用户集群造成最小的停机时间和中断，主要与控制平面切换相关。迁移过程会执行以下操作：

• 创建新的 HA 控制平面。
• 从现有的非 HA 集群恢复 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 或静态 IP，具体取决于 network.ipMode.type	3 个静态 IP 地址

将负载均衡器和控制平面迁移整合为一组

通常，在更新集群时，我们建议您一次只更新一项功能或设置。不过，在 1.30 版及更高版本中，您可以将负载均衡器和控制平面迁移的配置更改整合为一组，然后只需更新一次集群即可完成这两项更改。

如果您的用户集群使用的是旧版 CNI，您需要先迁移到 DataPlane V2。之后，您可以将负载均衡器和控制平面的迁移整合为一组。将迁移整合为一组可带来以下优势：

• 更简单的流程：如果您需要同时迁移控制平面和负载均衡器，通常只需更新一次集群即可。您无需决定需要优先迁移哪些功能。
• 缩短总停机时间：某些迁移会存在控制平面停机时间，因此将这些迁移组合到一个更新操作中比起依序执行单独的更新，可以缩短总停机时间。

此过程因集群配置而异。总体而言，请按以下顺序为每个集群执行迁移：

1. 迁移每个用户集群以使用推荐的 CNI (Dataplane V2)。

   1. 进行配置更改并更新用户集群，以触发将用户集群从 Calico 迁移到 Dataplane V2 的操作。

      注意：管理员集群无需执行此步骤。将管理员集群升级到版本 1.30 后，该集群会自动迁移到 Dataplane V2。

2. 迁移每个用户集群以使用推荐的负载均衡器和 Controlplane V2。

   1. 进行配置更改以使用建议的负载均衡器（MetalLB 或 ManualLB）。
   2. 进行配置更改以启用 Controlplane V2。
   3. 更新用户集群以迁移负载均衡器和控制平面。

3. 迁移管理员集群，以使用推荐的负载均衡器并使控制平面具有高可用性。

   1. 进行配置更改以使用建议的负载均衡器（MetalLB 或 ManualLB）。
   2. 进行配置更改，将管理员集群的控制平面从非 HA 迁移到 HA。
   3. 更新管理员集群以迁移负载均衡器和控制平面。

4. 执行可选的清理步骤，例如清理非 HA 控制平面虚拟机。

如果您的管理员集群和所有用户集群均为 1.30 版或更高版本，您可以使用组迁移流程。如需了解详细步骤，请参阅以下指南：

• 将用户集群迁移到推荐功能
• 将管理员集群迁移到推荐功能