K8s集群中如何防止PVC被误删及排查PVC删除操作来源

一、PVC 意外删除的防护实现方案 #

• 启用PVC原生保护机制：在PVC配置中保留kubernetes.io/pvc-protection finalizer，当PVC仍然被Pod以卷形式引用时，该finalizer会拦截删除请求，阻止PVC被直接移除
• 配置PV回收策略为Retain：修改关联存储类的默认回收策略，或直接为核心PV手动设置回收模式为Retain，即使PVC被触发删除，绑定的PV不会被自动删除，存储后端的底层卷数据也不会被直接清理，可随时重新关联恢复
• 基于RBAC做权限最小化收敛：针对非存储管理员的账号、ServiceAccount，剥离persistentvolumeclaims、persistentvolumes资源的delete操作权限，从入口层面阻断无必要的删除请求发起路径
• 配置准入控制规则做拦截：通过Kyverno、OPA/Gatekeeper这类准入策略引擎，编写规则禁止生产环境核心命名空间下的PVC直接删除，删除操作必须走专属审批流、经高权限账号二次确认后才能触发
• 为核心PVC打上专属保护标签：对接自定义准入webhook，对携带该保护标签的PVC拦截所有常规删除请求，只有持有特殊豁免权限的主体才能执行删除操作

二、PVC 删除操作来源的定位排查路径 #

• 优先查询kube-apiserver审计日志：这是定位操作来源的核心依据，筛选匹配被删除PVC的资源名称、操作类型为delete、资源类型为persistentvolumeclaims的日志条目，日志会直接携带操作发起的完整主体身份（用户/ServiceAccount信息）、请求源IP、调用的API参数、触发时间
• 结合日志中的user-agent字段区分操作来源：kubectl发起的命令行请求会携带客户端版本标识，集群内部组件发起的请求会有明确的组件名（如kube-controller-manager、存储插件provisioner），第三方运维平台、CI/CD系统发起的请求会携带对应平台的服务标识，可直接区分操作是人为手动执行、还是控制器/系统任务误触发
• 交叉关联kube-controller-manager、对应存储插件的运行日志，排查是否存在控制器逻辑异常导致的误删除场景，比如PVC绑定状态异常、存储插件bug触发的自动清理动作

注意：如果集群默认审计日志未配置全量记录规则，会导致历史操作溯源缺失，建议长期将PVC、PV等存储核心资源的写操作事件纳入审计采集范围

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