维护期和排除项

本页面介绍维护期和维护排除项，它们控制可以和不能在 Google Kubernetes Engine (GKE) 集群上进行集群维护（例如自动升级）的时间。例如，零售企业可以将维护操作限制为仅在工作日晚上进行，并且可以在重要的行业销售活动期间阻止自动维护操作。

概览

现在，借助维护期和排除项，您可以精确控制可以在集群上进行自动维护的时间。

维护窗口是允许进行自动维护的重复性时间段。

维护排除项是禁止进行自动维护的非重复性时间段。

您可以分开、单独配置维护期和维护排除项。您可以配置多个维护排除项。

自动维护示例

Google 会根据需要或者在您更改配置（重新创建集群中的节点或网络）时，在集群上执行维护任务，如下所示：

可用区级集群在控制层面配置更改和集群维护期间无法修改。这包括部署工作负载。

在将工作负载迁移到升级后的节点时，上面列出的所有其他类型的更改都会导致临时中断。

注意事项

维护期和排除项可能会导致安全补丁程序延迟安装。GKE 保留为防范重大安全漏洞而忽略维护政策的权利。在启用维护窗口和排除项之前，请务必了解以下注意事项。

其他 Google Cloud 维护

GKE 集群和工作负载还可能会受到其他依赖服务（例如 Compute Engine）自动维护的影响。 GKE 维护窗口和排除项不会阻止其他 Google 服务或向集群安装应用的服务（例如 Google Cloud Deploy）自动维护。

自动修复和调整大小

GKE 会对控制层面执行自动修复操作。此类操作包括将控制层面纵向扩容到适当大小或者重启控制层面以解决问题等流程。大多数修复操作都会忽略维护期和排除项，这是因为，如果不执行修复操作，则集群可能无法正常运行。修复控制层面无法停用。

节点还具有自动修复功能，但可以停用。

节点重新创建和维护期

如果您启用或修改某些功能或选项（例如影响集群控制层面和节点之间的网络的功能或选项），则系统会重新创建节点以应用新配置。以下是一些导致节点重新创建的功能示例：

如果您使用维护窗口或排除项，并启用或修改需要重新创建节点的功能或选项，则新配置仅在允许节点维护时才会应用于节点。如果您不想等待，可通过调用 gcloud container clusters upgrade 命令并使用节点池已经运行的 GKE 版本传递 --cluster-version 标志，将更改手动应用到节点。您必须使用 gcloud 命令行工具解决此问题。

维护期

借助维护期，您能够控制可以进行控制层面和节点自动升级的时间，以缓解工作负载可能暂时中断的情况。维护期适用于以下类型的场景和其他类似的场景：

  • 非高峰时段：您想要在流量减少的非高峰时段内安排自动升级以最大限度地减小停机的可能性。
  • 随时待命：您想要确保在工作时间内进行升级，以便有人可以监控升级并管理任何意外问题。
  • 多集群升级：您想要以指定的时间间隔在不同区域的多个集群中发布升级（一次一个区域）。

除了自动升级之外，Google 偶尔还需要执行其他维护任务，并尽可能遵循集群的维护期。

如果任务运行超出了维护期，则 GKE 会尝试暂停任务，并尝试在下一个维护期恢复这些任务。

GKE 保留在维护期之外发布计划外紧急升级的权利。此外，对弃用或过时软件的强制升级可能会在维护期之外自动进行。

如需了解如何为新集群或现有集群设置维护期，请参阅配置维护期。

限制

维护窗口具有以下限制：

每个集群有一个维护期

每个集群只能配置一个维护期。如果配置新的维护期，则新维护期会覆盖它的上一个维护期。

维护期的时区

在配置和查看维护期时，时间的显示方式会因您使用的工具而有所不同：

配置维护期时

使用更通用的 --maintenance-window 标志配置维护窗口时，您无法指定时区。使用 gcloud 工具或 API 时，系统会使用世界协调时间 (UTC)，而 Google Cloud Console 会使用本地时区显示时间。

如果使用更精细的标志（例如 --maintenance-window-start），您可以将时区指定为值的一部分。如果省略时区，则系统会使用本地时区。时间始终以世界协调时间 (UTC) 格式存储。

查看维护期时

查看集群的相关信息时，维护期的时间戳可能会以世界协调时间 (UTC) 格式或本地时区显示，具体取决于您查看信息的方式：

  • 使用 Google Cloud Console 查看集群的相关信息时，时间始终以本地时区显示。
  • 使用 gcloud 工具查看集群的相关信息时，时间始终以世界协调时间 (UTC) 格式显示。

在这两种情况下，RRULE 始终采用世界协调时间 (UTC)。也就是说，如果指定一周中的某天，则这些时间采用世界协调时间 (UTC)。

维护排除项

借助维护排除项，您可以防止在特定时间段内进行自动维护。例如，许多零售企业都制定了业务准则，禁止在年末假日期间更改基础架构。 对于已知的高影响力事件，建议您将任何内部更改限制与在事件发生前一周开始并持续到事件持续时间结束的事件排除项相匹配。

排除项没有重复周期。请分别创建定期排除项的每个实例。

当排除项和维护窗口重叠时，排除项优先。

如需了解如何为新集群或现有集群设置维护排除项，请参阅配置维护排除项。

要排除的维护范围

您不仅可以指定何时防止集群进行自动维护，还可以限制可能发生的自动更新的范围。维护排除项范围适用于以下类型的场景和其他类似的场景：

  • 避免任何维护：您希望暂时避免在特定时间段内对集群进行任何更改。
  • 维护当前的 Kubernetes 次要版本：您想要临时维护集群的次要版本，以避免 API 更改或验证下一个次要版本。
  • 防止节点池中断：您希望暂时避免工作负载被逐出和重新调度。

下表列出了您可以在维护排除项中限制的自动更新的范围。该表还说明了发生的升级类型（次要和/或补丁程序）。升级时，控制层面和/或节点池中的虚拟机会重启。对于控制层面，虚拟机重启可能会暂时降低 Kubernetes API 服务器的可用性，尤其是在具有单个控制层面的可用区级集群拓扑中。对于节点，虚拟机重启会触发 Pod 重新调度，这可能会暂时中断现有工作负载。

范围 控制平面 节点池
次要升级 补丁程序升级 虚拟机中断
（由于 GKE
维护）		 次要升级 补丁程序升级 虚拟机中断
（由于 GKE
维护）
无升级（默认） 否 否 否 否 否 否
无次要升级 否 是 是 否 是 是
无次要升级或节点升级 否 是 是 否 否 否

如需了解次要版本和补丁程序版本的定义，请参阅版本控制方案。

多个排除项

您可以在集群上设置多个排除项。这些排除项的范围可能不同，并且可能具有重叠的时间范围。年底的节假日用例是重叠排除项的示例，其中“无升级”和“无次要升级”范围都在使用。

当排除项重叠时，如果任何活跃的排除项（即当前时间在排除项时间段内）阻止升级，则升级将被推迟。

作为重叠排除项的一个示例，集群指定了以下排除项：

  • 无升级：1 月 1 日 - 1 月 7 日
  • 无次要版本升级：1 月 1 日 - 1 月 7 日
  • 无次要版本或节点升级：1 月 1 日 - 1 月 7 日

由于这些重叠的排除项，集群上的以下升级将被阻止：

  • 控制层面在 1 月 1 日的补丁程序升级（被“无升级”排除项拒绝）
  • 控制层面在 1 月 1 日的次要版本升级（被所有排除项拒绝）
  • 节点池在 1 月 1 日的补丁程序升级（被“无升级”和“无次要版本或节点升级”排除项拒绝）
  • 节点池在 1 月 1 日的次要版本升级（被所有排除项拒绝）

排除项到期时间

排除项到期（即当前时间超出了为排除项指定的结束时间）时，该排除项将不再阻止 GKE 更新。其他仍然有效（未过期）的排除项将继续阻止 GKE 更新。

如果没有阻止集群升级的排除项，则您的集群将逐步升级到集群发布渠道中的当前默认版本（或无发布渠道中的集群静态默认版本）。

如果您的集群在排除项到期后比当前默认版本有多个次要版本，则 GKE 每月将安排一次次要版本升级（同时升级集群控制层面和节点），直到集群达到发布渠道的默认版本。如果您希望尽快将集群恢复到默认版本，则可以执行手动升级。

限制

维护排除项具有以下限制：

  • 您可以仅针对在发布渠道中注册的集群限制维护排除项中的自动升级范围。
  • 您最多可以添加 3 个维护排除项，以排除所有升级（即“无升级”范围）。
  • 您总共可以有 20 个维护排除项。
  • 如果您没有在排除项中指定范围，则范围默认为“无升级”。
  • 维护排除项的长度根据指定的排除项范围存在限制：

用法示例

以下是一些限制可能发生的更新范围的示例用例。

示例：正在为年底的节假日做准备的零售商

在这个例子中，零售企业不希望系统在最高销量的时间段（从黑色星期五到网购星期一这四天以及 12 月到新年伊始）中断运行。在准备购物季时，集群管理员会设置以下排除项：

  • 无次要升级：仅允许 9 月 30 日至 1 月 15 日期间控制层面和节点上的补丁程序更新。
  • 无升级：在 11 月 19 日至 12 月 4 日期间冻结所有升级。
  • 无升级：在 12 月 15 日至 1 月 5 日期间冻结所有升级。

示例：在 Kubernetes 中使用即将移除的 Beta 版 API 的公司

在此示例中，公司使用 CustomResourceDefinition apiextensions.k8s.io/v1beta1 API，该 API 将在 1.22 版中移除。当公司运行 1.22 之前的版本时，集群管理员会设置以下排除项：

  • 无次要升级：在将客户应用从 apiextensions.k8s.io/v1beta1 迁移到 apiextensions.k8s.io/v1 时，冻结次要升级三个月。

示例：公司的旧版数据库无法应对节点池升级

在本示例中，公司运行的数据库无法很好地响应节点池升级期间发生的 Pod 逐出和重新调度。集群管理员会设置以下排除项：

  • 无次要升级或节点升级：冻结节点升级三个月。当公司准备好接受数据库的停机时间时，它们会触发手动节点升级。

后续步骤