GKE 集群升级的最佳实践

本文档为平台管理员提供了有关管理 Google Kubernetes Engine (GKE) 集群升级的最佳实践。默认情况下,GKE 会自动升级集群的控制平面和节点的版本,以提供新功能、bug 修复和安全补丁,从而确保环境保持高性能和安全性。

为确保这些自动升级符合您的运营需求并最大限度减少工作负载中断,GKE 提供了一些工具,以便您能够最大限度地控制升级。本指南介绍了如何有效使用这些工具来保持高性能和高可用性。如需了解基础知识,请参阅 GKE 集群升级概览

除了集群升级(仅更新控制平面和节点的 GKE 版本)之外,GKE 还会定期对集群执行其他更新。实施本文档中的最佳实践有助于为应对其中一些类型的变化做好准备。如需了解详情,请参阅管理集群生命周期更改,以最大限度地减少中断

如需全面了解所有 GKE 最佳实践,请参阅 GKE 最佳实践

核对清单

下表总结了以下部分中详细说明的任务。建议您在为集群升级准备环境时执行这些任务。

最佳做法 Tasks
通过发布渠道,在功能速度和升级稳定性之间选择平衡点
使用维护政策选择升级时间
控制跨集群的升级发布
控制升级的触发方式
监控集群升级
在节点升级期间最大限度地减少对现有工作负载的干扰

通过发布渠道,在功能速度和升级稳定性之间选择平衡点

借助发布渠道,您可以在功能更新速度和升级稳定性之间取得平衡。默认情况下,GKE 集群会在常规发布渠道中注册。当 GKE 升级集群的控制平面和节点以提供安全补丁、修复已知问题和引入新功能时,发布渠道会决定集群运行的 GKE 版本。例如,如果您希望尽快获得新功能,可以选择快速渠道;如果您希望获得稳定性更高的版本,可以选择稳定渠道。如需详细了解如何在特定渠道之间进行选择,请参阅有哪些渠道可供选择

如果您想手动升级集群,仍可通过以下方式受益于选择发布渠道:在选择新版本之前,查看该渠道的可用版本和自动升级目标。

此外,如果您希望尽快获取发布渠道中的补丁版本(例如,为了接收关键安全补丁),请参阅关于提前获取补丁版本

选择您需要为次要版本提供多少支持

在常规渠道中使次要版本可供使用后,GKE 会总共提供长达 24 个月的支持。此支持包括 14 个月的标准支持,以及大约 10 个月的延长支持(通过扩展渠道提供)。如需详细了解 GKE 如何支持次要版本,请参阅次要版本支持

如果您需要让集群在更长时间内使用某个次要版本,同时在标准支持服务终止日期之后仍能收到安全补丁,或者您想阻止标准支持服务终止强制执行,也可以使用扩展渠道。如需了解详情,请参阅下文中的在需要长期支持时使用扩展渠道部分。

当次要版本达到支持终止日期时,GKE 会自动升级您的集群,以帮助确保集群保持高效和安全,具体取决于集群注册的发布渠道。如需了解详情,请参阅自动升级节点以实现安全性和兼容性。 如果您使用本文档中所述的工具来阻止或延迟自动集群升级,我们建议您在集群运行的次要版本达到支持结束日期之前手动升级集群。否则,GKE 会自动升级您的集群。

使用维护政策选择升级时间

如需控制何时可以升级以及何时不可以升级,请使用以下功能:

  • 维护窗口:选择 GKE 可以升级集群的周期性时间段,例如非高峰营业时间。如果升级过程在维护窗口之外运行,GKE 会尝试暂停操作,并在下一个维护窗口恢复操作。
  • 维护排除项:选择一个特定时间段,在此期间 GKE 无法升级您的集群,例如零售业务的主要促销活动期间。您还可以使用维护排除项来暂时推迟集群的自动升级,例如,当您发现其他集群升级到新版本时出现问题时,可以这样做。
    • 对于高级使用情形,您可能需要手动执行某些类型的升级,而不是由 GKE 执行。您可以使用维护排除项来停用这些类型的自动升级。例如,您可以使用“无次要升级或节点升级”范围来停用所有次要升级和所有节点升级。您必须自行手动执行这些升级,否则 GKE 会在相应次要版本的支持终止时升级您的集群。
  • 维护频率:对于高级使用情形,您可以使用集群中断预算来控制两次连续自动升级之间的最短间隔。

通过配置维护政策,您可以提高升级的可预测性,并确保在最适合工作负载的时间进行升级。

控制跨集群的升级发布

我们建议您使用多个环境,将软件和基础架构变更与生产环境分开进行测试,从而最大限度地降低风险和减少不必要的停机时间。我们建议您至少拥有一个生产环境和一个生产前或测试环境。

请考虑以下推荐的环境:

环境 说明
生产 为任务关键型业务应用的最终用户提供实时流量。
Canary 版 在升级所有集群之前,先测试小部分生产环境。
预演 确保从之前环境部署的所有新更改在部署到生产环境之前按预期正常工作。
测试 使用您将在生产环境中使用的 GKE 版本对工作负载执行基准测试、测试和质量保证 (QA)。
开发 使用生产环境中运行的相同版本进行积极开发。在此环境中,您可以创建要在生产环境中部署的修复和增量更改。

GKE 提供发布序列等功能,可帮助您控制如何在这些不同环境中部署升级,详情请参阅下文。

使用发布序列跨环境发布

为了在这些环境中逐步推出新的 GKE 版本,我们建议您使用推出序列。借助发布序列,所有集群在整个部署阶段都使用相同的发布渠道和次要版本。GKE 会按照您配置的顺序逐步发布新版本。当 GKE 在您的环境中推出新版本时,您可以验证集群环境和工作负载是否在新版本下按预期运行。

如果您要配置新环境,请使用具有自定义阶段的发布序列(预览版)。借助这种新版发布序列,您可以分多个阶段将新版本发布到集群组。采用此方法后,GKE 可以先升级生产环境中的 Canary 环境,然后再升级其余生产环境。或者,如需了解该功能的正式版(使用不含自定义阶段的更线性化的模型),请参阅关于使用发布序列进行集群升级

测试 GKE 补丁程序升级和次要版本升级

GKE 会每周自动将集群升级到新的补丁版本。不过,次要版本升级大约每年仅进行三次。与同一 Kubernetes 次要版本的补丁相比,新的 Kubernetes 次要版本会引入更多更改。我们建议您在各个环境中发布次要版本升级时,进行更严格的检查,以确保新的次要版本能够按预期方式与集群和工作负载搭配使用。

在升级集群之前执行检查

在执行自动集群升级之前,GKE 会对新版本进行资格认证(时间长短取决于发布渠道),并检查集群的就绪情况。

在升级集群之前,我们建议您执行以下操作:

  • 对于所有升级(包括补丁升级和次要升级):
    • 查看 GKE 版本说明,了解问题并查找新的次要版本和补丁版本的更改日志。
    • 查看 GKE 已知问题,了解与您的集群环境和新版本相关的任何问题。
  • 对于次要升级,请额外查看以下内容:
    • 查看 API 弃用情况。如需了解详情,请参阅新版本的 GKE 版本说明、Kubernetes 更改日志以及功能和 API 弃用
    • 确保控制平面与节点之间的版本偏差受支持。GKE 支持运行比控制平面低两个次要版本的节点。如需了解详情,请参阅 GKE 版本偏差政策
  • 对于节点升级:

控制升级的触发方式

默认情况下,GKE 会定期自动将集群升级到新版本。不过,您也可以使用手动升级功能,在需要时升级集群,并控制集群运行的版本。

您可以执行以下操作:

  • 手动升级集群。
  • 针对正在进行的自动或手动节点升级执行操作,包括以下操作:

    • 取消升级。
    • 恢复升级。
    • 回滚升级。
    • 完成正在进行的升级。

如果您想更好地控制升级过程,建议您配置维护排除项,然后根据需要执行手动升级。如需详细了解手动升级以及您可以针对正在进行的升级采取的其他操作,请参阅手动升级集群或节点池

监控集群升级

为确保 GKE 升级按预期进行,并确保集群环境保持高性能和可用性,请使用以下工具监控集群升级。为了及时了解集群的状态,请使用通知、数据洞见和建议以及日志等工具。我们特别建议您留意支持结束通知、升级开始通知,以及针对次要版本升级的自选预定升级通知。设置提醒政策,以确保您会收到这些通知。

通过以下资源可获取有关当前升级的详细信息:

在节点升级期间最大限度地减少对现有工作负载的干扰

除了前几部分中介绍的一般最佳实践之外,我们还建议您考虑其他高级配置,以进一步自定义升级流程,使其适合您的集群环境和工作负载需求。

针对特定工作负载配置的其他注意事项

某些类型的工作负载和集群环境需要为集群升级做好额外准备。如果您的工作负载符合以下一个或多个类别,请考虑以下额外注意事项:

  • 在不进行实时迁移的机器上运行的工作负载:GKE 节点是 GKE 代表您创建的 Compute Engine 实例,需要定期对底层基础设施进行维护。大多数 Compute Engine 实例都可以实时迁移,这意味着在进行此类维护时,正在运行的工作负载不会中断。不过,某些机器类型无法实时迁移,这意味着在 GKE 节点上运行的工作负载可能会中断。至关重要的是,加速器(例如用于 AI/机器学习工作负载的 GPU 和 TPU)无法实时迁移。如需了解详情,请参阅管理无法实时迁移的 GKE 节点的中断
  • 受容量限制的工作负载:如果您的工作负载使用的机器类型受容量限制,则在执行集群升级时需要考虑其他因素。如需了解详情,请参阅确保用于节点升级的资源
  • 有状态工作负载:如果您的工作负载是有状态的,并且对正常关闭和重启有特定要求,那么在执行集群升级时需要额外考虑。如需了解详情,请参阅确保工作负载已准备好应对中断

请查看以下各部分,了解如何使用可用工具来升级这些类型的工作负载。

选择节点升级策略

在 GKE Standard 模式下,GKE 提供了不同的节点升级策略,用于确定节点池中各个节点的升级方式。通过为 Standard 节点池选择升级策略,您可以选择在速度、工作负载中断、风险缓释和费用优化之间取得适当平衡的流程。您还可以配置策略的参数,以最大限度满足您的需求。在 GKE Autopilot 模式下,GKE 会管理节点升级,您无需选择所用的具体策略。如需了解详情,请参阅节点升级策略简介

设置中断容忍度

使用 Pod 中断预算 (PDB) 有助于确保在升级期间 GKE 重新创建节点时(这可能会暂时减少工作负载的副本数量),工作负载仍能保持足够的冗余。

如果设置了 PDB,如果 Pod 的数量等于或小于配置的限制,GKE 将不会关停应用中的 Pod。GKE 升级遵循 PDB 的最长时间为 60 分钟。此外,如果节点排空因 PDB 而受阻,或者 PDB 超时且 Pod 将被强制删除(即使违反了 PDB),GKE 也会通知您。如需了解详情,请参阅节点池升级期间的中断性事件

使用正常终止来关闭应用

您可以配置正常终止,以确保工作负载有足够的时间为关停做好准备。在节点升级期间,GKE 会遵循正常终止设置,在默认的超额配置升级中最多遵循 60 分钟,在蓝绿升级自动扩缩的蓝绿升级预览版)中最多遵循 24 小时。

如需详细了解如何配置正常终止设置,请参阅配置 GKE 以正常终止工作负载

如果您需要长期支持,请使用扩展渠道

如果您希望集群使用某个次要版本的时间更长,请遵循最佳实践,在扩展渠道中注册集群。通过此渠道,GKE 对次要版本的支持期约为 24 个月。借助扩展渠道,您可以控制次要版本升级,只有在您未自行发起升级的情况下,GKE 才会在支持终止时自动升级。如需了解详情,请参阅通过扩展渠道获取长期支持

如果您不需要在次要版本上停留的时间超过售后支持期限,但仍想控制次要版本升级,请改用范围为“无次要升级”的维护排除项

为充分利用该渠道,建议您遵循以下最佳实践。其中一些最佳实践需要采取一些人工处置措施,包括手动升级集群更改集群的发布渠道。请查看以下支持的场景以及何时不使用扩展渠道

暂时在一段较长时间内继续使用次要版本

如果您需要暂时将集群保留在某个次要版本上,但时间超过 14 个月的标准售后支持期限,例如为了缓解使用下一个次要版本中移除的已弃用 API 的问题,请按以下流程操作。您可以暂时将集群从其他发布渠道移至扩展渠道,以便在准备升级到下一个次要版本的同时继续接收安全补丁。当您准备好升级到下一个次要版本时,可以手动升级集群,然后将集群移回原始发布渠道。

每年升级一次或两次次要版本

如果您希望在集群准备好升级到新的次要版本时,尽量减少对集群的干扰,同时仍能获得一些新功能,请执行以下操作:

  • 在扩展渠道中注册集群。
  • 每年执行一到两次连续的次要版本升级。例如,从 1.33 升级到 1.34,再升级到 1.35。

此流程有助于确保集群始终使用可用的次要版本,接收来自新次要版本的功能,但仅在您确定集群已准备就绪时才接收次要版本升级。

何时不使用扩展渠道

若要按预期用途使用扩展渠道,需要人工处置措施。以下场景说明了在不主动管理集群的次要版本的情况下使用扩展渠道的后果。

不采取任何措施,并按相同的频率接收次要升级

如果您想让集群永久使用某个次要版本,请在扩展渠道中注册集群,然后无需执行任何进一步操作。所有次要版本最终都会不受支持,并且 GKE 会自动将集群从不受支持的次要版本升级。因此,GKE 会将此集群从一个不受支持的次要版本升级到另一个即将不受支持的次要版本,平均大约每四个月升级一次。 此方法意味着,集群接收次要版本升级的频率与其他发布渠道相同,但接收新功能的时间较晚。

后续步骤