K8s删除应用资源重部署时如何复用原有持久卷保留共享数据

你遇到的所有场景问题都可以通过K8s原生能力解决，完全不需要调整现有Kustomize操作流程、不需要依赖定期备份恢复，就能实现删除整套资源后重新apply自动复用原存储卷、不创建新卷、不丢数据的目标。

前期踩坑的根因梳理 #

你之前的四次尝试都卡在PVC/PV的生命周期绑定逻辑上，核心问题点：

• 集群默认StorageClass的回收策略是Delete，PVC被真正删除后会连带后端云存储卷被回收清空，直接丢数据
• 就算用了Retain回收策略的StorageClass，PVC被删除后对应的PV会立刻进入Released状态，系统自动绑定逻辑会直接跳过这个PV，触发CSI创建全新的云卷，完全不会复用旧卷
• 想通过把PVC从yaml里移除绕开删除逻辑，又和现有Kustomize删除流程不兼容，没法灵活排除资源
• StatefulSet的卷是按Pod序号一一对应生成的，天生不支持多工作负载共享同一块卷，本身就不适合这个场景

最可靠的落地方案（适配现有所有操作流程） #

只需要对现有配置做两个调整，完全不需要修改原有apply/delete的命令逻辑、不需要调整Kustomize的目录结构拆分：

1. 强制PVC绑定到自定义的Retain策略StorageClass，不要用集群默认的Delete策略SC
2. 给PVC配置固定选择器，匹配PV上的固定标签，同时搭配轻量的PV状态自动修复逻辑，解决Released状态PV不自动绑定的问题

具体调整后的配置：

• StorageClass部分完全保留原有配置，确保reclaimPolicy: Retain、volumeBindingMode: WaitForFirstConsumer
• PVC部分做两个改动：

  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: media
  spec:
    storageClassName: retaining
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
    # 加固定选择器，匹配PV上的固定业务标签
    selector:
      matchLabels:
        k8s-app: media-shared-volume
  

• 动态PV创建完成后，给这个PV手动打上固定标签k8s-app: media-shared-volume，后续流程会自动维护这个标签

自动化逻辑非常简单，只需要一个1分钟周期的轻量CronJob，遍历所有带上述标签的PV，如果检测到PV处于Released状态，就执行一次patch操作清空PV的spec.claimRef字段，让PV回到Available状态，等待新PVC自动绑定。这个逻辑的代码量不到20行，没有复杂的依赖。

全流程执行效果 #

用调整后的配置跑你原有的三段操作，全程无人工干预：

1. 第一次执行k apply -f pv-issue.yaml：
   • StorageClass创建完成，回收策略为Retain
   • PVC创建完成，触发CSI动态创建PV，给PV打上固定的业务标签，完成绑定
   • 两个Deployment启动，因为两个Pod都通过nodeSelector调度到同一节点，完全符合ReadWriteOnce的挂载限制（RWO仅要求卷被单个节点挂载，同节点多Pod共享挂载是原生支持的），正常写入业务数据
2. 执行k delete -f pv-issue.yaml（或Kustomize的原删除流程）：
   • Deployment、StorageClass都会被正常删除，无遗留
   • PVC被正常删除，因为StorageClass是Retain策略，后端云卷和对应的PV会被保留下来，PV进入Released状态
   • CronJob检测到这个Released状态的PV，自动patch清空spec.claimRef，PV回到Available状态
3. 第二次执行k apply -f pv-issue.yaml：
   • StorageClass重新创建，配置和之前完全一致
   • PVC创建完成，通过固定选择器匹配到之前的Available状态PV，直接完成绑定，完全不会触发CSI创建新卷的逻辑
   • 两个Deployment启动时直接挂载原有PV，直接读取存量业务数据，无数据丢失

关键注意事项 #

• 完全不需要从yaml里移除PVC，原有Kustomize的build、delete命令不需要任何修改，自然解决了之前没法灵活排除PVC的落地障碍
• 不需要改成RWX访问模式，现有nodeSelector调度逻辑已经满足两个Pod共享RWO卷的要求
• 就算StorageClass在delete的时候被删除重建，只要名字、配置和之前一致，不会影响PV和PVC的绑定关系
• 这套方案不需要依赖定期备份+重建恢复的流程，原生实现原卷的自动关联

内容的提问来源于stack exchange，提问作者justadev