当ECI实例因库存不足等原因创建失败时，系统默认会自动重试，实例保持调度中状态，直到创建成功或触及重试上限。如果您希望尽快拿到创建结果，以便由上层编排及时处理故障，可以通过注解修改实例的故障处理策略，在成功率与交付效率之间做取舍。
配置说明
在创建ECI实例时，通过注解k8s.ctyun.cn/eci-fail-strategy指定故障处理策略。该注解决定实例创建失败后是否重试。
注意
- 注解仅在创建实例时生效。实例创建后修改注解不会改变已有策略，实际生效的策略固化在
Status.FailStrategy字段中。 通过Kubernetes工作负载创建时，注解需添加在
spec.template.metadata.annotations下；直接调用创建接口时，注解放在请求体的annotations字段中。
k8s.ctyun.cn/eci-fail-strategy的取值说明如下：
| 取值 | 说明 | 适用场景 |
|---|---|---|
| fail-back | 创建失败后自动重试。实例保持调度中状态，直到创建成功或达到重试上限。未设置该注解时使用此值 | 侧重成功率，可以接受实例延迟交付 |
| fail-over | 失败转移，行为与fail-back完全一致，用于兼容已有模板 | 同fail-back |
| fail-fast | 快速失败。创建失败后立即进入失败终态，不进行重试，由上层编排决定是否重建或改调度到其他资源 | 侧重效率，希望实例快速交付，且上层已有完善的失败处理逻辑 |
如果注解值为空或无法识别，系统按fail-fast处理，并在实例事件中记录非法取值，避免因配置错误导致无限重试。
配置示例
以下示例创建一个故障处理策略为fail-fast的实例。当实例因库存不足创建失败时，系统直接返回失败，不再重试。
{
"containerGroupName": "test-fail-strategy",
"cpu": 1,
"memory": 2,
"annotations": {
"k8s.ctyun.cn/eci-fail-strategy": "fail-fast"
},
"containers": [
{
"name": "nginx",
"image": "nginx:latest"
}
]
}通过 Kubernetes 工作负载创建时，注解的放置方式如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
spec:
replicas: 1
selector:
matchLabels:
app: test
template:
metadata:
labels:
app: test
annotations:
k8s.ctyun.cn/eci-fail-strategy: "fail-fast" # 创建失败后直接报错，不再重试
spec:
containers:
- name: nginx
image: nginx:latest结果验证
实例创建后，可通过查询接口查看实例状态。与故障处理策略相关的字段如下：
| 字段 | 含义 |
|---|---|
| status.failStrategy | 实际生效的策略，取值为fail-back、fail-over或 fail-fast |
| status.retryTimes | 当前策略下已重试的次数，用于运维与审计 |
| status.retryDeadline | 重试截止时间，首次重试时初始化。超过该时间后不再重试 |
| status.lastScheduleError | 最近一次调度失败的原因 |
| status.phase | 实例所处阶段。重试期间为Scheduling，失败终态为ScheduleFailed |
fail-back策略重试中的状态示例如下：
{
"status": {
"phase": "Scheduling",
"failStrategy": "fail-back",
"retryTimes": 2,
"retryDeadline": "2026-11-02T10:20:00Z",
"lastScheduleError": "FlavorSoldOut: the specified flavor is out of stock"
}
}fail-fast策略创建失败后的状态示例如下：
{
"status": {
"phase": "ScheduleFailed",
"failStrategy": "fail-fast",
"retryTimes": 0,
"lastScheduleError": "FlavorSoldOut: the specified flavor is out of stock"
}
}重试行为说明
仅对可恢复的调度错误重试。库存不足、规格售罄、虚机创建任务失败等错误会触发fail-back重试；参数非法、配额超限等确定性错误不会重试，两种策略下都直接失败。
重试有双重上限。默认最多重试 5 次，且总重试时长不超过 600 秒（自创建起算）。任一条件先到达即停止重试，实例进入ScheduleFailed。
规格队列优先。对于配置了规格队列的实例，创建失败时优先尝试队列中的下一个规格，该过程不受可恢复错误范围限制；只有规格队列耗尽后，才按当前策略进行同规格重试。未配置规格队列的实例直接按策略处理。
重试计数不清零。retryTimes为累计值，实例最终创建成功后仍保留，用于审计。
故障排查
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| phase为Scheduling，retryTimes持续递增 | 实例正在按fail-back重试 | 等待库存恢复，或补充其他规格、可用区 |
| phase为Scheduling，retryTimes长时间不变，且已超过retryDeadline | 重试已停止，但状态尚未刷新 | 触发一次状态查询；仍未变化时按创建失败处理 |
| phase为ScheduleFailed，retryTimes为 0，lastScheduleError有值 | 策略为fail-fast，或失败原因属于不可恢复错误 | 根据lastScheduleError修改规格、可用区或参数后重建 |
| failStrategy与创建时的注解不一致 | 创建后修改了注解 | 修改注解不会生效，需按目标策略重新创建实例 |
| 注解为fail-back，但实例立即失败 | 失败原因不在可恢复范围内，或规格队列已耗尽且重试额度用完 | 查看lastScheduleError确认原因 |
使用限制
故障处理策略只在创建时确定，创建后不可变更。
fail-fast与延迟绑定类型的存储卷存在冲突：当实例挂载的存储卷需要等到 Pod 调度后才创建时，快速失败可能导致存储卷停留在待创建状态。此类场景建议使用fail-back。
重试上限与时间窗为实例级配置，由平台统一设置，不支持按实例单独指定。
常见问题
创建成功后修改注解，能否切换故障处理策略？
不能。策略在创建时解析并固化到 status.failStrategy，之后修改注解不生效。需要切换策略时，请重新创建实例。
为什么 fail-fast有时不是立刻失败？
fail-fast的语义是"遇到可重试错误时不重试"。如果失败原因是参数非法等确定性错误，两种策略都会直接失败；如果实例配置了规格队列，系统仍会先尝试队列中的其他规格。
实例创建成功后，retryTimes会清零吗？
不会。retryTimes是累计计数，用于运维和审计，创建成功后保留。
如何区分"正在重试"和"已经卡住"？
同时查看三个字段：retryTimes是否递增、retryDeadline是否未过期、是否有重新调度事件。三者任一不再变化，说明重试已经停止。
