本页面介绍 Anthos clusters on VMware (GKE On-Prem) 中的高可用性 (HA) 选项、如何设置 Anthos clusters on VMware 组件以实现高可用性以及如何从灾难中恢复。
核心功能
Anthos clusters on VMware 包括一个管理员集群以及一个或多个用户集群。
管理员集群管理用户集群的生命周期，包括用户集群创建、更新、升级和删除。在管理员集群中，管理员主节点管理管理员工作器节点，这些节点包括用户主节点（运行代管式用户集群的控制层面的节点）和插件节点（运行支持管理员集群功能的插件组件的节点）。
对于每个用户集群，管理员集群都有一个运行控制层面的非 HA 节点或三个高可用性节点。控制层面包括 Kubernetes API 服务器、Kubernetes 调度程序、Kubernetes 控制器管理器以及用户集群的几个关键控制器。
用户集群的控制层面可用性对于工作负载操作（例如工作负载创建、纵向扩容和终止）至关重要。换句话说，控制层面中断不会影响正在运行的工作负载，但现有的工作负载会在 Kubernetes API 服务器失去管理功能时丢失。
容器化工作负载和服务部署在用户集群工作器节点中。只要应用的部署方式使得可在多个工作器节点上调度冗余 pod，那么任何单个工作器节点对于应用可用性都不是不可或缺的。
Anthos clusters on VMware 旨在确保故障尽可能与功能区域隔离，并优先保障对业务连续性至关重要的功能。
Anthos clusters on VMware 的核心功能具有以下类别：
应用生命周期
现有工作负载可以连续运行。这是确保业务连续性的最重要功能。
您可以创建、更新和删除工作负载。这是第二重要的功能，因为 Anthos clusters on VMware 需要在流量增加时扩缩工作负载。
用户集群生命周期
您可以添加、更新、升级和删除用户集群。。这一功能不太重要，因为无法修改用户集群不会影响用户工作负载。
管理员集群生命周期
您可以更新和升级管理员集群。这是最不重要的功能，因为管理员集群不托管任何用户工作负载。
故障模式
以下类型的故障可能会影响 Anthos clusters on VMware 集群的性能。
ESXi 主机故障
运行托管 Kubernetes 节点的虚拟机的 ESXi 主机可能会停止运行或变为网络分区。
| 现有工作负载 | 创建、更新和删除工作负载 | 用户集群生命周期 | 管理员集群生命周期 |
|---|---|---|---|
| 可能中断 + 自动恢复 |
可能中断 + 自动恢复 |
中断 + 自动恢复 |
中断 + 自动恢复 |
在由故障主机托管的虚拟机上运行的 Pod 会中断，并会自动重新安排到其他运行状况良好的虚拟机上。 如果用户应用有备用工作负载容量并且分布在多个节点上，则进行重试的客户端无法观察到中断。 |
如果主机故障影响非 HA 用户集群中的控制层面虚拟机或 HA 用户集群中的多个控制层面虚拟机，则会发生中断。 | 如果主机故障影响管理员集群中的控制层面虚拟机或工作器虚拟机，则会发生中断。 | 如果主机故障影响管理员集群中的控制层面虚拟机，则会发生中断。 |
| vSphere HA 会在运行状况良好的主机上自动重启虚拟机。 | vSphere HA 会在运行状况良好的主机上自动重启虚拟机。 | vSphere HA 会在运行状况良好的主机上自动重启虚拟机。 | vSphere HA 会在运行状况良好的主机上自动重启虚拟机。 |
| 以高可用方式部署工作负载，以尽量降低中断的可能性。 | 使用 HA 用户集群，以尽量降低中断的可能性。 |
虚拟机故障
虚拟机可能会被意外删除，或者启动磁盘可能遭到损坏。此外，虚拟机可能会由于操作系统问题而被破解。
| 现有工作负载 | 创建、更新和删除工作负载 | 用户集群生命周期 | 管理员集群生命周期 |
|---|---|---|---|
| 可能中断 + 自动恢复 |
可能中断 + 自动恢复 |
中断 + 自动/手动恢复 |
中断 + 手动恢复 |
在故障工作器虚拟机上运行的 Pod 会中断，并且会被 Kubernetes 自动重新安排到其他运行状况良好的虚拟机上。 如果用户应用有备用工作负载容量并且分布在多个节点上，则进行重试的客户端无法观察到中断。 |
如果非 HA 用户集群中的控制层面虚拟机或 HA 用户集群中的多个控制层面虚拟机出现故障，则会发生中断。 | 如果管理员集群中的控制层面虚拟机或工作器虚拟机出现故障，则会发生中断。 | 如果管理员集群中的控制层面虚拟机出现故障，则会发生中断。 |
| 如果用户集群启用了节点自动修复功能，则故障虚拟机会自动恢复。 | 如果管理员集群启用了节点自动修复功能，则故障虚拟机会自动恢复。 | 如果管理员集群启用了节点自动修复功能，则管理员集群中的故障工作器虚拟机会自动恢复。 如要恢复管理员集群的控制层面虚拟机，请参阅修复管理员集群的控制层面虚拟机。 |
如要恢复管理员集群的控制层面虚拟机，请参阅修复管理员集群的控制层面虚拟机。 |
| 以高可用方式部署工作负载，以尽量降低中断的可能性。 | 使用 HA 用户集群，以尽量降低中断的可能性。 |
存储故障
VMDK 文件中的内容可能会因虚拟机不安全关机而遭到损坏，或者数据存储区故障可能会导致 etcd 数据和 PersistentVolume (PV) 丢失。
etcd 故障
| 现有工作负载 | 创建、更新和删除工作负载 | 用户集群生命周期 | 管理员集群生命周期 |
|---|---|---|---|
| 不会中断 | 可能中断 + 手动恢复 |
中断 + 手动恢复 |
中断 + 手动恢复 |
| 如果非 HA 用户集群中的 etcd 存储区或 HA 用户集群中的多个 etcd 副本出现故障，则会发生中断。 | 如果非 HA 用户集群中的 etcd 存储区或 HA 用户集群中的多个 etcd 副本出现故障，则会发生中断。 如果管理员集群中的 etcd 副本出现故障，则会发生中断。 |
如果管理员集群中的 etcd 副本出现故障，则会发生中断。 | |
| Anthos clusters on VMware 提供恢复故障的手动流程。 | Anthos clusters on VMware 提供从故障中恢复的手动流程。 | Anthos clusters on VMware 提供从故障中恢复的手动流程。 |
用户应用 PV 故障
| 现有工作负载 | 创建、更新和删除工作负载 | 用户集群生命周期 | 管理员集群生命周期 |
|---|---|---|---|
| 可能中断 | 不会中断 | 不会中断 | 不会中断 |
使用故障 PV 的工作负载会受到影响。 以高可用方式部署工作负载，以尽量降低中断的可能性。 |
负载均衡器故障
负载均衡器故障可能会影响公开 LoadBalancer 类型的 Service 的用户工作负载。
| 现有工作负载 | 创建、更新和删除工作负载 | 用户集群生命周期 | 管理员集群生命周期 |
|---|---|---|---|
| 中断 + 手动恢复 |
|||
|
中断几秒钟，直至备用负载均衡器恢复管理员控制层面 VIP 连接。 如果使用 Seesaw，服务中断可能长达 2 秒；如果使用 F5，服务中断可能长达 300 秒。 随着负载均衡器节点数量的增加，MetalLB 的故障转移中断时长也会增加。如果节点少于 5 个，则中断在 10 秒内。 Seesaw HA 会自动检测故障并故障切换至使用备份实例。 Anthos clusters on VMware 提供从 Seesaw 故障中恢复的手动流程。 |
|||
启用高可用性
vSphere 和 Anthos clusters on VMware 提供了很多有助于实现高可用性 (HA) 的功能。
vSphere HA 和 vMotion
我们建议在用于托管 Anthos clusters on VMware 集群的 vCenter 集群中启用以下两个功能：
在 ESXi 主机出现故障时，这些功能可增强可用性和恢复能力。
vCenter HA 使用配置为集群的多个 ESXi 主机，为在虚拟机中运行的应用提供快速的中断恢复能力和经济实惠的高可用性。我们建议您为 vCenter 集群预配额外的主机，启用 vSphere HA 主机监控，并将 Host Failure Response 设置为 Restart VMs。这样，当 ESXi 主机发生故障时，您的虚拟机可以在其他可用的主机上自动重启。
vMotion 支持将虚拟机从一个 ESXi 主机实时迁移到另一个主机，实现零停机时间。对于计划的主机维护，您可以使用 vMotion 实时迁移完全避免应用停机并确保业务连续性。
管理员集群
Anthos clusters on VMware 不支持为管理员集群运行多个控制层面。但是，没有管理员控制层面不会影响现有用户集群功能或用户集群中运行的任何工作负载。
管理员集群中有两个插件节点。如果其中一个发生故障，另一个仍然可以处理管理员集群操作。为了实现冗余，Anthos clusters on VMware 将关键的插件 Service（例如 kube-dns）分布到两个插件节点上。
如果您在管理员集群配置文件中将 antiAffinityGroups.enabled 设置为 true，则 Anthos clusters on VMware 会自动为插件节点创建 vSphere DRS 反亲和性规则，这会使它们分布到两个物理主机上，以实现高可用性。
用户集群
您可以在用户集群配置文件中将 masterNode.replicas 设置为 3，从而为用户集群启用高可用性。这会在管理员集群中生成三个节点，每个节点都会为用户集群运行一个控制层面。每个这些节点还会运行一个 etcd 副本。只要有一个控制层面在运行并且存在 etcd 仲裁，用户集群就会继续工作。etcd 仲裁需要三个 etcd 副本中有两个在正常运行。
如果您在管理员集群配置文件中将 antiAffinityGroups.enabled 设置为 true，Anthos clusters on VMware 会自动为运行用户集群控制层面的三个节点创建 vSphere DRS 反亲和性规则。这会使这些虚拟机分布到三个物理主机上。
Anthos clusters on VMware 还会为用户集群中的工作器节点创建 vSphere DRS 反亲和性规则，使这些节点分布到至少三个物理主机上。每个用户集群节点池根据节点数量使用多个 DRS 反亲和性规则。这样可以确保工作器节点能够找到要运行它的主机，即使主机数量少于用户集群节点池中的虚拟机数量也是如此。我们建议您在 vcenter 集群中添加额外的物理主机。此外，请将 DRS 配置为完全自动化，这样，如果某个主机不可用，DRS 可以自动在其他可用主机上重启虚拟机，而不会违反虚拟机的反亲和性规则。
Anthos clusters on VMware 会维护一个特殊节点标签 onprem.gke.io/failure-domain-name，其值设置为底层 ESXi 主机名。需要高可用性的用户应用可以设置 podAntiAffinity 规则并将此标签作为 topologyKey，以确保其应用 Pod 分布到不同的虚拟机和物理主机上。您还可以为具有不同数据存储区和特殊节点标签的用户集群配置多个节点池。同样，您可以设置 podAntiAffinity 规则并将该特殊节点标签作为 topologyKey，以便在数据存储区发生故障时实现更高的可用性。
如需使用户工作负载具有高可用性，请确保用户集群在 nodePools.replicas 下有足够数量的副本，这将确保有所需数量的用户集群工作器节点处于运行状态。
您可以为管理员集群和用户集群使用不同的数据存储区，以隔离它们的故障。
负载均衡器
您可以使用两种负载均衡器类型来实现高可用性。
捆绑式 MetalLB 负载均衡器
对于捆绑式 MetalLB 负载均衡器，您可以通过将多个节点使用 enableLoadBalancer: true 来实现 HA。
MetalLB 将服务分发到负载均衡器节点，但对于单个服务，只有一个主节点来处理该服务的所有流量。
在集群升级期间，负载均衡器节点的升级会导致一些停机时间。随着负载均衡器节点数量的增加，MetalLB 的故障转移中断时长也会增加。如果节点少于 5 个，则中断在 10 秒内。
捆绑式 Seesaw 负载均衡器
对于捆绑式 Seesaw 负载均衡器，您可以通过在集群配置文件中将 loadBalancer.seesaw.enableHA 设置为 true 来实现高可用性。此外，您还必须在负载均衡器端口组上同时启用 MAC 学习、模拟传输和混杂模式。
启用高可用性后，两个负载均衡器会设置为主动-被动模式。如果主动负载均衡器存在问题，则流量将故障切换到被动负载均衡器。
在负载均衡器升级期间，会有一些停机时间。如果为负载均衡器启用了高可用性，则最长停机时间为两秒。
集成式 F5 BIG-IP 负载均衡器
F5 BIG-IP 平台提供了各种 Service，帮助您增强应用的安全性、可用性和性能。对于 Anthos clusters on VMware，BIG-IP 会提供外部访问权限和 L3/4 负载均衡 Service。
如需了解详情，请参阅 BIG-IP 高可用性。
恢复损坏的集群
以下部分介绍了如何恢复损坏的集群。
从 ESXi 主机故障中恢复
发生 ESXi 主机故障时，Anthos clusters on VMware 依赖 vSphere HA 进行恢复。vSphere HA 可以持续监控 ESXi 主机，并在需要时自动在其他主机上重启虚拟机。Anthos clusters on VMware 用户察觉不到这些操作。
从虚拟机故障中恢复
虚拟机故障可能包括以下内容：
意外删除虚拟机。
虚拟机启动磁盘损坏；例如，启动磁盘由于垃圾日志而变为只读。
性能不佳的磁盘或网络设置问题导致虚拟机启动失败；例如，由于某个原因无法分配 IP 地址而导致虚拟机无法启动。
Docker 叠加文件系统损坏。
由于升级失败导致管理员控制层面虚拟机丢失。
操作系统问题。
本部分讨论的虚拟机故障不包含挂接到虚拟机的 PV 或 etcd 数据磁盘上的数据损坏或丢失情况。如需了解详情，请参阅从存储故障中恢复。
Anthos clusters on VMware 为管理员插件节点、用户控制层面和用户节点提供自动恢复机制。您可以为每个管理员集群和用户集群启用此节点自动修复功能。
管理员控制层面虚拟机比较特殊，因为它并非由 Kubernete 集群管理，其可用性不会影响业务连续性。如需从管理员控制层面虚拟机故障中恢复，请与 Google 支持团队联系。
从存储故障中恢复
vSphere HA 和 vSAN 可以缓解一些存储故障，而不会影响 Anthos clusters on VMware。但是，某些存储故障可能会发生在 vSphere 级层，导致各种 Anthos clusters on VMware 组件出现数据损坏或丢失。
集群和用户工作负载的有状态信息存储在以下位置：
etcd
每个集群（管理员集群和用户集群）都有一个存储集群状态（Kubernetes 对象）的 etcd 数据库。
PersistentVolume
系统组件和用户工作负载均使用。
从 etcd 数据损坏或丢失中恢复
Etcd 是 Kubernetes 用于存储所有集群状态（包括用户应用清单）的数据库。如果用户集群的 etcd 数据库损坏或丢失，则应用生命周期操作将停止运行。如果管理员集群的 etcd 数据库损坏或丢失，则用户集群生命周期操作将停止运行。
Etcd 不提供用于数据损坏检测的可靠内置机制。如果您怀疑 etcd 数据损坏或丢失，则需要查看 etcd Pod 的日志。
挂起/错误/崩溃循环的 etcd Pod 不一定表示 etcd 数据损坏或丢失。这有可能是托管 etcd Pod 的虚拟机上的错误导致的。您应仅为数据损坏或丢失情况执行以下 etcd 恢复。
为了能够从 etcd 数据损坏或丢失恢复（到最近的集群状态），必须在集群中的任何生命周期操作（例如创建、更新或升级）之后备份 etcd 数据。如需备份 etcd 数据，请参阅备份管理员集群和备份用户集群。
恢复 etcd 数据会使集群回到之前的状态。换句话说，如果在部署应用之前备份，然后将该备份用于恢复集群，那么应用将不会在恢复的集群中运行。例如，如果您使用创建用户集群之前截取的管理员集群的 etcd 快照，则恢复的管理员集群将会移除用户集群控制层面。因此，我们建议您在每个关键集群操作后备份集群。
etcd 数据损坏/丢失故障可能会在以下情况下发生：
三节点 etcd 集群（HA 用户集群）的一个节点由于数据损坏或丢失而永久损坏。此时，只有一个节点损坏，并且 etcd 仲裁仍然存在。在 HA 集群中，如果其中一个 etcd 副本的数据损坏或丢失，就有可能发生这种情况。可以通过将故障 etcd 副本替换为默认状态的新副本来解决此问题，而不会丢失任何数据。如需了解详情，请参阅替换故障 etcd 副本。
三节点 etcd 集群（HA 用户集群）的两个节点由于数据损坏或丢失而永久损坏。仲裁丢失，因此将故障 etcd 副本替换为新副本将无效。必须从备份数据恢复集群状态。如需了解详情，请参阅从备份 (HA) 恢复用户集群。
单节点 etcd 集群（管理员集群或非 HA 用户集群）由于数据损坏或丢失而永久损坏。仲裁丢失，因此您必须通过备份创建新集群。如需了解详情，请参阅从备份（非 HA）恢复用户集群。
从用户应用 PV 损坏或丢失中恢复
Anthos clusters on VMware 客户可以使用某些合作伙伴存储解决方案来备份和恢复用户应用 PersistentVolume。
如需查看符合 Anthos clusters on VMware 资格的存储合作伙伴列表，请参阅 Anthos Ready 存储合作伙伴。
从负载均衡器故障中恢复
对于捆绑式 Seesaw 负载均衡器，您可以通过重新创建负载均衡器来从故障中恢复。如需重新创建负载均衡器，请将 Seesaw 升级到为管理员集群升级负载均衡器中所述的同一版本。
如果管理员集群负载均衡器出现故障，则控制层面可能无法完成升级。因此，您需要在具有控制层面访问权限的管理员控制层面虚拟机上运行升级。
对于集成式负载均衡器 (F5)，请咨询 F5 支持。
对于捆绑式 MetalLB 负载均衡器，系统使用集群节点作为负载均衡器。负载均衡器问题不会触发自动节点修复。您可以按照手动过程修复节点。
使用多个集群进行灾难恢复
在跨多个 vCenter 或 Anthos 平台的多个集群中部署应用可提供更高的全球可用性并限制中断的影响范围。
此设置使用次要数据中心中的现有 Anthos 集群进行灾难恢复，而不是设置新集群。下面是实现此设置的简要概述：
在次要数据中心中再创建一个管理员集群和用户集群。在这种多集群架构中，我们要求用户在每个数据中心中有两个管理员集群，并且每个管理员集群运行一个用户集群。
次要用户集群具有最少数量的工作器节点（3 个），并且是热备用（始终运行）。
可以使用 Anthos Config Management 在两个 vCenter 之间复制应用部署，或者首选方法是利用现有应用 DevOps（CI/CD、spinnaker）工具链。
如果发生灾难，用户集群的大小可以调整为节点数量。
此外，需要使用 DNS 切换将集群之间的流量路由到次要数据中心。