升级集群的最佳做法

本页面提供有关保持 Google Kubernetes Engine (GKE) 集群无缝更新的指南，以及创建符合您需求并可提高环境可用性和可靠性的升级策略的建议。您可以使用这些信息对集群进行更新，以确保其稳定性和安全性，同时最大程度减少对工作负载的中断。

或者，如需管理使用舰队组织的生产环境中的自动集群升级，请参阅关于使用发布顺序的集群升级。

设置多个环境

我们建议您在提供软件更新的工作流中使用多个环境。利用多个环境，您可将软件测试和基础架构更新与生产环境分开，从而帮助您最大限度地降低风险和减少不必要的停机时间。您至少应拥有一个生产环境和一个生产前或测试环境。

请考虑以下推荐的环境：

环境 说明
生产环境 用于为任务关键型应用的最终用户提供实时流量。
预演 用于确保从之前环境部署的所有新更改在部署到生产环境之前按预期正常工作。
测试 用于对您将在生产中使用的 GKE 版本执行基准测试、测试和质量检查工作负载。在此环境中，您可以在生产环境中升级控制平面和节点之前对升级进行测试。
开发 用于对生产环境中运行的相同版本进行积极开发。在此环境中，您可以创建要在生产环境中部署的修复和增量更改。
Canary 版 用作测试较新的 Kubernetes 版本、GKE 功能和 API 的辅助开发环境，一旦这些版本提升并变为默认版本，即可缩短上市时间。

在发布渠道中注册集群

Kubernetes 经常发布更新，以提供安全更新、解决已知问题以及推出新功能。GKE 发布渠道让您能够平衡集群中所部署版本的稳定性和功能集。当您在发布渠道中注册新集群时，Google 会自动管理集群及其节点池的版本和升级频率。

以下是一些推荐的环境以及集群应注册的相应发布渠道，可使集群与最新的 GKE 和 Kubernetes 更新保持同步：

环境 发布渠道 说明
生产环境 稳定或常规 如需保证稳定性和版本成熟度，请为生产工作负载使用稳定或常规渠道。
预演 与生产环境相同 如需确保测试代表生产环境将升级到的版本，请使用与生产环境相同的发布渠道。
测试
开发
Canary 版 快速 如需测试最新的 Kubernetes 版本并通过测试新的 GKE 功能或 API 领先一步，请使用快速渠道。当快速渠道中的版本提升到用于生产环境的渠道，则可缩短上市时间。
不适用 扩展 如需在标准支持服务期结束后继续使用次要版本，同时仍可接收安全补丁，请使用扩展渠道。如需了解详情，请参阅在需要长期支持时使用扩展渠道。

无论您的集群是否已注册发布版本，集群控制层面都会始终定期升级。

创建持续升级策略

在发布渠道中注册集群后，该集群会定期升级到符合该渠道质量和稳定性标准的版本。这些更新包括安全和问题修复，每个渠道对应用更新的审核严格程度递增：

  • 补丁会被逐步推送到所有渠道中的控制平面和节点，即在快速和常规渠道中累积预备时间，然后再进入稳定渠道。
  • 控制平面会先升级，然后是节点，以符合 Kubernetes OSS 政策，即 kubelet 不得高于 kube-apiserver。
  • GKE 会根据关键性和重要性自动向渠道发布补丁程序。
  • 稳定渠道仅接收重要补丁程序。

接收有关新 GKE 版本的更新

新版本的相关信息会发布到 GKE 版本说明主页面以及 RSS Feed。每个发布渠道都有一个专门的简化版本说明页面（例如：稳定渠道的版本说明），其中提供该渠道的推荐 GKE 版本的相关信息。

如需主动在升级之前接收有关 GKE 升级的更新，请使用 Pub/Sub 并订阅升级通知。

当有新版本可用时，您应在新版本变成集群的默认版本之前安排升级。在有需要的情况下，此方法可提供更多控制和可预测性，因为 GKE 会跳过已提前升级的集群的自动升级。

测试并验证新的补丁程序版本和次要版本

无论版本在哪个渠道中发布，所有版本都会通过内部测试。但是，由于来自上游 Kubernetes 和 GKE 的更新和补丁程序比较频繁，我们强烈建议您先在测试和/或预演环境中测试新版本，然后在生产环境中发布新版本（特别是 Kubernetes 次要版本升级）。

每个发布渠道都提供两个版本：默认和可用。

  • 新的补丁程序版本在成为默认版本之前的一周可用。
  • 新的 Kubernetes 次要版本在成为默认版本之前的四周可用。

GKE 会逐步将集群自动升级到默认版本。如果需要更好地控制升级过程，我们建议提前升级到可用的版本。GKE 自动升级会跳过手动升级的集群。

自动执行和简化升级的推荐方法涉及以下组成部分：

  • 使用可用版本的预生产环境。
  • 在集群上设置的升级通知，以在有新的可用版本可供测试和认证的时候通知您的团队。
  • 订阅发布渠道的生产环境，该渠道使用渠道中的默认版本。
  • 新的可用版本向生产集群的逐步发布。例如，如果有多个生产集群，则逐步升级计划会首先将这些集群的一部分升级到可用版本，同时将其他集群保持为默认版本，然后进行更多的小部分升级，直至所有集群完成升级。

下表总结了版本事件和建议的操作：

事件 推荐执行的操作
渠道中有新版本 X 可用。 手动升级测试集群，并认证和测试新版本。
版本 X 成为默认版本。 GKE 开始自动升级为默认版本。请考虑在其他集群升级之前升级生产集群。
GKE 开始自动升级集群。 允许集群自动升级，或者使用维护排除期来推迟升级。

补丁程序版本的升级策略

以下是补丁程序版本的建议升级策略，使用的场景如下：

  • 所有集群均订阅了稳定渠道。
  • 新的可用版本会首先发布到预演集群。
  • 生产集群会自动升级到新的默认版本。
  • 定期监控 GKE 是否有新的可用版本。
时间 事件 该怎么做？
T - 1 周 有新的补丁程序版本可用。 升级预演环境。
T 补丁程序版本成为默认版本。 请考虑提前升级生产控制平面，以更好地进行预测。
T GKE 将开始将控制层面升级到默认版本。 请考虑提前升级生产节点池，以更好地进行预测。
T + 1 周 GKE 将开始将集群节点池升级到默认版本。 GKE 将自动升级集群，并跳过手动升级的集群。

新的次要版本的升级策略

以下是新的次要版本的建议升级策略：

时间 事件 该怎么做？
T - 3 周 有新的次要版本可用 升级测试控制平面
T - 2 周
  1. 如果控制平面升级成功，请考虑提前升级生产控制平面。
  2. 升级测试节点池。
T - 1 周 如果升级成功，请考虑提前升级生产节点池。
T 次要版本成为默认版本。
T GKE 将开始将集群控制层面升级到默认版本。 如果在生产发布之前需要更多测试或缓解措施，请创建一个排除期。
T + 1 周 GKE 将开始将集群节点池升级到默认版本。 GKE 将自动升级集群，并跳过手动升级的集群。

减少现有工作负载在升级期间的中断

使集群与安全补丁程序和问题修复保持同步对于确保集群的生命力以及业务连续性至关重要。定期更新可保护您的工作负载免受漏洞和故障的影响。

安排维护期和排除项

为了提高升级的可预测性，并将升级与非高峰工作时间匹配，您可以通过创建维护期来控制控制平面和节点的自动升级。GKE 遵循维护期。也就是说，如果升级过程在定义的维护期之外运行，GKE 会尝试暂停操作，并在下一个维护期恢复操作。

GKE 遵循多日发布计划来提供新版本，以及自动升级不同区域中的集群控制层面和节点。发布通常会持续 4 个工作日或更长时间，并且需要缓冲时间来观察和监控问题。在多集群环境中，您可以为每个集群使用单独的维护期，以跨集群安排发布。例如，您可以通过为每个集群设置不同的维护期，控制不同地区中的集群进行维护的时间。

减少中断（尤其是在高需求的业务时间段内）的另一个工具是维护排除项。您可以使用维护排除来防止在这些时间段内进行自动维护；可以为新集群或现有集群设置维护排除项。您也可将排除项与升级策略结合使用。 例如，如果测试或预演环境因升级而出现故障，则建议您推迟升级生产集群。

设置中断容忍度

您可能熟悉 Kubernetes 中副本的概念。副本可确保工作负载的冗余，从而提升性能和响应速度。设置后，副本可控制在任何给定时间运行的 pod 副本数。但是，在维护期间，Kubernetes 会移除底层节点虚拟机，这会减少副本的数量。如需确保工作负载即使在维护期间也针对应用拥有足够数量的副本，请使用 pod 中断预算 (PDB)。

在 pod 中断预算中，您可以定义可终止的 pod 数量（或百分比），即使终止 pod 会使当前副本数低于期望值。此过程无需等待迁移的 pod 完全正常运行，因此可加快节点排空速度。排空会根据 PDB 配置从节点逐出 pod，使 Deployment 可以在其他可用节点上部署缺少的 pod。设置 PDB 后，如果 pod 的数量等于或小于配置的限制，GKE 将不会关停应用中的 pod。GKE 遵循一个 PDB 的时间最长为 60 分钟。

控制节点池升级

使用 GKE，您可以选择节点升级策略来确定节点池中节点的升级方式。默认情况下，节点池使用超额配置升级。通过超额配置升级，GKE 节点池的升级过程涉及在节点池中重新创建每个虚拟机。具有新版本（升级的映像）的新虚拟机通过滚动更新的方式创建。这需要关停旧节点上运行的所有 pod，然后将 pod 迁移到新节点。您的工作负载可以运行足够的冗余（副本），并且您可以依赖 Kubernetes 根据需要迁移和重启 pod。但是，副本数量暂时减少仍然可能造成业务中断，还可能会降低工作负载的性能，直到 Kubernetes 再次达到所需状态（即达到所需副本数量的下限）。您可以使用超额配置升级来避免此类中断。

在启用超额配置升级的升级期间，GKE 首先会确保升级所需的资源（机器），然后创建一个新的已升级节点，再排空旧节点，最后关停旧节点。这样，预期的容量会在升级过程中保持不变。

对于升级过程可能耗时较长的大集群，您可以通过同时升级多个节点来缩短升级完成时间。使用 maxSurge=20 和 maxUnavailable=0 的超额配置升级，指示 GKE 一次升级 20 个节点，而不使用任何现有容量。

在需要长期支持时使用扩展渠道

如果您希望集群在次要版本上保留更长时间，请遵循最佳实践，在扩展渠道中注册集群。通过此渠道，GKE 会大约 24 个月内支持次要版本。如需了解详情，请参阅通过扩展渠道获取长期支持。

为了充分利用该频道，我们建议您遵循以下最佳实践。其中一些最佳实践需要执行一些手动操作，包括手动升级集群和更改集群的发布渠道。请查看以下支持的场景以及何时不使用扩展信道。

暂时保留次要版本更长时间

如果您需要将集群暂时保留在次要版本上，且保留时间超过 14 个月的标准支持期（例如，为了减少使用在下一个次要版本中移除的已弃用 API），请使用以下流程。您可以暂时将集群从其他发布渠道移至扩展渠道，以便在准备升级到下一个次要版本时继续接收安全补丁。当您准备好升级到下一个次要版本时，可以手动升级集群，然后将集群移回原来的发布渠道。

每年进行 1-2 次次要版本升级

如果您希望在集群准备好升级到新的次要版本时尽可能减少中断，同时仍能获得一些新功能，请执行以下操作：

  • 在扩展渠道中注册集群。
  • 每年执行 1-2 次连续的次要版本升级。例如，从 1.30 升级到 1.31，再升级到 1.32。

此流程可确保集群始终使用可用的次要版本，并从新的次要版本中接收功能，但仅在您确定集群已准备就绪时才接收次要版本升级。

不应使用 Extended Channel 的情况

若要将扩展渠道用于预期用途，需要执行手动操作。以下场景说明了在未主动管理集群的次要版本的情况下使用扩展渠道会产生的后果。

不采取任何措施，并以相同的频率接收小幅升级

如果您想永久保留集群的次要版本，请在扩展渠道中注册集群，然后无需执行任何其他操作。所有次要版本最终都会变为不受支持，并且 GKE 会自动将集群从不受支持的次要版本升级。因此，GKE 会将此集群从一个不受支持的次要版本升级到一个即将不受支持的次要版本，平均间隔时间为大约 4 个月。这意味着，集群会像其他发布渠道一样频繁地接收次要版本升级，但会稍后接收新功能。

核对清单摘要

下表总结了保持 GKE 集群无缝更新的升级策略的建议任务：

最佳做法 Tasks
设置多个环境
在发布渠道中注册集群
创建持续升级策略
减少现有工作负载的中断

后续步骤