本页面介绍维护窗口和维护排除项政策，它们控制可以和不能在 Google Kubernetes Engine (GKE) 集群上进行某些集群维护（例如自动升级）的时间。例如，零售企业可以将维护操作限制为仅在工作日晚上进行，并且可以在重要的行业销售活动期间阻止自动维护操作。
GKE 维护政策简介
通过 GKE 维护政策（包括维护窗口和排除项），您可以控制可以对集群进行某些自动维护的时间，包括集群升级以及对节点配置或集群网络拓扑的其他更改。
维护窗口是允许进行 GKE 自动维护的重复性时间段。
维护排除项是禁止进行 GKE 自动维护的非重复性时间段。
如果有开启的维护窗口且没有活跃的维护排除项，GKE 会进行遵循集群维护政策的自动更改。对于每个集群，您可以配置一个周期性维护窗口和多个维护排除项。
其他类型的维护不依赖于 GKE 维护政策，包括控制平面修复操作，以及 GKE 所依赖的服务（例如 Compute Engine）的维护。如需了解详情，请参阅不遵循维护政策的自动维护。
哪些更改会遵循和不遵循 GKE 维护政策
在配置 GKE 维护政策（维护窗口和排除项）之前，请查看以下部分，了解 GKE 和相关服务如何遵循以及不遵循它们。
遵循 GKE 维护政策的自动维护
借助 GKE 维护政策，您可以控制以下类型的事件的时间，这些事件会导致集群临时中断：
- 自动集群升级，包括控制平面升级和节点升级。如需详细了解这些更改以及它们如何可能导致您的环境临时中断，请参阅 Autopilot 集群升级和 Standard 集群升级。
- 由用户发起的配置更改（导致重新创建节点或显著更改集群的内部网络拓扑）。如需了解详情，请参阅遵循 GKE 维护政策的手动更改。
其他类型的自动维护不依赖于维护政策。如需了解详情，请参阅不遵循维护政策的自动维护。
不遵循 GKE 维护政策的自动维护
GKE 维护窗口和排除项不会阻止所有类型的自动维护。在配置 GKE 集群的维护政策之前，请务必了解哪些类型的更改不会遵循维护窗口和排除项。
其他 Google Cloud 维护
GKE 维护窗口和排除项不会阻止底层 Google Cloud 服务（主要是 Compute Engine）或向集群安装应用的服务（例如 Cloud Deploy）的自动维护。
例如，GKE 节点是 GKE 为您的集群管理的 Compute Engine 虚拟机。Compute Engine 虚拟机有时会遇到主机事件，其中可能包括维护事件或主机错误。虚拟机在这些事件期间的行为方式取决于虚拟机的主机维护政策，对于大多数虚拟机而言，该政策在默认情况下表示进行实时迁移。这通常意味着节点的停机时间极少或没有，对于大多数工作负载，默认政策就足够了。对于某些虚拟机机器家族，您可以监控和规划主机维护事件，并触发主机维护事件以使用您的 GKE 维护政策设置其时间。
某些虚拟机（包括具有 GPU 和 TPU 的虚拟机）无法执行实时迁移。如果您使用的是这些加速器，请了解如何处理因 GPU 或 TPU 的节点维护而导致的中断。
我们建议您查看主机事件、主机维护政策的相关信息，并确认工作负载已准备好应对中断，尤其是在无法执行实时迁移的节点上运行时。
自动修复和调整大小
GKE 会对控制平面执行自动修复操作。此类操作包括将控制平面纵向扩容到适当大小或者重启控制平面以解决问题等流程。大多数修复操作都会忽略维护窗口和排除项，这是因为，如果不执行修复操作，则集群可能无法正常运行。
您无法停用控制平面修复功能。但是，大多数类型的集群（包括 Autopilot 集群和 Standard 区域级集群）具有多个控制平面副本，这样可以实现 Kubernetes API 服务器的高可用性，即使在维护事件期间也是如此。Standard 可用区级集群只有一个控制平面，在控制平面配置更改和集群维护期间无法修改。这包括部署工作负载。
节点还具有自动修复功能，您可以为 Standard 集群停用该功能。
关键安全漏洞修补
维护期和排除项可能会导致安全补丁程序延迟安装。不过，GKE 保留为防范重大安全漏洞而忽略维护政策的权利。
遵循 GKE 维护政策的手动更改
对节点或网络配置进行的某些更改需要重新创建节点才能应用新配置，包括以下某些更改：
这些更改遵循 GKE 维护政策，这意味着 GKE 会等待开启的维护窗口，并等待没有阻止节点维护的活跃维护排除项。如需手动将更改应用于节点，请使用 Google Cloud CLI 和节点池已在运行的 GKE 版本调用 gcloud container clusters
upgrade 命令并传递 --cluster-version 标志。
维护期
借助维护期，您能够控制可以进行控制层面和节点自动升级的时间，以缓解工作负载可能暂时中断的情况。维护期适用于以下类型的场景和其他类似的场景：
- 非高峰时段：您想要在流量减少的非高峰时段内安排自动升级以最大限度地减小停机的可能性。
- 随时待命：您想要确保在工作时间内进行升级，以便有人可以监控升级并管理任何意外问题。
- 多集群升级：您想要以指定的时间间隔在不同区域的多个集群中发布升级（一次一个区域）。
除了自动升级之外，Google 偶尔还需要执行其他维护任务，并尽可能遵循集群的维护窗口。
如果任务运行超出了维护窗口，则 GKE 会尝试暂停任务，并尝试在下一个维护窗口期间恢复这些任务。
GKE 保留在维护期之外发布计划外紧急升级的权利。此外，对弃用或过时软件的强制升级可能会在维护期之外自动进行。
如需了解如何为新集群或现有集群设置维护期，请参阅配置维护期。
维护期的时区
在配置和查看维护期时，时间的显示方式会因您使用的工具而有所不同：
配置维护期时
时间始终以世界协调时间 (UTC) 格式存储。 但是，在配置维护窗口时，您可以使用世界协调时间 (UTC) 或本地时区。
使用更通用的 --maintenance-window 标志配置维护窗口时，您无法指定时区。使用 gcloud CLI 或 API 时，系统会使用世界协调时间 (UTC)，而 Google Cloud 控制台会使用本地时区显示时间。
如果使用更精细的标志（例如 --maintenance-window-start），您可以将时区指定为值的一部分。如果省略时区，则系统会使用本地时区。
查看维护期时
查看集群的相关信息时，维护期的时间戳可能会以世界协调时间 (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 个维护排除项。
- 如果您没有在排除项中指定范围，则范围默认为“无升级”。
- 您可以根据范围将维护排除项设置为不同的时长。如需了解详情，请查看配置维护排除项部分中的维护排除项长度行。
- 您无法将维护排除项配置为包含或超出与集群发布渠道注册对应的次要版本的支持终止日期。请参见以下示例：
用法示例
以下是一些限制可能发生的更新范围的示例使用场景。
示例：正在为年底的节日季做准备的零售商
在本示例中，零售企业不希望在销量最高的时间段内（也就是涵盖黑色星期五到网购星期一的这四天以及 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 逐出和重新调度。集群管理员设置了以下排除项：
- 无次要升级或节点升级：冻结节点升级三个月。当公司准备好接受数据库停机时，其会触发手动节点升级。