GKE on VMware 集群升级的最佳实践

本文档介绍了升级 GKE on VMware 的最佳实践和注意事项。您将了解如何准备集群升级，以及升级之前应遵循的最佳实践。这些最佳实践有助于降低与集群升级相关的风险。

如果您有多个环境（例如测试环境、开发环境和生产环境），我们建议您从最不重要的环境（例如测试环境）开始，并验证升级功能。验证升级成功后，进入下一个环境。重复此过程，直到升级生产环境。这种方法可让您从一个关键点转到下一个关键点，并验证升级和工作负载是否正常运行。

升级核对清单

为了使升级过程尽可能顺利，请在开始升级集群之前查看并完成以下检查：

规划升级

更新可能会造成干扰。在开始升级之前，请仔细规划，确保您的环境和应用已准备就绪。

备份用户和管理员集群

在开始升级之前，请备份您的用户和管理员集群。

用户集群备份是用户集群的 etcd 存储区的快照。 etcd 存储区包含管理集群状态所需的所有 Kubernetes 对象和自定义对象。快照包含重新创建集群组件和工作负载所需的数据。如需了解详情，请参阅如何备份用户集群。

借助 GKE on VMware 1.8 版及更高版本，您可以在管理员集群配置文件中使用 clusterBackup.datastore 设置自动备份。如需在现有集群中启用此功能，请修改管理员集群配置文件并添加 clusterBackup.datastore 字段，然后运行 gkectl update admin。

启用 clusterBackup.datastore 后，管理员集群会在配置的 vSphere 数据存储区上的 etcd 中自动备份。每次更改管理员集群时，都会重复此备份过程。当您启动集群升级时，备份任务会在升级集群之前运行。

如果遇到问题，要从备份恢复管理员集群，请参阅使用 gkectl 备份和恢复管理员集群。

查看 PodDisruptionBudgets 的用法

在 Kubernetes 中，PodDisruptionBudgets (PDB) 有助于防止不必要的应用停机或中断。PDB 会指示调度程序始终让一定数量的 Pod 保持运行状态（在其他 Pod 可能发生故障时）。此行为是提供应用可用性的一个实用方法。

  1. 如需查看集群中配置的 PDB，请使用 kubectl get pdb 命令：

    kubectl get pdb -A --kubeconfig KUBECONFIG

    将 KUBECONFIG 替换为您的 kubeconfig 文件的名称。

    以下示例输出显示了名为 istio-ingress、istiod 和 kube-dns 的 PDB：

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

上表中的每个 PDB 指定至少有一个 Pod 必须始终可用。在升级期间，当节点排空时，这种可用性至关重要。

检查无法完成的 PDB。例如，当 Deployment 仅具有 1 个副本时，可以将最小可用性设置为 1。在此示例中，由于资源控制器无法满足 PDB 操作，排空操作中断。

为确保 PDB 不会干扰升级过程，请在开始升级之前检查给定集群上的所有 PDB。您可能需要与开发团队和应用所有者协调，以在集群升级期间临时更改或停用 PDB。

GKE on VMware 在升级过程中会运行预检检查，以就 PDB 发出警告。但是，您还应手动验证 PDB，以确保顺畅升级。如需详细了解 PDB，请参阅为应用指定中断预算。

查看可用的 IP 地址

集群升级期间，需要注意以下 IP 地址事项：

  • 集群升级过程会创建一个新节点，并在删除旧节点之前排空资源。我们建议您始终为管理员集群或用户集群提供 N+1 个 IP 地址，其中 N 是集群中的节点数。
  • 使用静态 IP 地址时，所需 IP 地址必须列在 IP 地址块文件中。
  • 如果您使用 DHCP，请确保新虚拟机在升级期间可获得所需子网中的其他 IP 租期。
    • 如果您需要添加 IP 地址，请更新 IP 块文件，然后运行 gkectl update 命令。如需了解详情，请参阅规划 IP 地址。
  • 如果您使用静态 IP 地址并希望加快用户集群升级过程，请在 IP 地址块文件中列出足够的 IP 地址，以便每个节点池可以有额外的 IP 地址。这种方法可让升级过程加快对虚拟机执行添加和移除步骤，因为它是按节点池执行的。
    • 虽然这种方法是个不错的加快用户集群升级的方案，但在继续之前，请考虑 vSphere 环境的资源和性能可用性。
  • 如果整个用户集群只有一个备用 IP 地址，则此限制会减慢升级过程，一次减慢一个虚拟机，即使使用多个节点池也是如此。

检查集群利用率

确保可以在节点排空时清空 Pod，并且正在升级的集群中有足够的资源来管理升级。如需检查集群的当前资源使用情况，您可以使用 Cloud Operations Suite 中的自定义信息中心，也可以直接在集群上使用 kubectl top nodes 等命令。

您针对集群运行的命令会显示当前集群资源用量的快照。信息中心可以提供更详细的资源使用情况随时间变化的视图。此资源使用情况数据有助于指示升级何时会导致最少的服务中断（例如在周末或晚上），具体取决于正在运行的工作负载和使用场景。

管理员集群升级的时间可能不如用户集群那么重要，因为管理员集群升级通常不会导致应用停机。但是，在开始管理员集群升级之前，请务必检查 vSphere 中的可用资源。此外，升级管理员集群可能会带来一些风险，因此建议在不太活跃的使用期间（对集群的管理访问不太重要时）升级管理员集群。

如需了解详情，请参阅集群升级期间受影响的服务。

检查 vSphere 利用率

检查底层 vSphere 基础架构上是否有足够的资源。如需查看此资源使用情况，请选择 vCenter 中的集群，然后查看摘要标签页。

“摘要”标签页显示整个集群的整体内存、CPU 和存储空间消耗情况。由于 GKE on VMware 升级需要更多资源，因此您还应检查集群是否可以处理这些额外的资源请求。

一般来说，您的 vSphere 集群必须能够支持以下额外的资源：

  • 每个管理员集群升级 +1 个虚拟机
  • 每次用户集群升级为每个节点池 +1 个虚拟机

例如，如果您升级一个具有 3 个节点（每个节点有 8 个 vCPU 和 32GB 或更多 RAM）的用户集群，则升级过程会使用以下额外的资源：

  • 24 个 vCPU
  • 256GB RAM
  • 虚拟机磁盘空间 + 256GB 的 vSwap

升级过程会使用 vSphere 克隆操作创建虚拟机。从模板克隆多个虚拟机可能会以上升的 I/O 操作的形式给底层存储系统带来压力。如果底层存储子系统无法在升级期间提供足够的性能，则升级速度可能会严重减慢。

虽然 vSphere 设计为同时使用资源并具有提供资源的机制（即使过度使用），但我们强烈建议您不要过度使用虚拟机内存。内存过度使用可能会导致严重的性能影响（影响整个集群），因为 vSphere 提供将页面交换到数据存储区中的“缺失 RAM”。此行为可能会导致集群升级期间出现问题，并对 vSphere 集群上其他正在运行的虚拟机产生性能影响。

如果可用资源已经不足，请关闭不需要的虚拟机，以满足这些额外要求并防止潜在的性能损失。

诊断集群问题。

如需在升级前检查集群的运行状况，请针对集群运行 gkectl diagnose。该命令会运行高级检查，例如识别未正确配置的节点或者处于卡滞状态的 Pod。

gkectl upgrade 命令会运行预检检查，如果这些检查失败，则停止升级过程。最好主动识别并修复这些问题，而不是依靠预检检查来保护集群免遭任何可能的损坏。由于 gkectl diagnose 命令执行的检查要比常规预检检查多，因此我们建议您在升级前手动运行此命令。

如果 gkectl diagnose 命令显示 Cluster unhealthy 警告，请在尝试升级之前解决问题。

如需了解详情，请参阅诊断集群问题。

使用 Deployment 来最大限度地减少应用中断

由于节点在更新期间需要排空，因此集群升级可能会导致应用中断。排空节点意味着必须关停所有正在运行的 Pod，然后再在集群中的其余节点上重启。

如有可能，您的应用应使用 Deployment。通过这种方法，应用设计为可以处理中断。对具有多个副本的 Deployment 的影响应该最小。如果应用不使用 Deployment，您仍然可以升级集群。

还有一些 Deployment 规则，用于确保让一定数量的副本始终保持运行状态。这些规则称为 PodDisruptionBudgets (PDB)。当出于某种原因（例如集群节点上的升级或维护）必须重新安排其 Pod 时，PDB 允许您限制对工作负载的中断，并且在升级之前进行检查很重要。

使用高可用性负载均衡器对

如果您在集群上使用 Seesaw 作为负载均衡器，则在您升级集群时，负载均衡器会自动升级。此升级可能会导致服务中断。为了减少升级和最终负载均衡器故障的影响，您可以使用高可用性对（HA 对）。在此配置中，系统会创建并配置两个负载均衡器虚拟机，以便发生到另一个对等体的故障切换。

为了提高服务可用性（即对 Kubernetes API 服务器而言），我们建议您始终在管理员集群前面使用高可用性对。如需详细了解 Seesaw 及其 HA 配置，请参阅使用 Seesaw 进行捆绑式负载均衡。

为防止使用高可用性对升级期间服务中断，集群会在创建新的负载均衡器虚拟机之前启动故障切换。如果用户集群仅使用单个负载均衡器实例，则在负载均衡器的升级完成之前，服务中断。

如果用户集群本身也配置为高可用性，我们建议您使用高可用性负载均衡器对。本最佳实践系列文章假设高可用性用户集群使用高可用性负载均衡器对。

如果 GKE on VMware 版本 1.11 或 1.12 使用 MetalLB 作为捆绑式负载均衡器，则无需进行升级前设置。负载均衡器会在集群升级过程中升级。

升级序列

从 1.7 版开始，就地升级必须始终遵循特定升级序列：

  1. 升级管理员工作站。

  2. 逐个升级用户集群。

    如果您决定不升级所有用户集群，则无法升级管理员集群。如果升级所有用户集群，则可以选择升级管理员集群。

  3. 升级管理员集群作为最后的可选步骤。

集群类型之间的差异

集群有两种不同的类型：

  • 用户集群
  • 管理员集群

创建用户集群时，用户集群仅包含工作器节点，而不包含控制平面节点。在管理员集群中为所有附加的用户集群添加或创建控制平面节点。当用户工作负载和控制平面节点分开时，这种方法使 GKE on VMware 能以更灵活的方式以不同方式处理升级。

用户集群与管理员集群升级的不同影响

GKE on VMware 升级过程涉及一个节点排空过程，该过程会从节点中移除所有 Pod。该过程会为每个排空的工作器创建一个新虚拟机，并将其添加到集群中。排空的工作器随后会从 VMware 的清单中移除。在此过程中，在这些节点上运行的任何工作负载都将停止并在集群中的其他可用节点上重启。

此过程可能会影响工作负载的可用性，具体取决于工作负载的所选架构。为避免对集群资源能力造成过多压力，GKE on VMware 一次升级一个节点。

用户集群中断

下表介绍了就地用户集群升级的影响：

函数 管理员集群 非高可用性用户集群 高可用性用户集群
Kubernetes API 访问权限 不受影响 不受影响 不受影响
用户工作负载 不适用 受影响 受影响
PodDisruptionBudgets* 不受影响 不受影响 不受影响
控制平面节点 不受影响 受影响 不受影响
Pod 自动扩缩器 (VMware) 不受影响 不受影响 不受影响
自动修复 不受影响 不受影响 不受影响
节点自动扩缩 (VMware) 不受影响 不受影响 不受影响
Pod 横向自动扩缩 受影响 受影响 不受影响
  • *：PDB 可能会导致升级失败或停止。
  • 受影响：升级期间服务中断明显，直到升级完成。
  • 不受影响：服务中断可能在很短的时间内发生，但几乎不明显。

升级管理员集群不会中断用户集群工作负载。管理员集群仅包含用户控制平面节点，该节点不运行任何用户工作负载。在升级期间，这些控制平面节点会被排空，然后进行相应更新。

如需在升级期间提高可用性并减少生产用户集群中断，我们建议您使用三个控制平面节点（高可用性模式）。

管理员集群中断

下表介绍了就地管理员集群升级的影响：

函数 管理员集群 非高可用性用户集群 高可用性用户集群
Kubernetes API 访问权限 受影响 受影响 不受影响
用户工作负载 不适用 不受影响 不受影响
PodDisruptionBudgets 受影响 受影响 不受影响
控制平面节点 受影响 受影响 不受影响
Pod 自动扩缩器 受影响 受影响 不受影响
自动修复 受影响 受影响 不受影响
节点自动扩缩 受影响 受影响 不受影响
Pod 横向自动扩缩 受影响 受影响 不受影响
  • 受影响：升级期间服务中断明显，直到升级完成。
  • 不受影响：服务中断可能在很短的时间内发生，但几乎不明显。

后续步骤