在长时间运行的 GKE 集群的生命周期内,由于Google Cloud 为支持 GKE 基础设施的 Compute Engine 资源发出了自动维护事件,因此工作负载会定期中断。本页可帮助您了解节点中断在 GKE 中的含义,监控维护通知,并最大限度地减少中断在挂接了 GPU 和 TPU 的 GKE 节点中的影响。
本文档适用于管理底层技术基础设施生命周期的平台管理员和操作员。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务,请参阅常见的 GKE Enterprise 用户角色和任务。
节点中断在 GKE 中意味着什么?
GKE 集群会管理 GKE 节点的生命周期。这些节点预配在 Compute Engine 虚拟机上,而 Compute Engine 虚拟机会定期遇到主机事件,导致这些事件的原因多种多样,例如:
- 硬件或软件更新和维护。 Google Cloud发出了自动维护事件。
- 硬件故障。
- Compute Engine 虚拟机升级。这类升级与 GKE 节点或节点池版本的升级不同。
主机事件是针对底层 Google Cloud 基础设施发出的,会绕过 GKE 维护政策和排除项。在长时间运行的 GKE 集群的生命周期内,节点可能会遇到训练或服务工作负载定期中断。当这些中断影响运行 AI/机器学习工作负载的 GKE 节点时,GKE 需要重启正在运行的工作负载和底层节点。
为何 GPU 和 TPU 需要中断管理
大多数 Compute Engine 虚拟机(但有一些例外情况)的主机维护政策设置为实时迁移,这意味着正在运行的工作负载通常不会中断,或者几乎不会中断。不过,某些类别的虚拟机不支持实时迁移,包括挂接了 GPU 和 TPU 的虚拟机。当 TPU 切片中的虚拟机发生主机事件时,整个切片会中断,然后重新计划,因为所有维护事件都是在切片级别协调的。因此,如果您创建的 TPU 切片包含数百个虚拟机,那么所有这些虚拟机都会收到相同的维护事件时间表。
发生主机事件时,GKE 会终止节点及其 Pod。如果 Pod 是作为更大的工作负载(例如作业或部署)的一部分部署的,GKE 会在受影响的节点上重启 Pod。
由您或是您使用的框架决定如何处理工作负载配置以适当响应维护事件。例如,您可以保存 AI 训练作业的状态,以减少数据丢失。
如需管理 AI/机器学习工作负载中出现的中断,您可以执行以下操作:
监控维护通知
当已为节点及其底层虚拟机计划中断性主机事件时,以及当这些事件开始时,Compute Engine 会发出通知。通知包含计划的开始时间、事件类型以及其他详细信息。
在 GKE 1.31.1-gke.2008000 版本及更高版本中,您可以监控即将发生的维护事件,包括本部分中所述的事件。
即将进行的维护已计划,但尚未开始
在挂接了 GPU 或 TPU 的虚拟机发生计划的维护事件之前,Compute Engine 会向其所有虚拟机推送通知。这些通知会报告维护窗口的开始时间。如果虚拟机已计划即将进行的维护,但该维护尚未开始,GKE 会向节点标签添加 scheduled-maintenance-time
。
如需在节点级别查询这些通知,请运行以下命令:
kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
-L cloud.google.com/scheduled-maintenance-time
输出类似于以下内容:
NAME STATUS SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name> Ready 1733083200
<gke-accelerator-node-name> Ready 1733083200
[...]
SCHEDULED-MAINTENANCE-TIME
列表示秒数,以 Unix 纪元时间格式显示。
如需在节点元数据级别查询这些通知,请检查实例是否存在维护事件通知。
计划的维护开始
对于支持高级维护的加速器优化机器家族,您可以访问 upcoming-maintenance
端点,该端点会提供有关已计划和已开始的维护事件的信息。
当计划的维护开始时,Compute Engine 会更新 http://metadata.google.internal/computeMetadata/v1/instance/attributes/
目录中的元数据。Compute Engine 会按如下方式更新元数据标签:
- 将
maintenance-event
设置为TERMINATE_ON_HOST_MAINTENANCE
。 - 在
upcoming-maintenance
中,将maintenance_status
设置为ONGOING
。
GKE 会在维护通知窗口的最长有限预定义时间内正常逐出 Pod 并终止工作负载。
尽量减少中断的影响
为了尽量减少节点中断的影响,您可以手动启动主机维护事件。
如果您不启动维护事件,Compute Engine 将完成定期计划的维护。
手动启动主机维护事件
当 Compute Engine 发出有关计划维护事件的通知时,您可以根据您的操作时间表(例如在活动减少的时间段)手动启动维护。
在节点池中的节点上,将节点标签 cloud.google.com/perform-maintenance
设置为 true
。例如:
kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true
GKE 会在使用 perform-maintenance 操作开始维护事件之前正常逐出 Pod 并终止工作负载。应用标签与维护开始之间的时长各不相同。
配置 GKE 以正常终止工作负载
在本部分中,您将配置 GKE 以管理应用生命周期并最大限度地减少工作负载的中断。如果您未配置宽限期,则宽限期默认为 30 秒。
GKE 会尽最大努力正常终止这些 Pod 并执行您定义的终止操作,例如保存训练状态。GKE 会在宽限期开始时向 Pod 发送 SIGTERM
信号。如果 Pod 未在宽限期结束前退出,GKE 会向仍在 Pod 中的任何容器中运行的任何进程发送跟进 SIGKILL
信号。
如需配置正常终止期,请在 Pod 清单的 spec.terminationGracePeriodSeconds
字段中设置终止宽限期(秒)。例如,如需获得 10 分钟的通知时间,请将 Pod 清单中的 spec.terminationGracePeriodSeconds
字段设置为 600 秒,如下所示:
spec:
terminationGracePeriodSeconds: 600
我们建议您设置的终止宽限期足够长,以便任何正在进行的任务在通知时间范围内完成。
如果您的工作负载使用机器学习框架(例如 MaxText、Pax 或带有 Orbax 的 JAX),则工作负载可以捕获关停 SIGTERM
信号并启动检查点过程。如需了解详情,请参阅 TPU 自动检查点。
正常终止的过程
当中断事件开始时(无论该事件是手动触发还是由虚拟机自动触发),Compute Engine 都会通过更新 maintenance-event
元数据键来发出即将关停机器的信号。在这两种即将关停节点的情况下,GKE 都会开始正常终止。
以下工作流展示了 GKE 在即将关停节点时如何正常终止节点:
- 在 60 秒内会发生以下情况:
- 系统组件将应用设置为
ONGOING
的cloud.google.com/active-node-maintenance
节点标签,以指示工作负载正在停止过程中。 - GKE 会应用节点污点来防止在该节点上安排新的 Pod。污点具有
cloud.google.com/impending-node-termination:NoSchedule
键。我们建议您修改工作负载,以容忍由于发生已知终止而导致的此污点。
- 系统组件将应用设置为
- maintenance-handler 组件会开始逐出 Pod,首先逐出工作负载 Pod,然后逐出系统 Pod(例如 kube-system)。
- GKE 会向节点上正在运行的工作负载 Pod 发送
SIGTERM
关停信号,以提醒它们即将关停。Pod 可以使用此提醒来完成任何正在进行的任务。GKE 会尽最大努力正常终止这些 Pod。 - 驱逐完成后,GKE 会将
cloud.google.com/active-node-maintenance
标签的值更新为terminating
,以指示节点已准备好进行终止。
之后,系统会执行节点终止并分配替换节点。该过程完成后,GKE 会清除标签和污点。如需延长使用 GPU 或 TPU 的工作负载的终止时段,请完成手动启动主机维护事件部分中的步骤。
监控活跃正常终止的进度
您可以按以下正常终止事件过滤 GKE 日志:
- 当虚拟机检测到因即将发生的节点终止(例如 Compute Engine 主机维护事件)而导致中断时,GKE 会在工作负载正在停止时将
cloud.google.com/active-node-maintenance
设置为ONGOING
,并在工作负载完成且节点准备好进行终止时将其设置为terminating
。 - 在限制安排新的工作负载时,GKE 会应用
cloud.google.com/impending-node-termination:NoSchedule
污点。