本文介绍如何在 VCI 场景下，通过故障处理策略开启 Pod 快速失败（Fail-fast）能力。当 VCI 实例因库存不足、规格不可用等原因创建失败时，系统可快速返回失败结果并透出明确标识，帮助用户及时感知并切换到备用方案（如从规格族 A 切换到规格族 B），避免长时间无效等待。

背景信息

默认情况下，VCI Pod 创建失败后会自动重试，通过退避算法持续尝试直至实例创建成功，适用于对成功率敏感、可等待库存的场景。但在 GPU 等稀缺资源场景下，该机制会导致 Pod 长时间 Pending 并反复重试，需要用户等待 2~5 分钟才能确认失败，不满足实际业务场景需求。

为此，VCI 提供故障处理策略（Fail-strategy）, 支持在 Pod 上声明快速失败行为，资源创建类任务失败时不再长时间重试，而是快速判定并透出明确失败原因，将确认失败的耗时从分钟级缩短到秒级。

功能说明

Pod 快速失败能力通过在 Pod 上添加 Annotation 来开启。核心 Annotation 说明如下所示。

Annotation Key	Annotation Value 示例值	说明
vci.volcengine.com/fail-strategy	fail-fast	用于声明 VCI Pod 创建失败后的处理方式。取值如下： fail-back：（默认值）失败自动恢复，即 Pod 创建失败后系统自动尝试重新创建，通过退避算法持续重试直至创建成功。 fail-fast：快速失败，即 Pod 创建失败后直接报错，不再进行长时间重试，同时透出明确的失败标识（status.reason）：CreatePodError。开启 fail-fast 后的 Pod 行为如下：当资源创建类任务失败时，系统立即回滚创建流程，不再长时间重试。 Pod 的status.phase保持为 Pending，并通过失败原因（Reason）透出快速失败标识（如 CreatePodError）。上层工作负载（如 Deployment、StatefulSet）可根据该失败原因识别快速失败，并触发 Pod 重建；用户据此可快速切换到备用规格。原生 Kubernetes 默认不会自动重建，需由用户自定义的工作负载控制器处理。

使用限制

使用 VCI Pod 快速失败能力时，请注意以下限制。

限制项	说明
仅创建 Pod 任务支持快速失败	快速失败仅对创建 Pod 生效，其他类型的任务创建失败后仍会按默认逻辑重试。
重建依赖上层工作负载	原生 Kubernetes 默认不会对快速失败的 Pod 自动重建，需由 Deployment、StatefulSet 等自定义工作负载控制器根据失败原因触发重建。

前提条件

已创建 VCI 业务所需的集群。详细操作，请参见在 VPC-CNI 网络模型集群中使用 VCI、在 Flannel 网络模型集群中使用 VCI。

已准备好备用方案，以便在快速失败后及时切换。切换方案示例，请参见本文下方切换备用方案。

操作步骤

下文示例以通用型规格（vci.n3a.4c-8gi）的 Deployment 为例，通过将 Pod 子网指定到 cn-beijing-a 可用区，模拟vci.n3a规格在该可用区无库存，从而验证开启快速失败后的效果。各地域和可用区支持的 VCI 规格信息，请参见地域和可用区。VCI Pod 子网配置方法，请参见管理虚拟节点。

步骤一：在工作负载中声明快速失败策略

工作负载中通过 Pod Annotations 开启快速失败。

使用 kubectl 连接集群。详情请参见连接集群。

创建 Deployment 的 YAML 文件。示例文件vci-failfast-demo.yaml代码如下。

apiVersion: apps/v1
kind: Deployment
metadata:
name: vci-failfast-demo # Deployment 名称。
namespace: default # Deployment 所属命名空间。
spec:
replicas: 1 # Pod 数量。
selector:
matchLabels:
app: vci-failfast-demo
template:
metadata:
labels:
app: vci-failfast-demo
annotations:
vke.volcengine.com/burst-to-vci: "enforce" # 强制将 Pod 调度到 VCI。
vci.volcengine.com/fail-strategy: "fail-fast" # 开启快速失败，创建失败后立即透出失败标识，不再长时间重试，取值：fail-fast（快速失败）、fail-back（失败自动恢复）。
vci.vke.volcengine.com/preferred-instance-types: "vci.n3a.4c-8gi" # 指定 VCI 通用型规格（4 vCPU、8 GiB 内存）。
spec:
containers:
- name: nginx
image: doc-cn-beijing.cr.volces.com/vke/nginx-demo:v1.0 # 容器镜像的地址和版本，请配置为您自己的镜像地址。若使用公网镜像，请确保您的集群能够访问公网。
resources:
requests:
cpu: "4"
memory: 8192Mi
limits:
cpu: "4"
memory: 8192Mi

执行如下命令，创建 Deployment。

kubectl apply -f vci-failfast-demo.yaml

步骤二：验证快速失败是否生效

开启快速失败后，Pod 不会直接变为 Failed，而是在 Pod 的status.phase中显示状态为Pending，同时status.reason置为CreatePodError，并在status.message中给出具体失败原因，容器则停留在ContainerCreating状态。

执行以下命令，获取 Deployment 中 Pod 的名称。

kubectl get pod -l app=vci-failfast-demo -n default

预期返回结果如下：

NAME READY STATUS RESTARTS AGE
vci-failfast-demo-7c9f8d6b5-***** 0/1 ContainerCreating 0 10s

执行以下命令，查看 Pod 的status字段。

kubectl get pod vci-failfast-demo-7c9f8d6b5-***** -n default -o yaml

预期返回结果如下（节选status部分）：

status:
phase: Pending
reason: CreatePodError
message: The specified resource vci.n3a of cn-beijing-a is sold out, try other instance types of resources or other zones.
hostIP: 192.168.XX.XX
qosClass: Guaranteed
startTime: "2026-08-21T03:54:48Z"
containerStatuses:
- name: nginx
image: doc-cn-beijing.cr.volces.com/vke/nginx-demo:v1.0
ready: false
started: false
restartCount: 0
state:
waiting:
reason: ContainerCreating

步骤三：（可选）切换备用方案

上层工作负载或运维流程可根据快速失败标识，触发切换逻辑。例如在 GPU 无库存时，改为提交使用大核 CPU 规格的工作负载继续计算。下文提供两种方案，更多方案，您可以根据实际业务情况自行实现。

方案一（推荐）

方案二

通过在同一个工作负载内追加备用规格来确保业务负载成功创建并正常运行。

VCI 中指定规格/规格族的相关 Annotation（例如preferred-instance-types）支持传入多个规格/规格族，用半角逗号分隔并按前后顺序排列优先级，高优先级规格无资源时使用低优先级规格/规格族创建实例。

说明

该方案将切换动作前置到创建阶段，多数库存波动无需人工介入即可自动兜底，快速失败仅在所有候选规格都不可用时触发。

Annotation 示例如下，更多操作说明，请参见创建 VCI 实例。

容器服务