Google Distributed Cloud 集群升级的最佳做法

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

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

注意 ：本文档重点介绍 1.8 及更高版本的 Google Distributed Cloud。一些提供自动检查的命令在较旧的版本中不可用。如果您运行的是较旧的集群，则必须手动运行部分检查。

升级核对清单

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

估算升级所需时间并规划升级的维护窗口。

为用户集群和管理员集群准备备份。

检查用户集群中的 PodDisruptionBudgets。

查看可用的 IP 地址和需求。

检查用户集群利用率和可用资源。

检查 vSphere 集群容量以了解 CPU、内存和就绪时间等可用资源。

请在升级前检查集群的健康状况和配置以解决问题。

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

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

确定如何升级每个用户集群。

检查是否需要轮替 CA 证书。

注意：虽然 gkectl upgrade 命令会自动运行一些预检检查，但这些检查无法取代手动升级准备。

规划升级

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

估算时间承诺并规划维护窗口

默认情况下，所有节点池都会并行升级，但在每个节点池内，节点会依序升级。因此，升级的总时间取决于最大节点池中的节点数量。如需粗略估算升级时间，请使用 15 分钟 * 最大节点池中的节点数。例如，如果最大的池中有 10 个节点，则总升级时间将约为 150 分钟。

在 1.28 版及更高版本中，您可以通过为单个节点池设置 maxSurge 的值来加快升级速度。

备份用户和管理员集群

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

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

借助 Google Distributed Cloud 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。

Google Distributed Cloud 在升级过程中会运行预检检查，以发出有关 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，并且正在升级的集群中有足够的资源来管理升级。如需检查集群的当前资源使用情况，您可以使用 Google Cloud Observability 中的自定义信息中心，也可以使用 kubectl top nodes 等命令直接在集群上使用。

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

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

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

检查 vSphere 利用率

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

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

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

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

例如，假设某个用户集群有 3 个节点池，其中每个节点池都有使用 8 个 vCPU 和 32GB 或更高 RAM 的节点。由于默认情况下 3 个节点池的升级会并行进行，因此升级过程会额外消耗 3 个超额配置节点的以下资源：

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

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

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

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

检查集群的健康状况和配置

升级之前，请在所有集群上运行以下工具：

• gkectl diagnose 命令：gkectl diagnose 可确保所有集群均正常运行。该命令会运行高级检查，例如识别未正确配置或 Pod 处于卡住状态的节点。如果 gkectl diagnose 命令显示 Cluster unhealthy 警告，请先修复问题，然后再尝试升级。如需了解详情，请参阅诊断集群问题。

• 升级前工具：除了检查集群的运行状况和配置外，还会检查集群升级期间可能发生的潜在已知问题。

此外，如果您要将用户集群升级到 1.29 及更高版本，我们建议您运行带有 --dry-run 标志的 gkectl upgrade cluster 命令。--dry-run 标志会运行预检检查，但不会启动升级过程。虽然早期版本的 Google Distributed Cloud 会运行预检检查，但它们在升级后无法单独运行。通过添加 --dry-run 标志，您可以查找并修复预检检查在升级之前发现的用户集群的所有问题。

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

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

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

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

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

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

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

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

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

如果您将 MetalLB 用作捆绑式负载均衡器，则无需进行升级前设置。负载均衡器会在集群升级过程中升级。

确定如何升级每个用户集群

在 1.14 及更高版本中，您可以选择将用户集群作为一个整体进行升级（这意味着您可以升级控制层面以及集群中的所有节点池），也可以升级用户集群的控制平面并将节点池保留为当前版本。如需了解您可能想要单独升级控制平面的原因，请参阅用户集群升级。

在多集群环境中，请跟踪哪些用户集群已升级并记录其版本号。如果您决定分别升级控制平面和节点池，请记录每个集群中控制平面和每个节点池的版本。

检查用户和管理员集群版本

gkectl

• 如需检查用户集群的版本，请执行以下操作：

  gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  将 ADMIN_CLUSTER_KUBECONFIG 替换为您的管理员集群的 kubeconfig 文件的路径。

• 如需查看管理员集群的版本，请执行以下操作：

  gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gcloud CLI

对于在 GKE On-Prem API 中注册的集群，您可以使用 gcloud CLI 获取用户集群、用户集群上的节点池以及管理员集群的版本。

1. 确保您拥有最新版本的 gcloud CLI。根据需要更新 gcloud CLI 组件：

   gcloud components update
   

2. 运行以下命令以检查版本：

• 如需检查用户集群的版本，请执行以下操作：

  gcloud container vmware clusters list \
      --project=PROJECT_ID \
      --location=-

  将 PROJECT_ID 替换为舰队宿主项目的项目 ID。

  设置 --location=- 时，意味着列出所有区域中的所有集群。如果您需要缩小列表范围，请将 --location 设置为您在注册集群时指定的区域。

  该命令的输出包括集群版本。

• 如需查看管理员集群的版本，请执行以下操作：

  gcloud container vmware admin-clusters list \
      --project=PROJECT_ID \
      --location=-

检查集群节点的版本：

您可以使用 kubectl 获取集群节点的版本，但 kubectl 会返回 Kubernetes 版本。如需获取 Kubernetes 版本的相应 Google Distributed Cloud 版本，请参阅版本历史记录。

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

将 USER_CLUSTER_KUBECONFIG 替换为您的用户集群的 kubeconfig 文件的路径。

检查是否需要轮替 CA 证书

在升级期间，叶证书会轮替，但 CA 证书不会。您必须每五年至少手动轮替一次 CA 证书。如需了解详情，请参阅轮替用户集群证书授权机构和轮替管理员集群 CA 证书。

集群类型之间的差异

集群有两种不同类型的集群：

• 用户集群
• 管理员集群

根据您创建用户集群的方式，该集群可能同时包含工作器节点和控制平面节点 (Controlplane V2)，也可能仅包含工作器节点 (kubeception)。使用 kubeception 时，用户集群的控制平面在管理员集群中的一个或多个节点上运行。在这两种情况下，在 1.14 版及更高版本中，您都可以单独升级用户集群的控制平面，与运行工作负载的节点池分开进行升级。

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

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

此过程可能会影响工作负载的可用性，具体取决于工作负载的所选架构。为了避免集群资源功能承受太大压力，Google Distributed Cloud 一次升级了一个节点。

用户集群中断

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

函数	管理员集群	非高可用性用户集群	高可用性用户集群
Kubernetes API 访问权限	不受影响	不受影响	不受影响
用户工作负载	不受影响	不受影响	不受影响
PodDisruptionBudgets^*	不受影响	不受影响	不受影响
控制平面节点	不受影响	受影响	不受影响
Pod 自动扩缩器 (VMware)	不受影响	不受影响	不受影响
自动修复	不受影响	不受影响	不受影响
节点自动扩缩 (VMware)	不受影响	不受影响	不受影响
Pod 横向自动扩缩	受影响	受影响	不受影响

• *：PDB 可能会导致升级失败或停止。
• 受影响：升级期间服务中断明显，直到升级完成。
• 不受影响：服务中断可能在很短的时间内发生，但几乎不明显。

用户集群控制平面节点，无论是在管理员集群 (kubeception) 上运行，还是在用户集群本身 (Controlplane V2) 上运行，都不会运行任何用户工作负载。在升级期间，这些控制平面节点会被排空，然后进行相应更新。

在具有高可用性 (HA) 控制平面的环境中，升级用户集群的控制平面不会中断用户工作负载。在高可用性环境中，升级管理员集群不会中断用户工作负载。对于使用控制平面 V2 的用户集群，仅升级控制平面不会中断用户工作负载。

在非高可用性控制平面环境中升级期间，控制平面无法控制 Pod 伸缩、恢复或部署操作。在升级期间控制平面短暂中断期间，处于伸缩、部署或恢复状态的用户工作负载可能会受到影响。这意味着在非高可用性环境中升级期间，发布将失败。

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

管理员集群中断

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

函数	管理员集群	非高可用性用户集群	高可用性用户集群
Kubernetes API 访问权限	受影响	受影响	不受影响
用户工作负载	不受影响	不受影响	不受影响
控制平面节点	受影响	受影响	不受影响
Pod 自动扩缩器	受影响	受影响	不受影响
自动修复	受影响	受影响	不受影响
节点自动扩缩	受影响	受影响	不受影响
Pod 横向自动扩缩	受影响	受影响	不受影响

• 受影响：升级期间服务中断明显，直到升级完成。
• 不受影响：服务中断可能在很短的时间内发生，但几乎不明显。

后续步骤

• 升级 Anthos clusters on VMware