持久卷(PV)与持久卷声明(PVC)

PV 是集群层面的存储资源，PVC 是应用对存储的“申请单”。Kubernetes 会把 PVC 绑定到合适的 PV。

核心概念

PV：由管理员或存储系统提供
PVC：由应用声明需求
绑定：PVC 与 PV 一对一

常见流程

创建 PVC
自动或手动绑定 PV
Pod 通过 PVC 挂载

小建议

尽量使用 StorageClass 做动态供给
关注访问模式：ReadWriteOnce vs ReadWriteMany

实操要点

先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

资源定义与业务意图一致。
Namespace、权限、镜像与环境匹配。
上线前具备健康探针与可观测日志。

存储模型与绑定关系

Kubernetes 将“需求”和“实现”分离：PVC 描述需求，PV 描述具体存储，StorageClass 描述供给方式。PV/PVC 决定了存储如何创建、如何绑定到 Pod。

访问模式与回收策略

访问模式决定卷的使用方式：RWO 适合单写入，RWX 适合共享读写，ROX 适合只读共享。回收策略决定 PVC 删除后的行为，Delete 会移除底层卷，Retain 会保留数据。生产环境务必谨慎选择。

扩容与快照

很多存储后端支持在线扩容，但仍需确认文件系统是否需要额外扩展步骤。快照用于备份与克隆，建议用于升级演练与灾备验证。

性能与成本

存储往往是瓶颈。SSD 类更快但更贵，网络存储更灵活但延迟更高。选择 StorageClass 要基于真实 IOPS 与吞吐需求，而不是仅看容量。持续监控使用率能避免过度预留。

拓扑与可用区

部分存储只支持单可用区。要让调度与绑定一致，需配置合适的绑定模式和拓扑约束。若出现 Pending，检查可用区与卷绑定配置。

数据一致性与备份窗口

备份和快照需要考虑一致性。数据库类工作负载建议在低峰或配合一致性机制进行快照，并定期验证恢复流程，确认实际恢复时间。

运维流程

先确认 PVC 已绑定，再启动业务。监控磁盘使用与 inode 压力。迁移时预留数据复制窗口，并演练恢复流程。存储具备持久性，因此资源下线时也要清理遗留 PVC 与底层卷。

kubectl get pv
kubectl get pvc -n demo
kubectl describe pvc data-demo -n demo

实战补充

把快速入门应用到真实业务时，建议固定一套检查项：资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复，并随仓库一起维护，这样每次发布都能快速对齐标准。

排障路径

从现象入手，不要先猜原因。先看事件，再看日志，最后验证流量路径和配置版本是否一致。若访问异常，先确认 readiness 和 endpoints，再逐段排查入口到后端的链路。记录每一步改动，方便回滚和复盘。

小练习

在测试环境做几次常见操作：扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习，你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口，准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划，确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次：访问核心接口、观察延迟和错误率，确认新旧 Pod 的状态稳定。如果涉及存储或网络，顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤，包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原，而不是现场临时拼步骤。