本页面介绍维护期和维护排除项，它们控制可以和不能在 Google Kubernetes Engine (GKE) 集群上进行集群维护（例如自动升级）的时间。例如，零售企业可以将维护操作限制为仅在工作日晚上进行，并且可以在重要的行业销售活动期间阻止自动维护操作。
概览
现在，借助维护期和排除项，您可以精确控制可以在集群上进行自动维护的时间。
维护窗口是允许进行自动维护的重复性时间段。
维护排除项是禁止进行自动维护的非重复性时间段。
您可以分开、单独配置维护期和维护排除项。您可以配置多个维护排除项。
自动维护示例
Google 会根据需要或者在您更改配置（重新创建集群中的节点或网络）时，在集群上执行维护任务，如下所示：
- 根据 GKE 版本控制和支持政策，自动升级到集群控制层面。
- 节点自动升级（如果已启用）。
- 用户执行的配置更改（导致重新创建节点），例如 GKE Sandbox。
- 用户执行的配置更改（从根本上更改了集群的内部网络拓扑），例如优化 IP 地址分配。
可用区级集群在控制层面配置更改和集群维护期间无法修改。这包括部署工作负载。
在将工作负载迁移到升级后的节点时，上面列出的所有其他类型的更改都会导致迁移暂时中断。
注意事项
维护期和排除项可能会导致安全补丁程序延迟安装。GKE 保留为防范重大安全漏洞而忽略维护政策的权利。在启用维护窗口和排除项之前，请务必了解以下注意事项。
其他 Google Cloud 维护
GKE 集群和工作负载还可能会受到其他依赖服务（例如 Compute Engine）自动维护的影响。 GKE 维护窗口和排除项不会阻止其他 Google 服务或向集群安装应用的服务（例如 Google Cloud Deploy）自动维护。
自动修复和调整大小
GKE 会对控制层面执行自动修复操作。此类操作包括将控制层面纵向扩容到适当大小或者重启控制层面以解决问题等流程。大多数修复操作都会忽略维护期和排除项，这是因为，如果不执行修复操作，则集群可能无法正常运行。修复控制层面无法停用。
节点还具有自动修复功能，但可以停用。
节点重新创建和维护期
如果您启用或修改某些功能或选项（例如影响集群控制层面和节点之间的网络的功能或选项），则系统会重新创建节点以应用新配置。以下是一些导致节点重新创建的功能示例：
如果您使用维护窗口或排除项，并启用或修改需要重新创建节点的功能或选项，则新配置仅在允许节点维护时才会应用于节点。如果您不想等待，可通过调用 gcloud container clusters upgrade 命令并使用节点池已经运行的 GKE 版本传递 --cluster-version 标志，将更改手动应用到节点。您必须将 Google Cloud CLI 用于此临时解决方法。
维护期
借助维护期，您能够控制可以进行控制层面和节点自动升级的时间，以缓解工作负载可能暂时中断的情况。维护期适用于以下类型的场景和其他类似的场景：
- 非高峰时段：您想要在流量减少的非高峰时段内安排自动升级以最大限度地减小停机的可能性。
- 随时待命：您想要确保在工作时间内进行升级，以便有人可以监控升级并管理任何意外问题。
- 多集群升级：您想要以指定的时间间隔在不同区域的多个集群中发布升级（一次一个区域）。
除了自动升级之外，Google 偶尔还需要执行其他维护任务，并尽可能遵循集群的维护期。
如果任务运行超出了维护期，则 GKE 会尝试暂停任务，并尝试在下一个维护期恢复这些任务。
GKE 保留在维护期之外发布计划外紧急升级的权利。此外，对弃用或过时软件的强制升级可能会在维护期之外自动进行。
如需了解如何为新集群或现有集群设置维护期，请参阅配置维护期。
限制
维护窗口具有以下限制：
每个集群有一个维护期
每个集群只能配置一个维护期。如果配置新的维护期，则新维护期会覆盖它的上一个维护期。
维护期的时区
在配置和查看维护期时，时间的显示方式会因您使用的工具而有所不同：
配置维护期时
使用更通用的 --maintenance-window 标志配置维护窗口时，您无法指定时区。使用 gcloud CLI 或 API 时，系统会使用世界协调时间 (UTC)，而 Google Cloud 控制台会使用本地时区显示时间。
如果使用更精细的标志（例如 --maintenance-window-start），您可以将时区指定为值的一部分。如果省略时区，则系统会使用本地时区。时间始终以世界协调时间 (UTC) 格式存储。
查看维护期时
查看集群的相关信息时，维护期的时间戳可能会以世界协调时间 (UTC) 格式或本地时区显示，具体取决于您查看信息的方式：
- 使用 Google Cloud 控制台查看集群的相关信息时，时间始终以本地时区显示。
- 使用 gcloud CLI 查看集群的相关信息时，时间始终以世界协调时间 (UTC) 格式显示。
在这两种情况下，RRULE 始终采用世界协调时间 (UTC)。也就是说，如果指定一周中的某天，则这些时间采用世界协调时间 (UTC)。
维护排除项
借助维护排除项，您可以防止在特定时间段内进行自动维护。例如，许多零售企业都制定了业务准则，禁止在年末假日期间更改基础架构。再举一例，如果公司使用的是计划弃用的 API，他们可以使用维护排除项暂停次要升级，以便留出时间来迁移应用。
对于已知且具有较大影响的事件，我们建议您将任何内部更改限制与维护排除项相匹配，而维护排除项在事件发生前一周开始并在整个事件期间持续。
排除项没有重复周期。请分别创建定期排除项的每个实例。
当排除项和维护窗口重叠时，排除项优先。
如需了解如何为新集群或现有集群设置维护排除项，请参阅配置维护排除项。
要排除的维护范围
您不仅可以指定何时禁止集群进行自动维护，还可以限制可能发生的自动更新的范围。维护排除项范围适用于以下类型的场景和其他类似的场景：
- 不升级 - 避免任何维护：您希望在特定时间段内暂时避免对集群进行任何更改。
- 无次要升级 - 维护当前的 Kubernetes 次要版本：您需要暂时维护集群的次要版本，以避免进行 API 更改或验证下一个次要版本。
- 无次要或节点升级 - 防止节点池中断：由于节点升级，您希望暂时避免逐出和重新安排工作负载。
下表列出了您可以在维护排除项中限制的自动更新的范围。该表还指出了发生的升级类型（次要升级和/或补丁程序升级）。升级时，控制层面和/或节点池的虚拟机会重启。对于控制层面，虚拟机重启可能会暂时降低 Kubernetes API 服务器的可用性，尤其是在具有单个控制层面的可用区级集群拓扑中。对于节点，虚拟机重启会触发 Pod 重新安排，这可能会暂时中断现有工作负载。您可以使用 Pod 中断预算 (PDB) 设置工作负载中断的容忍度。
| 范围 | 控制平面 | 节点池 | ||||
|---|---|---|---|---|---|---|
| 次要升级 | 补丁升级 | 虚拟机中断 （由于 GKE 维护） |
次要升级 | 补丁升级 | 虚拟机中断 （由于 GKE 维护） |
|
| 无升级（默认） | 否 | 否 | 否 | 否 | 否 | 否 |
| 无次要升级 | 否 | 是 | 是 | 否 | 是 | 是 |
| 无次要升级或节点升级 | 否 | 是 | 是 | 否 | 否 | 否 |
如需了解次要版本和补丁程序版本的定义，请参阅版本控制方案。
多个排除项
您可以对一个集群设置多个排除项。这些排除项的范围可以不同，彼此之间可以具有重叠的时间范围。年底的节假日用例是重叠排除项的一个示例，其中同时使用了“无升级”和“无次要版本升级”范围。
在排除项重叠时，如果有任何生效的排除项（即当前时间在排除项时间段内）阻止升级，升级将被推迟。
使用年底的节假日使用场景，集群指定了以下排除项：
- 无次要升级：9 月 30 日 - 1 月 15 日
- 无升级：11 月 19 日 - 12 月 4 日
- 无升级：12 月 15 日 - 1 月 5 日
由于这些重叠的排除项，集群上的以下升级将被阻止：
- 11 月 25 日对节点池进行补丁程序升级（被“无升级”排除项拒绝）
- 12 月 20 日对控制层面进行次要版本升级（被“无次要版本升级”和“无升级”排除项拒绝）
- 12 月 25 日对控制层面进行补丁程序升级（被“无升级”排除项拒绝）
- 1 月 1 日对节点池进行次要版本升级（被“无次要版本升级”和“无升级”排除项拒绝）
将允许在集群上执行以下维护：
- 11 月 10 日对控制层面进行补丁程序升级（“无次要版本升级”排除项允许）
- 12 月 10 日因 GKE 维护而导致的虚拟机中断（“无次要版本升级”排除项允许）
排除项到期时间
在一个排除项到期（即当前时间超出了为排除项指定的结束时间）时，该排除项将不再阻止 GKE 更新。其他仍然有效（未过期）的排除项将继续阻止 GKE 更新。
如果没有阻止集群升级的排除项，则您的集群将逐步升级到集群发布渠道中的当前默认版本（或无发布渠道中的集群静态默认版本）。
如果在排除项到期后，您的集群相较于当前默认版本落后了多个次要版本，则 GKE 每月将安排一次次要版本升级（同时升级集群控制层面和节点），直至集群达到该发布渠道的默认版本。如果您希望尽快将集群恢复到默认版本，则可以执行手动升级。
限制
维护排除项具有以下限制：
- 您可以仅针对在发布渠道中注册的集群限制维护排除项中的自动升级范围。维护排除项默认设为“无升级”范围。
- 您最多可以添加 3 个维护排除项，以排除所有升级（即“无升级”范围）。这些排除项必须配置为在 32 天的滚动窗口中至少提供 48 小时的维护时间。
- 您总共可以有 20 个维护排除项。
- 如果您没有在排除项中指定范围，则范围默认为“无升级”。
- 维护排除项的时长根据指定的排除项范围存在限制：
- 无升级：不能超过 30 天。
- 无次要版本升级：不能在排除项创建日期后超过 180 天结束，也不能超过次要版本的服务终止日期。
- 无次要版本升级或节点升级：不能在排除项创建日期后超过 180 天结束，也不能超过次要版本的服务终止日期。
用法示例
以下是一些限制可能发生的更新范围的示例使用场景。
示例：正在为年底的节假日做准备的零售商
在本示例中，零售企业不希望在销量最高的时间段内（也就是涵盖黑色星期五到网购星期一的这四天以及 12 月到新年初）中断。在为购物季做准备时，集群管理员会设置以下排除项：
- 无次要升级：仅允许 9 月 30 日至 1 月 15 日期间控制层面和节点上的补丁程序更新。
- 无升级：在 11 月 19 日至 12 月 4 日期间冻结所有升级。
- 无升级：在 12 月 15 日至 1 月 5 日期间冻结所有升级。
如果在维护排除项到期时没有其他排除期，则集群会在 9 月 30 日至 1 月 6 日期间升级到新的 GKE 次要版本（若有）。
示例：在 Kubernetes 中使用即将移除的 Beta 版 API 的公司
在本示例中，公司使用 CustomResourceDefinition
apiextensions.k8s.io/v1beta1 API，该 API 将在 1.22 版中移除。当公司运行的版本低于 1.22 时，集群管理员会设置以下排除项：
- 无次要升级：在将客户应用从
apiextensions.k8s.io/v1beta1迁移到apiextensions.k8s.io/v1时，冻结次要升级三个月。
示例：公司的旧版数据库无法应对节点池升级
在本示例中，公司运行的数据库无法很好地响应节点池升级期间发生的 Pod 逐出和重新调度。集群管理员设置了以下排除项：
- 无次要升级或节点升级：冻结节点升级三个月。当公司准备好接受数据库停机时，其会触发手动节点升级。