StatefulSet能为Pod提供稳定名称、稳定网络标识和稳定存储声明，但它并不会自动保证数据永不丢失。数据是否安全，取决于PVC生命周期、PV回收策略、存储后端、应用复制机制、升级流程和备份恢复能力。很多事故并非由Kubernetes本身造成，而是删除资源、缩容、回收策略、初始化脚本或恢复流程处理不当，导致旧数据被覆盖或无法重新挂载。
先理解StatefulSet保护了什么
StatefulSet保护的是有序身份，而不是业务数据本身。比如web-0、web-1这样的Pod名称会保持稳定，volumeClaimTemplates会为每个副本创建独立PVC，Pod重建后通常会重新挂载自己的PVC。这能降低无状态Deployment在有状态场景中的混乱，但不等于备份、容灾和一致性。
真正的数据安全要看三个层次。第一，Pod重建时能否挂回原PVC；第二，PVC是否会因缩容、删除StatefulSet或回收策略而被误删；第三，底层存储损坏或人为覆盖后是否有可恢复副本。只满足第一层，只能应对普通Pod漂移，不能应对误操作和存储故障。
volumeClaimTemplates要设计清楚
StatefulSet通常通过volumeClaimTemplates为每个副本创建PVC。它适合数据库分片、消息队列节点、搜索节点等每个副本拥有独立数据目录的场景。命名规则相对稳定，有利于排查和恢复，但也要求容量、访问模式和StorageClass在上线前设计清楚。
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast-ssd
resources:
requests:
storage: 100Gi不要为了方便把多个副本写到同一个共享目录，除非应用本身支持并发写入、锁机制和数据一致性。许多中间件要求每个节点独占数据目录，共享卷反而会带来覆盖、锁冲突或索引损坏。
PVC保留策略和回收策略要双重检查
避免数据丢失的重点之一，是明确删除StatefulSet、缩容和删除PVC时会发生什么。Kubernetes较新版本支持persistentVolumeClaimRetentionPolicy，用于控制StatefulSet删除或缩容时PVC是否保留。生产环境通常更倾向于保留PVC，避免应用资源删除带走数据。
PV的reclaimPolicy同样关键。Retain会在PVC删除后保留底层存储，便于人工确认和恢复；Delete可能会让底层卷随PV删除而释放。对于承载核心数据的存储类，不建议默认使用会直接删除底层数据的策略，除非已经有成熟备份和审批流程。
kubectl get pv
-o custom-columns=NAME:.metadata.name,RECLAIM:.spec.persistentVolumeReclaimPolicy,STATUS:.status.phase滚动升级前先建立恢复点
StatefulSet滚动升级看起来安全，因为它按序更新Pod，但有状态服务的风险在于新版本可能修改数据格式、执行自动迁移或触发重新初始化。升级前应确认版本兼容性、备份状态、回滚策略和探针设置。对于数据库和消息系统，回滚应用镜像不一定能回滚数据格式。
建议在升级前至少完成三件事：创建快照或应用级备份；确认恢复步骤可执行；把初始化脚本设计成幂等，避免容器重启时误清空数据目录。很多数据丢失事故来自入口脚本判断目录为空的逻辑不严谨，或把挂载失败的空目录当作新数据盘初始化。
扩缩容要理解副本与数据关系
StatefulSet缩容时通常会删除序号较大的Pod，但PVC可能保留。再次扩容时，新Pod可能重新挂载原PVC。这对恢复副本有帮助，但也可能让旧数据与新集群配置不匹配。对于分布式系统，缩容不是简单减少Pod，还涉及数据迁移、副本再平衡、成员移除和集群元数据更新。
扩容时也要避免把新副本直接加入生产写路径。更稳妥的流程是先创建PVC和Pod，等待数据同步或再平衡完成，再放开流量或调整副本权重。应用层健康和Kubernetes就绪探针要配合，不能只以容器进程存在作为可服务标准。
备份恢复要覆盖单副本和整集群
StatefulSet恢复不是只恢复一个PVC。对于单副本数据库，恢复一个卷可能就能启动；对于多副本系统，还要考虑成员ID、集群配置、日志位置和复制关系。恢复旧快照到新副本时，可能导致脑裂、数据回退或副本拒绝加入。
建议把恢复场景拆成三种：单个Pod数据损坏、整个StatefulSet误删、跨集群迁移。单Pod恢复强调序号和PVC对应关系；整体恢复强调资源清单、Secret、ConfigMap、Service和PVC一起恢复；跨集群迁移还要处理StorageClass、拓扑和访问地址变化。
权限与操作边界也能防丢数据
技术策略之外，权限治理同样重要。生产命名空间中删除PVC、修改StorageClass、删除StatefulSet和修改回收策略都应纳入高风险操作。可以通过RBAC限制普通发布人员删除PVC，通过准入策略阻止关键PVC使用不安全回收策略，通过审计日志追踪谁在何时修改了有状态资源。
对于平台团队，可以把关键StatefulSet加上保护标签，并在备份控制器、巡检脚本和告警规则中识别。一旦发现关键PVC没有备份策略、PV使用Delete回收策略或容量接近上限，应提前告警，而不是等写满或误删后处理。
常见问题
删除StatefulSet会删除PVC吗？ 这取决于集群版本、StatefulSet保留策略和具体删除方式。生产环境不要凭经验判断，删除前应查看PVC保留策略，并先导出资源和确认备份。即使PVC保留，关联的Service、Secret和配置也可能被删除，需要整体恢复视角。
StatefulSet是否适合所有数据库？ 不一定。它适合需要稳定身份和持久卷的服务，但数据库还需要复制、备份、故障切换和版本治理。对于复杂数据库，使用成熟Operator或托管数据库通常更稳妥。
缩容后保留下来的PVC可以直接删除吗？ 不要直接删除。先确认对应副本是否已经完成数据迁移、再平衡或成员移除，并确认备份可用。保留PVC通常是一道安全缓冲，删除它意味着放弃本地恢复点。
如何判断恢复是否成功？ 不能只看Pod Running。应检查应用日志、数据版本、业务读写、复制状态、成员列表、监控指标和关键接口。对有状态服务而言，Running只是基础状态，可服务和数据一致才是恢复目标。
转载请注明出处：https://www.cloudnative-tech.com/p/7451/
