本页面介绍了如何管理经过 AI 优化的 Google Kubernetes Engine (GKE) 集群，这些集群包含 A4X Max、A4X、A4、A3 Ultra、A3 Mega 和 A3 High（8 个 GPU）机器，包括以下与 GKE 集群和 AI 工作负载相关的常见事件：
- 宿主机维护
- 集群升级
- 报告有故障的主机
管理 AI 工作负载的主机维护
GKE 节点在 Compute Engine 实例上运行，这些实例会定期遇到主机事件，这些事件可能会中断 AI 工作负载。由于主机事件发生在底层Google Cloud 基础设施上，因此会绕过 GKE 维护窗口和排除项。虽然大多数计算实例的主机维护政策都设置为实时迁移，这样可以最大限度地减少工作负载中断，但 GPU 和 TPU 不支持实时迁移。当这些主机事件影响运行 AI 工作负载的 GKE 节点时，GKE 必须终止该节点以及在该节点上运行的 Pod。如果 Pod 是作为更大的工作负载（例如作业或部署）的一部分部署的，GKE 会尝试在受影响的节点上重启 Pod。
如需详细了解如何管理底层计算实例的主机维护，请参阅管理 GPU 和 TPU 的 GKE 节点中断。
监控主机维护事件
对于运行 GKE 1.31.1-gke.2008000 版或更高版本的集群，您可以通过以下方式查看主机维护事件的预定开始时间。对于所有 GPU 和 TPU，启动时间都由相应 GKE 节点上的 Kubernetes 节点标签表示。
如需了解详情，请参阅监控维护通知。
借助这些节点标签，您可以执行以下操作：
手动启动主机维护事件
在 Compute Engine 发出有关计划维护事件的通知后，您可以根据自己的时间表手动启动维护。例如，您可以选择在活动减少期间执行维护。
如果您不手动启动主机维护事件，Compute Engine 将自动完成定期计划的维护。
按照说明手动启动主机维护事件。此外，请继续阅读本部分，了解以下内容：
在安排工作负载时使用主机维护信息
您可以结合使用通过 GKE 节点标签显示的维护信息以及节点亲和性和反亲和性，最大限度地减少对工作负载的中断。
如需查看如何使用这些信息的示例，请参阅以下部分。
将 Pod 调度到没有未来预定维护事件的节点
您可以指示 GKE 仅将 Pod 调度到没有未来预定维护事件的节点，例如使用以下代码段：
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/scheduled-maintenance-time
operator: DoesNotExist
将 Pod 调度到在特定日期之后安排了维护的节点
您可以提供 Unix 纪元时间，指示 GKE 仅将 Pod 调度到在特定日期之后安排了维护的节点：
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/scheduled-maintenance-time
operator: Gt
values:
- 1733296000
管理 AI 工作负载的 GKE 集群升级
AI 工作负载对中断很敏感。
在 GKE 集群的生命周期内，AI 工作负载必须做好准备，以应对底层计算实例和 GKE 集群本身的中断：
- 主机维护：如需管理底层计算实例的主机维护，请参阅管理 GPU 和 TPU 的 GKE 节点中断。 前面的部分也介绍了这一点。
- 集群升级：为了管理集群升级带来的中断，您可以使用以下工具：
我们建议您让集群始终在发布渠道中注册。默认情况下，GKE 集群会在常规发布渠道中注册。如需详细了解发布渠道的优势，请参阅已在发布渠道中注册和未在发布渠道中注册的集群之间的比较。
借助发布渠道，您可以访问更多功能，包括其他维护排除范围。 我们建议为 AI 工作负载选择“无次要升级或节点升级”范围。
通过 GKE 报告有故障的主机
本部分概述了如何通过 GKE 报告使用与预留绑定的预配模型预配了计算实例的故障主机。如果您想报告使用灵活启动预配模型（预览版）预配的节点存在故障的主机，请与您的客户支持团队联系。
如果您在节点上观察到 GPU 内存或 Xid 错误，并且想在报告主机故障之前验证手动恢复措施（例如触发客户操作系统重启 [kubectl label
nodes <NODE_NAME> cloud.google.com/perform-reboot=true]）是否可以解决问题，请参阅查看 Xid 消息。
主机是数据中心内运行计算实例的单个物理服务器机器，该计算实例托管您的 GKE 节点。您可以将 fault-behavior 节点标签应用于受影响的 GKE 节点，以报告有故障的主机。将节点标签应用到特定 GKE 节点后，GKE 会执行以下步骤：
- 正常逐出节点中的工作负载。
- 防止在该节点上调度新的 Pod。
- 在计算实例上调用 API 以将主机标记为有故障。
- 等待计算实例在运行状况良好的主机上恢复运行。对于使用“所有容量”预留运行模式的预留，Compute Engine 会在修复操作完成后将计算实例恢复到同一节点上。
- 从节点中移除污点和
fault-behavior标签。
之后，节点将再次准备好为工作负载提供服务。
要求
如需报告有故障的主机，您的 GKE 节点必须满足以下要求：
- 您必须运行 GKE 补丁版本 1.32.3-gke.1057001 或更高版本。
- 您必须运行以下 GPU 机器类型之一：A4X Max、A4X、A4、A3 Ultra、A3 Mega 和 A3 High（8 个 GPU）。
- 您必须在与预留资源绑定的计算实例上运行 GKE 节点。
- 您的 GKE 节点必须处于
RUNNING状态。如果您尝试在删除计算实例后报告故障宿主机，系统会返回错误消息，并且不会将宿主机标记为故障。 - 根据对代码块健康状况的评估，您每月对相应 API 的调用次数可能会受到速率限制。如果您的预留使用全容量预留运行模式，则不适用速率限制。
报告有故障的主机
如需报告有故障的主机，请执行以下操作：
使用 GKE 可观测性工具、您自己的监控工具或日志来确定出现性能问题的 GKE 节点。保存
NODE_NAME。使用以下命令将节点报告为有故障。您可以提供原因，并在后续版本中提供说明：
kubectl patch node NODE_NAME --type merge -p '{ "metadata": { "labels": { "cloud.google.com/fault-behavior": "FAULT_REASON" }, "annotations": { "cloud.google.com/fault-description": "FAULT_DESCRIPTION" } } }'按如下方式修改命令：
- 将
NODE_NAME替换为故障节点的名称。 - 使用以下一个或多个值将
FAULT_REASON替换为相应的故障原因：PERFORMANCE：如果计算实例上的 GPU 的性能低于集群中的其他 GPU，并且您在日志中未看到任何 XID 错误，也未检测到其他异常故障模式（例如静默数据损坏），请使用此值。SDC：如果发现数据损坏但没有系统崩溃，请使用此值来表示静默数据损坏。这种数据损坏可能是由 CPU 缺陷、软件 bug（例如释放后使用或内存覆盖）、内核问题或其他缺陷造成的。此术语通常用于指代硬件引起的缺陷。XID：如果您发现某个计算实例存在 XID 对应的不可恢复的 GPU 错误，请使用此值。unspecified：如果您不确定是哪种行为导致了计算实例出现问题，请使用此值。这是默认值。不过，我们建议您指定其他值之一（如果适用）。
- 根据 GKE 集群的控制平面版本调整
annotations代码块：- 1.35.6-gke.1017000 或更高版本，或 1.36.0-gke.3251000 或更高版本：保留注释块，并将
FAULT_DESCRIPTION替换为观测到的故障的文本说明。这可能包括 XID 错误代码、症状或时间戳。此说明会转发给 Compute Engine 以协助进行修复诊断，并在操作完成后自动从节点中移除。 例如：GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z。 - 早期版本：从命令中移除整个
annotations块。在这些版本中，fault-description字段不会转发到 Compute Engine，也不会自动从节点中移除。请改为与您的客户支持团队或 Cloud Customer Care 联系，以提供故障详情。
- 1.35.6-gke.1017000 或更高版本，或 1.36.0-gke.3251000 或更高版本：保留注释块，并将
- 将
reservationOperationalMode 字段。
下表总结了两种可用的预留运行模式（全容量模式和受管模式）的故障主机进程：
全容量模式 (ALL_CAPACITY) |
托管模式 (HIGHLY_AVAILABLE_CAPACITY) |
|
|---|---|---|
| 支持的机器类型 | A4X Max 和 A4X | A4、A3 Ultra、A3 Mega 和 A3 High |
| 故障主机报告 API 速率限制 | 无速率限制。 | 对 API 的调用可能会受到速率限制。 |
| 有故障的主机报告流程 |
当您为以全容量模式运行的节点报告故障主机时，会发生以下情况：
|
当您为以受管模式运行的节点报告故障主机时，会发生以下情况：
|
监控操作进度
您可以使用 GKE 节点上的 cloud.google.com/report-and-replace-status 节点标签监控 GKE 操作的进度，该标签具有以下值之一：
PodsEvicted：GKE 已完成从受影响的节点驱逐 Pod。OperationRUNNING：报告故障主机的操作正在运行。OperationDONE：底层主机已被报告为有故障，并且 GKE 节点已准备好迁移到新主机。OperationFAILED：计算实例上的 API 因配额限制或其他基础设施问题而失败。如需了解此错误，请参阅排查报告故障主机 API 错误。 如需了解如何恢复，请参阅处理报告和替换故障。Error：API 调用失败，因为请求不符合上一部分中所述的某项要求。
您还可以查看 node.gke.io/report-and-replace-operation 节点标签，以查看 Compute Engine 操作 ID，从而监控操作的状态。
您可以使用以下命令查看这两个节点标签：
kubectl get nodes NODE_NAME \
-L cloud.google.com/report-and-replace-status,node.gke.io/report-and-replace-operation
如果发生 API 错误，GKE 会将 cloud.google.com/report-and-replace-status 节点标签设置为 Error。如果发生操作失败，GKE 会将标签设置为 OperationFAILED。在这两种情况下，GKE 都会移除 cloud.google.com/fault-behavior 节点标签。此外，在 GKE 1.35.6-gke.1256000 版或更高版本，或者 1.36.0-gke.4060000 版或更高版本中，GKE 会向节点应用 cloud.google.com/report-and-replace-failed:NoSchedule 污点。此污点可防止在新节点上调度新的 Pod，从而确保工作负载不会放置在可能存在故障的主机所在的节点上。如需了解详情，请参阅处理报告和替换失败。
如需了解如何跟踪“报告主机故障”操作的详细状态，请参阅查看“报告主机故障”操作。
处理报告和替换失败
当报告并替换操作失败时，GKE 会将 cloud.google.com/report-and-replace-failed:NoSchedule 污点应用于受影响的节点。此污点会使节点保持封锁状态，以便在底层主机可能仍存在故障时，不会在该节点上调度新的工作负载。
检查是否存在故障污点
如需检查节点是否具有 report-and-replace 故障污点，请运行以下命令：
kubectl describe node NODE_NAME | grep "report-and-replace-failed"
从报告和更换失败中恢复
如需从报告和替换失败中恢复，请执行以下操作之一：
通过将
cloud.google.com/fault-behavior标签重新应用于节点来重试操作。如果重试成功，GKE 会自动移除cloud.google.com/report-and-replace-failed:NoSchedule污点：kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON如果您已确定节点运行正常或想要恢复其服务，请手动移除污点：
kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-
后续步骤
了解如何通过拓扑感知调度安排 GKE 工作负载。
了解如何使用 NCCL/gIB 优化集群网络。
了解如何排查报告故障主机 API 错误。