集群升级

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

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

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

集群先于其节点升级。

集群升级

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

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

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

如果您配置了维护时段或排除选项,我们会尽可能遵守。

节点池升级

您的集群与节点池不一定运行相同版本的 GKE。本节讨论了通过 Google 自动升级节点池或手动升级节点池的不同预期结果。

一次只能升级一个节点池。在节点池中,节点升级的顺序不确定,且一次只能升级一个节点。您可以更改一次能升级的节点数量

此过程可能需要几个小时,具体取决于节点数量及其工作负载配置。可能会减慢节点升级速度的配置包括:

如果您配置了维护时段或排除选项,我们会尽可能遵守。

当某个节点升级时,会出现以下情况:

  1. 如果已启用超额配置升级,则 GKE 会使用升级后的版本创建新的超额配置节点,并等待其向控制层面注册。
  2. GKE 会选择现有节点(我们称之为目标节点)来进行升级。它会封锁并开始排空目标节点。此时,GKE 无法在目标节点上调度新的 Pod。
  3. 该目标节点上的 Pod 会被重新调度到其他节点上。如果无法重新调度 Pod,则该 Pod 会保持 PENDING 状态,直到可以重新调度为止。
  4. 如果在第 1 步中创建了超额配置节点,则系统会删除目标节点。如果未创建超额配置节点,则 GKE 会升级目标节点,然后等待该节点注册。
  5. 如果大量节点在自动升级到某个给定版本时导致 GKE 机群中出现运行状况不佳的节点,则在调查该问题时将停止升级到该版本。

自动升级

当您使用 Google Cloud Console 创建集群时,默认情况下集群及其节点池会启用自动升级;当为新的 GKE 版本选择自动升级时,Google 会升级您的集群。

使用 gcloud 命令或 GKE API 创建集群时,默认情况下会启用节点自动升级。要手动将其停用,请参阅自动升级节点

如需要更好地控制何时可以(或不得)进行自动升级,您可以配置维护时段和排除选项

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

如果您将集群加入发布版本,节点始终与集群本身运行相同版本的 GKE,除了在完成集群的控制平面升级和开始升级给定节点池之间的短暂时间。

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

新的 GKE 版本将定期发布,但不会立即选为可自动升级的版本。当 GKE 版本积累了足够的集群用量,证明能够长期稳定运行后,Google 才会将其选为可自动升级的版本,用于升级运行旧版本子集的集群。

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

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

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

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

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

默认情况下,系统可以随时进行自动升级。自动升级带来的干扰非常小,尤其是对于区域级集群而言。但是,某些工作负载可能需要更为精细的控制。您可以通过配置维护时段和排除选项来管理可以自动升级和禁止自动升级的时间。

手动升级

您可以随时请求手动将您的集群或其节点池升级到可用且兼容的版本。手动升级会忽略所有已配置的维护时段和维护排除选项。

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

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

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

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

超额配置升级

借助超额配置升级,您可以控制 GKE 能够同时升级的节点数以及中断性升级对工作负载的影响。

更改升级设置以平衡升级速度和运行中断

通过更改节点池的超额配置升级参数,您可以更改 GKE 尝试同时升级的节点数。超额配置升级可以降低集群维护期内工作负载的中断,还可以控制并行升级的节点数量。超额配置升级还可用于集群自动扩缩器,以防止系统对正在升级的节点进行更改。

超额配置升级行为通过以下两项设置决定:

max-surge-upgrade

可在升级过程中添加到节点池中的额外节点数量。增加 max-surge-upgrade 会提升可同时升级的节点数量。默认为 1。 可以设置为 0 或更高。

max-unavailable-upgrade

升级期间同时不可用的节点数量。默认为 0。增加 max-unavailable-upgrade 会提升可以并行升级的节点数量。

同时升级的节点数是 max-surge-upgrademax-unavailable-upgrade 之和。同时升级的节点数量上限为 20

例如,创建 5 节点池,其中 max-surge-upgrade 设置为 2,max-unavailable-upgrade 设置为 1。在节点池升级过程中,GKE 会创建两个已升级的节点。在已升级的节点准备就绪后,GKE 最多可以减少三个(max-surge-upgrademax-unavailable-upgrade 的总量)现有节点。GKE 一次最多只能有一个节点不可用(max-unavailable-upgrade)。 在升级过程中,节点池将包含四到七个节点。

您可以为使用自动升级手动升级的节点池配置关于超额配置升级的参数。您可以通过完成使用超额配置升级来减少 GKE 节点升级所导致的中断次数教程,详细了解并试用超额配置升级。

确定最佳超额配置

下表介绍了三种不同的升级设置,以帮助您了解不同的配置:

说明 配置
平衡(默认),速度较慢,但中断次数最少 maxSurge=1 maxUnavailable=0
快速、无超额配置资源、中断次数最多 maxSurge=0 maxUnavailable=20
快速、超额配置资源最多、中断次数较少 maxSurge=20 maxUnavailable=0

平衡(默认)

如需利用超额配置升级,最简单的方法是配置 maxSurge=1 maxUnavailable=0.。这意味着升级期间只能将 1 个超额配置节点添加到节点池,因此一次只能升级 1 个节点。此设置优于现有的升级配置 (maxSurge=0 maxUnavailable=1),因为它可以在升级期间加快 Pod 重启的速度,同时以保守的方式进行升级。

快速、无超额配置资源

如果您的工作负载对中断不敏感(就像大多数批量作业一样),则您可以使用 maxSurge=0 maxUnavailable=20 来加快速度。此配置不会产生额外的超额配置节点,并且允许系统同时升级 20 个节点。

快速、中断次数较少

如果您的工作负载对中断很敏感,并且您已经设置了 PodDisruptionBudgets (PDB),而且您没有使用 externalTrafficPolicy: Local(它不使用并行节点排空),则您可以使用 maxSurge=20 maxUnavailable=0 加快升级的速度。此配置可以并行升级 20 个节点,而 PDB 会限制在给定时间可排空的 Pod 数量。虽然 PDB 的配置可能会有所不同,但如果您使用 maxUnavailable: 1 为节点池上运行的一个或多个工作负载创建 PDB,则系统一次只能逐出这些工作负载的一个 Pod,从而限制整个升级的并行性。

与配额的关系

重新创建节点时不需要额外的 Compute Engine 资源,但超额配置升级节点需要额外的 Compute Engine 资源。资源分配受 Compute Engine 配额限制。根据您的配置,此配额可能会限制并行升级的数量,甚至可能导致升级失败。

如需详细了解配额,请参阅节点升级和配额

接收升级通知

GKE 将升级通知发布到 Pub/Sub,为您提供了一个渠道,接收来自 GKE 的关于您的集群的信息。

如需了解详情,请参阅接收集群升级通知

后续步骤