标准集群升级

本文档讨论了自动和手动升级功能在 Google Kubernetes Engine (GKE) Standard 集群上的工作原理，包括指向相关任务和设置的详细信息链接。您可以使用这些信息对集群进行更新，以确保其稳定性和安全性，同时最大程度减少对工作负载的中断。

如需大致了解集群升级，请参阅 GKE 集群升级概览。如需了解集群升级对 AutoPilot 集群的特定支持，请参阅 Autopilot 集群升级。

集群和节点池升级运行原理

本部分介绍了在自动或手动升级期间集群中发生的情况。如果是自动升级，则该升级由 GKE 启动。GKE 会观察所有 GKE 集群的自动升级和手动升级情况，并在出现问题时进行干预。

为了升级集群，GKE 会更新控制平面和节点正在运行的版本。集群会升级到较新的次要版本（例如 1.24 到 1.25）或较新的补丁版本（例如 1.24.2-gke.100 到 1.24.5-gke.200）。如需了解详情，请参阅 GKE 版本控制和支持。

如果您将集群加入发布版本，则节点会运行与集群相同的 GKE 版本，但除了在完成集群的控制平面升级和开始升级给定节点池之间的短暂时间（通常为数天，具体取决于当前发布版本）内或者手动升级控制平面。如需了解详情，请参阅版本说明。

集群升级

本节讨论了通过 GKE 自动升级集群与手动升级集群的不同预期结果。

  • 地区级集群只有一个控制平面。在升级期间，您的工作负载会继续运行，但直到升级完成前，您都无法部署新的工作负载，也无法修改现有工作负载或对集群的配置进行其他更改。

  • 区域集群有多个控制平面副本，并且一次只能升级一个副本，顺序不确定。在升级过程中，集群保持高可用性，并且每个控制平面副本仅在升级时不可用。

如果您配置了维护窗口或排除选项，我们会尽可能遵守。

节点池升级

本节讨论了通过 GKE 自动升级节点池或手动升级节点池的不同预期结果。 此信息与 Standard 节点池和 Autopilot 管理的 节点池均相关。

默认情况下，GKE 会自动一次升级集群中的一个节点池。为了缩短具有多个节点 池的集群的总体升级时间，您可以 配置并发节点池升级 （预览版），让 GKE 自动同时升级多个节点池。 或者，您可以手动并行升级一个或多个节点池。默认情况下，节点池中的节点按任意顺序一次升级一个。在分布在多个 可用区的节点池中，升级 按可用区进行。在一个可用区中，节点将按不确定的顺序升级。

进行 GKE Standard 节点池升级时，您可以选择以下节点升级策略：

  • 超额配置升级
  • 蓝绿升级
  • 自动扩缩的蓝绿升级（预览版）

对于每种节点升级策略，您都可以根据集群环境的需求调整升级过程。Standard 集群中由 Autopilot 管理的节点池始终使用超额配置升级，您无法修改该策略的配置或其设置。

在节点池升级过程中，除非取消升级，否则无法更改集群配置。

GKE 会尽量在自动升级期间遵循维护窗口和排除项。手动升级会忽略您配置的维护期和排除项。

节点升级方式

在节点池升级过程中，节点的升级方式取决于节点池升级策略以及配置方式（如可能）。但是，基本步骤是一致的。为了升级节点，GKE 会从节点中移除 Pod，以便可以升级 Pod。

升级节点时，Pod 会发生以下情况：

  1. 该节点会被封锁，因此 Kubernetes 不会在其上安排新的 Pod。
  2. 然后，节点会被排空，这意味着 Pod 会被移除。对于超额配置升级，GKE 遵循 Pod 的 PodDisruptionBudget 和 GracefulTerminationPeriod 设置，时间最长可达一小时。使用蓝绿升级时，如果您配置更长的过渡时间，则可以进行扩展。
  3. 控制平面会将控制器管理的 Pod 重新调度到其他节点上。无法重新安排的 Pod 将保持待处理状态，直到可以重新安排为止。

节点池升级过程可能需要几个小时，具体取决于升级策略、节点数量及其工作负载配置。

影响节点升级时长的注意事项

可能导致节点升级需要更长时间才能完成的配置包括：

节点升级策略

GKE 提供了内置的可配置策略，用于确定节点池的升级方式。 如需详细了解使用节点升级策略的更改类型，请参阅以下内容：

超额配置升级

默认情况下，超额配置升级策略用于节点池升级。此策略始终用于 Autopilot 管理的节点池。超额配置升级使用滚动方法升级节点。此策略最适合可处理增量非中断性更改的应用。使用此策略时，节点在滚动窗口中升级。对于 Standard 节点池，您可以更改一次可以升级的节点数量以及升级的中断情况等设置，找到最佳速度和中断环境需求之间的平衡。

蓝绿升级

对于 Standard 节点池，另一种方法是蓝绿升级，即同时维护两组环境（原始环境和新环境），从而尽可能轻松回滚。蓝绿资源更多，并且对变化更敏感的应用性能更好。使用此策略时，工作负载会从原始“蓝部署”环境逐步迁移到新的“绿部署”环境，并留出过渡时间，以使用新配置验证工作负载。如果需要，工作负载可以快速回滚到现有的“蓝色”环境。

如需详细了解节点升级策略的工作原理，请参阅节点 升级 策略。

自动扩缩的蓝绿升级

自动扩缩的蓝绿 升级 （预览版）是一种节点 升级策略，可让工作负载运行更长时间，同时最大限度地降低因节点闲置或未充分利用而产生的费用。

节点升级策略的资源要求

超额配置升级会创建额外的节点（如果 maxSurge 设置为大于 0），并且蓝绿升级会暂时将节点池中的节点数量加倍。这需要额外的资源，具体取决于 Compute Engine 配额、资源可用性和预留容量。如果您的节点池没有足够的资源，升级可能需要更长时间或失败。

如需详细了解如何确保您的项目有足够的资源用于 节点升级，以及如果您的环境资源有限该怎么办，请参阅 确保节点 升级资源。

自动升级

创建标准集群时，默认情况下，集群及其节点池会启用自动升级。

GKE 负责保护集群的控制平面，并在新的 GKE 版本选为可自动升级版本时升级集群。基础架构安全性对于 GKE 而言具有较高的优先级，因此，控制平面会定期升级，并且无法停用。不过，您可以通过使用维护 窗口和排除项来临时暂停控制平面的升级。

在 GKE 责任共担 模型中，您 负责保护节点、容器和 Pod 的安全。默认情况下，节点自动升级处于 启用状态，您可以使用维护窗口和 排除项来控制何时可以或不能进行自动升级 。如果您阻止节点自动升级，则需要负责确保 集群的节点所运行的版本与控制平面的版本兼容， 并且版本符合 GKE 版本偏差 政策。无论您的 集群设置如何，GKE 都会在支持终止时执行 自动升级 。

为保持与集群 API 的兼容性，集群的节点池不能低于控制平面两个次要版本。节点池版本还决定了在每个节点上安装的软件包的版本。 建议将节点池更新为集群版本。

如果您让集群加入发布 渠道，节点通常会运行 与集群本身相同的 GKE 版本，但除了在 完成集群的控制平面升级和开始升级给定 节点池之间的短暂时间（通常为数天，具体取决于当前发布版本）。如需了解详情，请参阅版本说明。

如何选择版本进行自动升级

新的 GKE 版本将定期发布，但不会立即选为可自动升级的版本。当 GKE 版本积累了足够的集群用量，证明能够长期稳定运行后，GKE 才会将其选为可自动升级的版本，用于升级运行旧版本子集的集群。 如需获取特定集群的自动升级目标，请参阅获取有关集群升级的信息。

新的自动升级目标会在版本说明中进行公布。若新版本还未选为可自动升级版本，您可以手动升级到该版本。有时，系统会在不同的星期内为集群自动升级和节点自动升级选择一个版本。

当新的次要版本普及后，通常不再对最旧的可用次要版本提供支持。当集群运行这些不受支持的次要版本时，会自动升级到下一个次要版本。

在次要版本（例如 v1.14.x）中，集群可自动升级到新的补丁版本。

发布版本允许您根据版本的稳定性对集群和节点池的版本进行控制，而非直接管理。

影响版本发布时间的因素

为了帮助确保新版本上集群的稳定性和可靠性，GKE 在版本发布期间遵循某些做法。

这些做法包括但不限于：

  • GKE 会逐步跨 Google Cloud区域和可用区发布更改。
  • GKE 会逐步跨发布渠道发布补丁版本。补丁会依次在快速发布渠道和常规发布渠道中留出过渡时间，等到积累了一些使用情况并继续保持稳定后再推广到稳定发布渠道。如果在发布渠道的过渡期间发现补丁版本存在问题，则该版本不会推广到下一个渠道，并且较新的补丁版本会修复该问题。
  • GKE 会逐步发布次要版本，并执行与补丁版本类似的过渡流程。由于次要版本涉及更多重大更改，因此会有更长的过渡期。
  • 当新版本影响一组集群时，GKE 可能会延迟自动升级。例如，对于检测到使用下一个次要版本将移除的已弃用 API 或功能的集群，GKE 会暂停自动升级。
  • GKE 可能会在峰值期间（例如主要节假日）延迟发布新版本，以确保业务连续性。

配置可以进行系统自动升级的时间

默认情况下，为了保障基础架构安全，自动升级可能随时发生。自动升级带来的干扰非常小，尤其是对于区域级集群而言。但是，某些工作负载可能需要更为精细的控制。您可以通过配置维护窗口和排除选项来管理可以自动升级和禁止自动升级的时间。

手动升级

您可以随时请求手动将集群的控制平面或其节点池升级到可用且兼容的版本。在 Standard 集群中，您可以手动升级 Standard 节点池和由 Autopilot 管理的节点池。手动升级会忽略所有已配置的维护时段和维护排除选项。

如果您手动升级集群，其可用性取决于集群是否为区域级集群：

  • 对于区域级集群，控制平面在升级时不可用。工作负载大部分运行正常，但在升级过程中无法修改。

  • 对于区域级集群，其控制平面的副本在升级时不可用，但集群在升级期间可保持高可用性。

您可以手动启动节点升级，将其升级到与控制平面兼容的版本。

GKE 如何响应自动升级失败

由于底层 Compute Engine 实例的问题或 Kubernetes 的问题，节点池自动升级可能会失败。例如，自动升级在以下情况下会失败：

  • 您配置的 maxSurge 设置超出了 Compute Engine 资源配额。
  • 新的超额配置节点未向集群控制平面注册。
  • 节点排空时间过长，或删除时间过长。

如果单个节点升级出现问题，GKE 会多次重试，且升级之间的间隔会不断增加。如果节点池中的节点升级失败，则 GKE 不会回滚已升级的节点。相反，GKE 会尝试再次自动升级节点池，直到所有节点都成功升级。

如果由于超额配置节点请求超出 Compute Engine 配额而导致节点升级失败，GKE 会减少并发超额配置节点数以尝试达到配额并继续升级。

接收升级通知

GKE 会将与您的集群相关的事件（例如版本升级和安全公告）通知发布到 Pub/Sub，这为您提供了一个渠道，让您可以接收 GKE 发布、与您的集群相关的信息。

如需了解详情，请参阅接收集群通知。

检查升级日志

默认情况下，GKE 日志控制平面和节点池会将事件升级到 Cloud Logging。升级事件日志可帮助您了解升级过程，并在需要时提供有价值的信息以进行问题排查。

控制平面升级日志

您可以使用以下过滤条件查询集群升级事件：

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

这些日志以结构化日志记录格式记录。您可以使用以下字段来详细了解升级事件：

字段 说明
protoPayload.metadata.operationType

集群升级事件有两种类型：

  • UPGRADE_MASTER：升级到 Kubernetes 控制平面版本。
  • UPDATE_CLUSTER：更新，不会更改 Kubernetes 控制平面版本。

这两种集群升级类型都可能导致可用区级集群无法使用控制平面。如需了解详情，请参阅集群和节点池升级运行原理。
protoPayload.methodName

此字段显示哪个 API 触发了集群升级。

  • google.container.v1.ClusterManager.UpdateCluster：手动控制平面升级
  • google.container.internal.ClusterManagerInternal.UpdateClusterInternal：自动控制平面升级
  • google.container.v1.ClusterManager.PatchCluster：集群配置更改
protoPayload.metadata.previousMasterVersion 此字段仅用于 MASTER_UPGRADE 操作类型，包含升级前使用的先前控制平面版本。
protoPayload.metadata.currentMasterVersion 此字段仅用于 MASTER_UPGRADE 操作类型，包含升级后使用的新控制平面版本号。

节点池升级日志

使用以下查询可查看节点池升级事件：

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

使用以下字段可详细了解升级事件：

protoPayload.methodName 字段显示升级是手动触发还是自动触发，如下所示。

组件升级

GKE 在工作器节点上运行系统工作负载，以支持集群的特定功能。例如，gke-metadata-server 系统工作负载支持适用于 GKE 的工作负载身份联合。 GKE 负责这些工作负载的健康状况。如需详细了解这些组件，请参阅关联功能的文档。

当组件的新功能或修复可用时，GKE 会指示包含它们的补丁程序版本。如需获取组件的最新版本，请参阅关联文档或版本说明，了解有关将控制平面或节点升级到相应版本的说明。

后续步骤