默认情况下，所有节点池都会并行升级。但在每个节点池中，节点会按顺序升级，因为必须排空并重新创建每个节点。因此，升级所需的总时间取决于最大节点池中的节点数。如需计算升级时间的粗略估算值，请将 15 分钟乘以最大节点池中的节点数。例如，如果最大池中有 10 个节点，则总升级时间大约为 15 * 10 = 150 分钟或 2.5 小时。

您可以通过以下几种方法缩短升级时间，并让您更轻松地规划和安排升级：

在 1.28 版及更高版本中，您可以通过为各个节点池设置 maxSurge 的值来加快升级速度。使用 maxSurge 升级节点时，多个节点会在升级单个节点所需的时间内升级。
如果您的集群为 1.16 版或更高版本，则可以在升级节点池时跳过某个次要版本。执行跳过版本升级可将依序升级节点池两个版本所需的时间缩短一半。此外，跳过版本升级还可以让您在升级之间留出更多时间，以便继续使用受支持的版本。减少升级次数有助于减少工作负载中断和验证时间。如需了解详情，请参阅升级节点池时跳过某个版本。
您可以将用户集群的控制平面与节点池分开升级。这种灵活性有助于您规划多个较短的维护窗口（而不是一个较长的维护窗口）来升级整个集群。如需了解详情，请参阅升级节点池。

备份用户和管理员集群

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

用户集群备份是用户集群的 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 可能发生故障时）。此行为是提供应用可用性的一个实用方法。

如需查看集群中配置的 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 地址块文件中。
- 升级非高可用性管理员集群时，请在管理员集群使用的 IP 地址块文件中添加额外的 IP 地址。您必须在管理员集群配置文件的 network.ipMode.ipBlockFilePath 字段中指定此文件的路径。
- 升级用户集群时，请在用户集群使用的 IP 地址块文件中添加额外的 IP 地址。您必须在用户集群配置文件的 network.ipMode.ipBlockFilePath 字段中指定此文件的路径。
如果您使用 DHCP，请确保新虚拟机在升级期间可获得适用子网中的额外 IP 租期。

如果您需要添加 IP 地址，请更新 IP 块文件，然后运行 gkectl update 命令。如需了解详情，请参阅规划 IP 地址。
如果您使用静态 IP 地址并希望加快用户集群升级过程，请在 IP 地址块文件中列出足够的 IP 地址，以便每个节点池可以有额外的 IP 地址。这种方法可让升级过程加快对虚拟机执行添加和移除步骤，因为它是按节点池执行的。

虽然这种方法是个不错的加快用户集群升级的方案，但在继续之前，请考虑 vSphere 环境的资源和性能可用性。
如果整个用户集群只有一个备用 IP 地址，则此限制会减慢升级过程，一次减慢一个虚拟机，即使使用多个节点池也是如此。

高可用性管理员集群无需 N+1 IP 地址即可进行升级。高可用性管理集群中的三个控制平面节点会逐个重新创建，以确保不需要额外的 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
96GB RAM
虚拟机磁盘空间 + 96GB vSwap

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

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

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

检查集群健康状况和配置

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

gkectl diagnose 命令：gkectl diagnose 可确保所有集群的健康状况良好。该命令会运行高级检查，例如识别未正确配置的节点或者处于卡滞状态的 Pod。如果 gkectl diagnose 命令显示 Cluster unhealthy 警告，请在尝试升级之前解决问题。如需了解详情，请参阅诊断集群问题。
升级前工具：除了检查集群健康状况和配置之外，升级前工具还会检查集群升级期间可能发生的潜在已知问题。

此外，如果您将用户集群升级到 1.29 及更高版本，我们建议您在运行 gkectl upgrade cluster 命令时使用 --dry-run 标志。--dry-run 标志会运行预检检查，但不会启动升级过程。虽然早期版本的 Google Distributed Cloud 会运行预检检查，但它们无法与升级分开运行。通过添加 --dry-run 标志，您可以在升级之前发现并解决预检检查在用户集群中发现的任何问题。

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

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

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

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

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

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

为了提高服务可用性（即对 Kubernetes API 服务器而言），我们建议您始终在管理员集群前面使用高可用性对。如需详细了解 Seesaw 及其高可用性配置，请参阅 1.16 版文档使用 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 获取用户集群、用户集群中的节点池和管理员集群的版本。

确保您拥有最新版本的 gcloud CLI。根据需要更新 gcloud CLI 组件：
```
gcloud components update
```
运行以下命令以检查版本：

如需检查用户集群的版本，请运行以下命令：
```
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) 控制平面的环境中，升级用户集群的控制平面不会中断用户工作负载。在高可用性环境中，升级管理员集群不会中断用户工作负载。对于使用 Controlplane V2 的用户集群，仅升级控制平面不会中断用户工作负载。

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

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

管理员集群中断

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

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

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

后续步骤

升级集群或节点池

Google Distributed Cloud 集群升级的最佳实践

升级核对清单

规划升级

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