尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
Kubernetes 存储实战:PVC 动态供给与 Pod 重启后数据丢失排查
Kubernetes 存储实战:PVC 动态供给与 Pod 重启后数据丢失排查写数据库、写上传文件、写缓存,只要 Pod 里的进程往磁盘写东西,你迟早会撞上同一个问题:Pod 一重启,数据全没了。很多人第一反应是「加个 volume 不就行了」,结果加了emptyDir发现重启照样丢,或者用了 PVC 却发现多副本时数据对不上。这篇把动态供给讲清楚,再把「重启后数据丢失」这个最高频的坑逐层拆开。先搞清楚:emptyDir 为什么救不了你新手最容易写出这样的 volume:apiVersion:v1kind:Podmetadata:name:demospec:containers:-name:appimage:busyboxcommand:[sh,-c,echo hi /data/log.txt; sleep 3600]volumeMounts:-name:cachemountPath:/datavolumes:-name:cacheemptyDir:{}# 生命周期绑定 Pod,Pod 没了目录就没了emptyDir的生命周期和 Pod 绑定。容器崩溃重启(同一个 Pod 内)数据还在,但 Pod 被删除重建(滚动更新、节点驱逐、kubectl delete pod)时,emptyDir会被清空。它的定位是「临时暂存」,不是持久化。要跨 Pod 生命周期保留数据,必须用PersistentVolume(PV)。动态供给:别再手写 PV早期用法是管理员先手动创建一堆 PV,用户再用 PVC 去认领。规模一大就崩溃。现在的标准做法是动态供给:你只声明「我要多大、什么类型」,StorageClass背后的 provisioner 自动帮你开一块盘。先看集群有哪些 StorageClass:kubectl get storageclass# NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE# standard (default) k8s.io/minikube-hostpath Delete Immediate# gp3 ebs.csi.aws.com Delete WaitForFirstConsumer带(default)的是默认类。写 PVC 时不指定storageClassName就用它:apiVersion:v1kind:PersistentVolumeClaimmetadata:name:data-pvcspec:accessModes:-ReadWriteOnce# 单节点读写,最常用resources:requests:storage:5GistorageClassName:gp3# 显式指定,别依赖默认类应用到 Deployment:apiVersion:apps/v1kind:Deploymentmetadata:name:webspec:replicas:1selector:matchLabels:{app:web}template:metadata:labels:{app:web}spec:containers:-name:webimage:nginxvolumeMounts:-name:datamountPath:/usr/share/nginx/htmlvolumes:-name:datapersistentVolumeClaim:claimName:data-pvc现在 Pod 重启、重建,/usr/share/nginx/html里的数据都还在——只要 PVC 没被删。坑一:PVC 一直 Pending,Pod 也起不来kubectl get pvc看到Pending,先看事件:kubectl describe pvc># Events:# Warning ProvisioningFailed ... no volume plugin matched常见三种原因:storageClassName写错或集群根本没这个类。kubectl get sc核对名字。VolumeBindingMode 是WaitForFirstConsumer。这不是错误——它故意等到有 Pod 调度了才创建卷(为了把卷开在 Pod 所在的可用区)。此时 PVC Pending 是正常的,等 Pod 调度上去就会 Bound。如果 Pod 也 Pending,去查 Pod 的调度事件。底层配额不足,比如云账号 EBS 卷数量到上限。看 provisioner 的日志。坑二:多副本时数据「对不上」——ReadWriteOnce 的真相把上面的replicas改成 3,你可能会发现 3 个 Pod 看到的数据不一致,甚至有 Pod 卡在ContainerCreating。原因在accessModes。ReadWriteOnce(RWO)的含义是同一时刻只能被一个节点挂载读写。多个副本如果被调度到不同节点,后面的 Pod 挂不上卷:kubectl describe pod web-xxx# Warning FailedAttachVolume Multi-Attach error for volume pvc-...# Volume is already exclusively attached to one node三种访问模式记牢:模式缩写语义ReadWriteOnceRWO单节点读写(块存储,如 EBS)ReadOnlyManyROX多节点只读ReadWriteManyRWX多节点读写(需 NFS、CephFS 等文件存储)结论:多副本共享写数据,要么用支持 RWX 的存储(NFS/CephFS),要么改架构——用StatefulSet给每个副本一块独立的 PVC。坑三:重启后数据还是丢了——三个隐藏杀手你明明用了 PVC,数据却还是没了。逐个排查:1. ReclaimPolicy 是 Delete,PVC 被删了kubectl getpv# RECLAIM POLICY: DeleteDelete策略下,删除 PVC 会连带删掉 PV 和底层云盘。如果你的 CI 脚本或helm uninstall删了 PVC,数据就真没了。生产环境重要数据把 StorageClass 的reclaimPolicy设成Retain,删 PVC 后 PV 保留、数据还在,可手动恢复。2. subPath 挂错,写进了容器层volumeMounts:-name:datamountPath:/app/datasubPath:prod# 卷内的子目录如果应用实际写的是/app/logs而不是/app/data,那/app/logs还在容器可写层里,重启就没。确认应用的写入路径和mountPath完全一致,进容器df -h看目标目录是不是挂载点:kubectlexec-itweb-xxx --df-h/app/data# Filesystem ... Mounted on# /dev/nvme1n1 ... /app/data ← 是独立设备才说明挂上了如果Mounted on显示的是overlay(容器根文件系统),说明根本没挂上卷,写的都是临时数据。3. StatefulSet 缩容删了 PVCStatefulSet缩容默认不会删 PVC(这是有意保护数据)。但如果你手动kubectl delete pvc,或者设了persistentVolumeClaimRetentionPolicy: Delete,缩容时 PVC 就被回收了。检查:kubectl get statefulset db-oyaml|grep-A3RetentionPolicy一个能落地的排查顺序数据丢失时,按这个顺序查,基本 5 分钟定位:# 1. Pod 到底挂没挂上卷?kubectlexec-itpod--df-hmountPath# 看是不是 overlay# 2. PVC 是不是 Bound?kubectl get pvc# 3. PV 的回收策略?会不会被连带删除?kubectl getpv-ocustom-columnsNAME:.metadata.name,POLICY:.spec.persistentVolumeReclaimPolicy# 4. 应用写入路径 vs mountPath/subPath 对得上吗?kubectl get podpod-oyaml|grep-A5volumeMounts小结emptyDir是临时暂存,Pod 重建即清空,别拿它做持久化。动态供给靠StorageClass,PVC 只声明「多大 什么类」,provisioner 自动开盘。PVC Pending 先看describe:多半是storageClassName错,或WaitForFirstConsumer在等 Pod 调度。ReadWriteOnce是单节点读写,多副本共享写要用 RWX 存储或 StatefulSet。重要数据把reclaimPolicy设成Retain,删 PVC 也不丢盘。一句话记忆点:数据丢了先df -h看目标目录是不是 overlay——是 overlay 就压根没挂上卷,别的都白查。
RELATED

相关推荐

Windows 11部署OpenClaw集成1Password技能指南

Windows 11部署OpenClaw集成1Password技能指南

1. 项目背景与核心需求在Windows 11环境下部署OpenClaw并安装1Password技能,本质上是在构建一个本地化的智能助手系统。OpenClaw作为开源AI助手框架,其模块化设计允许用户通过"技能"扩展功能。1Password作为知名密码管理工具,将其集…

📅 2026/9/19 12:32:32
大数据学习心路:从Java基础到Hadoop生态的实战闭环

大数据学习心路:从Java基础到Hadoop生态的实战闭环

1. 从迷茫到清晰:我的大数据学习心路历程四年前,当我第一次在专业导论课上听到“大数据”这个词时,脑子里一片空白。它听起来既宏大又遥远,像是只存在于科技新闻头条里的概念。身边的同学有的已经开始讨论Hadoop、Spark&#xff0…

📅 2026/9/21 10:26:17
C++内存管理:从基础到智能指针与性能优化

C++内存管理:从基础到智能指针与性能优化

1. C内存管理基础概念在C编程中,内存管理是每个开发者必须掌握的核心技能。与Java、Python等带有垃圾回收机制的语言不同,C要求开发者手动管理内存分配和释放,这既带来了性能优势,也增加了复杂性。1.1 内存分区模型C程序运行时&am…

📅 2026/9/21 13:33:16
MORE NEWS

更多资讯

📰

2026最新疯狂坦克2官网转岗避坑:5个高频面试真题拆解

2026最新疯狂坦克2官网转岗避坑:5个高频面试真题拆解 看了一堆教程还是不会写项目?别怪你笨,是你学的东西和面试官想听的脱节了。很多转行的朋友,手里攥着几个烂大街的CRUD项目,去面试大厂还是被刷得干干净净。…

📰

fputs函数底层原理与最佳实践深度解析

fputs函数底层原理与最佳实践深度解析 盯着屏幕上一长串红色的报错信息,Stack Trace里的每一行都像天书,让人瞬间大脑宕机。你明明只是想把数据写进文件,结果程序直接崩溃,或者数据丢了,这种无力感在开发初期尤为强烈。这时候,掌握fp…

📰

EMQX Durable Storage 事务配置运行时热更新:原理、配置与源码解析

后端物联网消息队列通信 【免费下载链接】emqx The most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles 项目地址: https://gitcode.com/gh_mirrors/em/emqx 点击查看 免费下载 EMQX 的 Durable Storage(持久化存储&…

📰

西贴网实战:搞定高频面试题,项目不再从零开始

西贴网实战:搞定高频面试题,项目不再从零开始 你是不是也这样?书上的语法背得滚瓜烂熟,LeetCode 题也刷了几百道,可一让搭个真实项目,脑子就一片空白?更扎心的是,去面试时遇到那些 高频面试题 ,明明觉得会,但一结合业务场景就卡壳。…

📰

北京枪击事件后端逻辑手写实现避坑指南

北京枪击事件后端逻辑手写实现避坑指南 复制来的代码跑不通,报错信息像天书一样看不懂,这种绝望感每个后端开发者都体会过。特别是处理像“北京枪击事件”这类高敏感、高并发、强实时性的业务模块时,现成的开源库往往因为版本迭代或环境差异,直接导致服务…

📰

单证硕士怎样转为双证面试必问

3个坑让单证硕士转双证卡壳实战项目经验全解析 版本升级后 API 全变了,这不是代码库的噩梦,也是很多在职人员从单证硕士转向双证硕士时的真实写照。我见过太多同学在备考过程中,因为没搞懂政策底层逻辑,把精力全花在了错误的复习方向上,甚至错过了…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬