Kubernetes 上手实战（5）：存储卷与持久化

上一篇把配置与密钥从镜像剥离但 Pod 重建后可写层仍会消失。本篇区分临时卷与持久卷并用 PVC 完成一次“写入数据、删除 Pod、重新读取”的实验建立存储生命周期的正确边界。一、痛点Pod 可替换数据不能一起消失容器可写层适合临时文件不适合业务状态。容器重启、Pod 重建或迁移节点后它可能消失。emptyDir与 Pod 同生共死适合同一 Pod 内容器交换文件、缓存和临时工作区它能跨容器重启保留却不能跨 Pod 删除保留。把数据库放进 emptyDir 只是把数据事故延后。持久化涉及 PersistentVolume、PersistentVolumeClaim 和 StorageClass。PVC 表达工作负载对容量、访问模式和存储类的需求动态制备器据此创建 PVPod 引用 PVC 而不是绑定某块云盘。这个抽象让应用清单不必知道具体磁盘 ID同时保留管理员对后端、扩容与回收策略的控制。访问模式容易误解。ReadWriteOnce 表示卷可由单个节点读写不等同于只允许一个 Pod同节点的多个 Pod 可能同时使用。ReadWriteOncePod 才是集群范围单 Pod 读写但需要 CSI 支持。ReadWriteMany 需要 NFS、分布式文件系统或支持它的云存储普通块盘通常不提供。二、原理绑定、挂载和回收是三段生命周期PVC 与 PV 绑定后调度器还要考虑卷所在可用区和节点拓扑。StorageClass 使用WaitForFirstConsumer可推迟制备等 Pod 调度约束明确后再选择拓扑避免卷创建在无法使用的区域。kind 默认存储类适合学习生产必须核对制备器、扩容、快照与故障域。删除 Pod 不会删除 PVC删除 PVC 后 PV 如何处理由 reclaimPolicy 决定。Delete 常随之删除后端卷Retain 则保留并要求人工回收。两者都不是备份策略。快照也通常与源存储在同一故障域或账户关键数据应有独立备份、恢复演练和明确 RPO/RTO。下面的清单创建 PVC 和一个单副本 Deployment。initContainer 仅在文件不存在时写入初值主容器通过 HTTP 提供该文件。单副本是因为示例文件不是并发安全数据库真实数据库优先使用成熟 Operator 或托管服务。apiVersion:v1kind:PersistentVolumeClaimmetadata:name:web-dataspec:accessModes:-ReadWriteOnceresources:requests:storage:256Mi---apiVersion:apps/v1kind:Deploymentmetadata:name:web-storagespec:replicas:1selector:matchLabels:app.kubernetes.io/name:web-storagetemplate:metadata:labels:app.kubernetes.io/name:web-storagespec:initContainers:-name:initializeimage:busybox:1.36.1command:[sh,-c]args:-test-f /data/index.html||printf persistent-v1\n/data/index.htmlvolumeMounts:-name:datamountPath:/datacontainers:-name:webimage:nginx:1.27.4-alpineports:-name:httpcontainerPort:80volumeMounts:-name:datamountPath:/usr/share/nginx/htmlvolumes:-name:datapersistentVolumeClaim:claimName:web-data三、实现亲手证明数据跨 Pod 存活脚本检查 PVC Bound找到当前 Pod写入唯一内容然后删除 Pod 并等待新实例 Ready。最后读取文件并比较。这里不依赖 Service直接在容器内部检查减少网络因素干扰。#!/usr/bin/env bashset-euopipefailtest$(kubectl config current-context)kind-k8s-labkubectl apply-fstorage.yaml kubectlwait--forjsonpath{.status.phase}Bound pvc/web-data--timeout120s kubectl rollout status deployment/web-storage--timeout120sold_pod$(kubectl get pod-lapp.kubernetes.io/nameweb-storage-ojsonpath{.items[0].metadata.name})valuesurvived-pod-replacementkubectlexec${old_pod}--sh-cprintf %s\n ${value} /usr/share/nginx/html/index.htmlkubectlexec${old_pod}--cat/usr/share/nginx/html/index.html kubectl delete pod${old_pod}--waittrue kubectl rollout status deployment/web-storage--timeout120snew_pod$(kubectl get pod-lapp.kubernetes.io/nameweb-storage-ojsonpath{.items[0].metadata.name})test${old_pod}!${new_pod}actual$(kubectlexec${new_pod}--cat/usr/share/nginx/html/index.html)test${actual}${value}echoold_pod${old_pod}echonew_pod${new_pod}echodata${actual}kubectl get pvc web-data kubectl getpv预期旧、新 Pod 名称不同而 data 仍为survived-pod-replacement。这证明的是该集群中卷跨 Pod 重建保留不证明跨集群、跨区域或误删 PVC 后可恢复。必须区分高可用、持久化和备份三个能力。StatefulSet 适合需要稳定网络身份、稳定序号和每副本独立 PVC 的应用。它不会自动让数据库具备复制、一致性或故障转移能力。若应用本身不知道如何组建集群换成 StatefulSet 也不会得到可靠数据库。无状态前端仍应使用 Deployment。四、踩坑权限、拓扑与扩容挂载后 Permission denied 常来自镜像用户 UID 与卷所有权不一致。可以让镜像初始化正确权限或合理设置fsGroup不要为了省事长期运行 privileged 或 chmod 777。大卷递归修改权限会拖慢启动支持时可使用fsGroupChangePolicy降低重复操作。PVC Pending 时先 describe 查看事件可能没有默认 StorageClass、请求的访问模式不支持、容量不足或拓扑无法满足。Pod Pending 也可能是卷节点亲和性冲突。扩容前确认 StorageClassallowVolumeExpansion文件系统是否支持在线扩容并做好备份缩容通常不受支持。删除 Deployment 不会自动删 PVC这有利于防误删也会留下费用。清理实验应先删除 Deployment再明确确认数据不再需要后删除 PVC。生产中可用资源标签、所有者和费用告警治理遗留卷不能靠定期盲删。五、验证用恢复能力定义存储完成存储验收至少覆盖 Pod 重建、节点迁移、容量告警、卷扩容、快照创建和从备份恢复。只有最后一项在隔离环境成功才能声称备份可用。还要测应用一致性崩溃时写到一半的文件、数据库事务与文件系统快照是否一致。本篇得到的可复用方法是用 PVC 表达需求用 StorageClass 隔离后端用故障实验验证生命周期并把备份恢复独立验收。清理前可保留清单确认实验数据无价值后执行kubectl delete deployment/web-storage与kubectl delete pvc/web-data。下一篇回到无状态 web在集群中引入 Gateway API把外部请求通过 Gateway 和 HTTPRoute 路由到 Service并诊断路由为何未被控制器接受。容量规划还要区分逻辑用量、文件系统可用量和后端配额。监控卷使用率、索引节点、读写延迟、错误与队列深度并按增长速度预测耗尽时间。告警阈值应留出扩容和审批所需的操作窗口而不是到百分之九十九才通知。数据库还需监控日志盘、临时空间与复制延迟因为总容量充足也可能由局部资源耗尽导致停写。恢复演练建议新建隔离命名空间从指定时间点的备份恢复然后运行数据校验与应用只读查询记录下载、挂载、恢复和验证各阶段耗时。恢复成功后再删除演练资源保留报告而非保留敏感副本。若恢复依赖某位管理员记忆中的命令就还没有真正达到可恢复。把这些步骤自动化但对覆盖现有数据的动作保持显式审批。存储选型可先写成确定性决策而不是看到“有数据”就一律申请 PVC。下面程序根据是否需要跨 Pod、是否共享写入和数据重要性给出卷类型并拒绝本地临时卷承载关键数据。fromdataclassesimportdataclassdataclass(frozenTrue)classDataNeed:name:strsurvives_pod:boolshared_writers:boolcritical:booldefchoose_volume(need:DataNeed)-str:ifnotneed.survives_pod:returnemptyDirifneed.shared_writers:returnPVC(ReadWriteMany)returnPVC(ReadWriteOnce)needs[DataNeed(cache,False,False,False),DataNeed(uploads,True,True,True),DataNeed(database,True,False,True),]forneedinneeds:selectedchoose_volume(need)ifneed.criticalandselectedemptyDir:raiseRuntimeError(fcritical data is ephemeral:{need.name})print(f{need.name}{selected})运行输出cacheemptyDir uploadsPVC(ReadWriteMany) databasePVC(ReadWriteOnce)第二个程序模拟写入校验和、Pod 被替换、重新挂载后读取的验收逻辑。真正的集群实验应把volume替换成挂载目录但“比较原始校验和而非只看文件存在”这一验收方式保持不变。importhashlibdefchecksum(data:bytes)-str:returnhashlib.sha256(data).hexdigest()volume:dict[str,bytes]{}pod_awriter-7fd9payloadborderK8S-2026;amount128volume[/data/record.txt]payload written_hashchecksum(payload)print(fwriter{pod_a}bytes{len(payload)})delpod_a pod_breader-a314restoredvolume[/data/record.txt]restored_hashchecksum(restored)matcheswritten_hashrestored_hashprint(freader{pod_b}bytes{len(restored)})print(fchecksum_match{matches})ifnotmatches:raiseSystemExit(restored data is corrupted)print(persistencePASS)运行输出writerwriter-7fd9 bytes25 readerreader-a314 bytes25 checksum_matchTrue persistencePASS参考来源Persistent VolumesStorage ClassesVolumesStatefulSets 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《Kubernetes 上手实战》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。