409 冲突的由来
Kubernetes API 用乐观锁处理并发写入：对象带一个版本号，写回时若版本与当前不一致就拒绝本次请求并返回 409。这样能避免两个修改者互相覆盖。它不影响读取，通常是脚本、控制器或人工修改与自动控制器同时动手时才出现。
基本信息
| 适用平台 | Kubernetes 全版本，所有命名空间级与集群级资源 |
|---|---|
| 报错关键字 | Operation cannot be fulfilled，the object has been modified |
| HTTP 状态码 | 409 Conflict |
| 典型触发 | 并发修改、控制器无条件重写、脚本反复提交旧文件 |
| 正确做法 | 重新读取最新版本，合并改动后再写回 |
典型触发场景
- 对同一部署连续执行两次基于旧输出的编辑命令
- 自研控制器拿到对象后长时间处理，写回时对象已被他人修改
- 脚本把固定的一份 YAML 反复 apply，字段却已被集群侧改写（例如副本数被自动扩缩容调整）
- 人工在控制台改了注解，同时流水线带着旧版本提交
- 多个 Operator 同时管理同一个自定义资源
报错与对策
报错与对策
kubectl apply -f deploy.yaml # 失败时提示对象已被修改
# Operation cannot be fulfilled on deployments.apps "web": the object has been
# modified; please apply your changes to the latest version and try again
kubectl get deploy web -o yaml > web.yaml # 取回最新版本
# 在最新版本上合并自己的改动，再提交
kubectl apply -f web.yaml
kubectl rollout status deploy/web # 改完确认滚动结果常见场景与处理
| 场景 | 表现 | 处理方式 |
|---|---|---|
| 命令行并发修改 | 第二次编辑报 409 | 重新取回对象再改，缩短两步之间的间隔 |
| 控制器写回 | 日志中反复出现冲突 | 处理时采用重试，冲突后重新读取再计算 |
| 自动扩缩容介入 | 副本数被改回 | 脚本不要硬写副本数，交给自动扩缩容管理 |
| 流水线重复发布 | 偶发发布失败 | 发布前拉取最新对象，避免使用长期缓存的清单 |
资源版本号是集群内部的修改序号，只用于并发控制，不要人工指定或跨对象比较大小；它也不能当作业务数据的版本号使用。
不要用强制覆盖的手段绕过冲突。绕过乐观锁意味着你可能会静默丢掉别人的改动，包括自动扩缩容刚调的副本数或运维刚加的注解。