pv/pvc是kubernetes原生跨节点持久化方案，通过pv抽象集群存储资源、pvc声明需求，实现应用与底层存储解耦，支持pod跨节点调度时数据持续可用。
核心问题在于：Kubernetes Pod 可能被调度到任意节点，而传统本地挂载（如 hostPath 或 Bind Mount）只在单节点有效，一旦 Pod 迁移或重启到其他节点，数据就不可见甚至丢失。
用 PersistentVolume + PersistentVolumeClaim（PV/PVC）替代 hostPath
这是 Kubernetes 原生、跨节点的持久化方案，不依赖具体宿主机路径：
- PV 是集群级资源，代表实际可用的网络存储（如 NFS、Ceph、云盘 EBS/EVS/OSSFS 等），由管理员预创建或 StorageClass 动态供应
- PVC 是用户声明，只管“我要多少空间、什么访问模式”，Kubernetes 自动绑定匹配的 PV
- 无论 Pod 调度到哪个节点，只要该节点能访问后端存储（如 NFS server 可达、CSI driver 已安装），挂载就始终有效
选对访问模式（Access Mode）
必须根据应用类型匹配 PV/PVC 的 accessModes，否则调度失败或读写异常：
- RWO（ReadWriteOnce）：适合 MySQL、PostgreSQL 等单实例数据库——仅允许一个节点挂载为读写，但可跨节点迁移（Pod 重建后在新节点重新 mount）
- RWX（ReadWriteMany）：适合需要多 Pod 同时读写的场景，如共享配置目录、文件服务——必须后端存储原生支持（如 NFS、GlusterFS、阿里云 NAS）
- ROX（ReadOnlyMany）一般用于只读分发，不解决写入持久化问题
优先使用 CSI 驱动对接网络存储
避免直接操作底层设备，让 Kubernetes 统一管理生命周期：
- CNI 插件管网络，CSI 插件管存储——例如 aws-ebs-csi-driver、aliyun-csi-plugin、nfs-subdir-external-provisioner
- CPI（Cloud Provider Interface）已逐步被 CSI 取代；CSI 支持动态 Provision（自动建卷）、Attach（块设备绑定）、Mount（节点级挂载）三阶段分离
- 部署 CSI Driver 后，只需定义 StorageClass，PVC 就能触发自动创建 PV 和后端存储卷（如 AWS EBS 卷、阿里云云盘）
本地开发环境（Docker Desktop）要绕过虚拟机陷阱
Docker Desktop 内置的 Kubernetes 实际运行在 Linux VM 中，hostPath 指向的是 VM 的路径，不是你的 macOS/Windows：
- 不要用
hostPath.path: /Users/xxx/data这类本地路径——它在 VM 里根本不存在 - 若必须用本地路径测试，改用 NFS 共享：在宿主机启动 NFS server，VM 作为 client 挂载，再通过 PV 指向该挂载点
- 更推荐方式：用
nfs-subdir-external-provisioner在 Docker Desktop 中模拟 RWX 存储，避免陷入 hostPath 误区
