单副本 Deployment 更新 Multi-Attach：检查 RWO 卷与更新策略

Deployment 平时只有一个副本，更新镜像后新 Pod 却停在 ContainerCreating，事件提示 Multi-Attach error 或 Volume is already used by pod(s)。PVC 已经 Bound 时，先检查旧 Pod 是否仍在另一节点使用同一块卷，以及当前更新策略是否允许新旧 Pod 同时存在。

这条路径适用于存储后端限制跨节点同时挂载的 ReadWriteOnce 卷。RWO 描述单节点读写能力，同节点上的多个 Pod 仍可能使用它；不能把“一个副本”直接理解为任何时刻都只有一个 Pod。

对照同一轮更新的两个 Pod

下面为只读检查示例，名称与命名空间需要替换：

kubectl get pods -n team-app -o wide
kubectl describe pod app-new -n team-app
kubectl get deployment app -n team-app -o yaml
kubectl get pvc -n team-app

确认新旧 Pod 都属于这次 Deployment 更新、引用同一 PVC，并查看各自节点、状态和挂载事件。旧 Pod 在节点 A 正常运行，新 Pod 在节点 B 等待同一卷附加，才符合这条并存冲突路径。

Deployment 默认使用 RollingUpdate。单副本的默认比例允许更新时额外创建 Pod，并保留旧可用 Pod。如果新 Pod 只有等旧 Pod 释放卷才能启动，而控制器又等待新 Pod 可用才缩减旧副本，更新就可能卡住。

PVC 尚未绑定、存储类无法供应卷、节点不可用或旧挂载无法正常脱离，则需要按对应事件继续检查。不要只因出现 Multi-Attach 就修改存储权限，更不要删除 PVC 试图清除占用。

可以停机的单副本应用，考虑 Recreate

业务允许更新期间短暂停机时，可在保存原 Deployment 清单与可恢复数据备份后，将更新策略改为 Recreate。以下是需合并进现有 Deployment 的局部配置：

spec:
  replicas: 1
  strategy:
    type: Recreate

切换时移除原 strategy.rollingUpdate 配置；它不适用于 Recreate。其余 selector、Pod 模板、镜像、卷引用等按原部署保留，不要用这个片段替换整份清单。

Recreate 在 Deployment 升级时等待旧版本 Pod 移除，再创建新版本。应用从旧实例停止到新实例真正可用之间会离线，存储脱离与重新附加也可能耗时。先安排维护窗口、确认新镜像能启动并保留回退版本，不能把它当成零停机方案。

该策略不保证手动删除 Pod 时也按同样顺序替换。手动删除由 ReplicaSet 补充副本，旧 Pod 仍在 Terminating 时就可能创建替代实例。旧节点失联、存储脱离失败时，也不能通过强制删除对象证明真实挂载已经释放。

必须持续服务时，重新评估存储和应用模型

强行把新旧 Pod 调度到同一节点，可能避开跨节点附加冲突，但会增加节点依赖；同卷的多个写入者是否安全，还由应用决定。不能仅凭它们都启动就认定并发写入正确。

需要多节点并存时，应选实际支持所需访问能力的存储，并核对应用是否支持共享数据。把 PVC 文本里的 RWO 改成 RWX，不会让原有磁盘获得多节点读写能力；存储迁移需要独立规划、数据备份与一致性检查。

ReadWriteOncePod 用于限制单个 Pod 访问，CSI 支持条件与组件版本需要核对，Kubernetes 1.29 起该能力稳定。它也不会让两个更新实例同时使用同一卷。StatefulSet 提供不同的身份与卷管理方式，但不能只改 kind 就完成应用迁移，也不能修复存储后端的异常脱离。

看挂载恢复，也看应用数据

更新完成后，确认旧 Pod 已退出、原卷已从旧节点正常释放，新 Pod 的附加与挂载成功，且实际读取的是预期数据。继续检查就绪状态、业务请求和写入一致性；Pod Running 并不单独证明数据正确。

调整策略后若仍卡在 Multi-Attach，保留事件与存储控制器日志，沿旧节点、CSI 与后端附加状态排查。强制解除附加必须遵守存储供应商的恢复流程，确认旧写入者确实停止，避免双写损坏。

回退时恢复此前保存的镜像与部署配置，确认该组合能使用当前数据格式。恢复 RollingUpdate 可能再次出现同样的并存冲突；数据格式已经变更时，镜像回退也不会自动恢复数据。整个处理过程保留 PV、PVC 和真实存储，不把删卷当作释放节点占用的快捷办法。