如何在Kubernetes(k8s)集群中设置和使用Persistent Volumes (PV)和Persistent Volume Claims (PVC)？

为什么不尝试使用Dynamic Volume Provisioning结合StorageClass来自动化PV的创建，减少手动配置的复杂性呢？

在k8s里用PV和PVC分三步：1.先搞个PV，定义好存储大小、访问权限（比如只读或读写）和存储类型（比如本地硬盘或云存储）；2.创建PVC去匹配这个PV，相当于申请使用这个存储空间；3.在Pod里把PVC挂载到容器目录。比如用yaml文件定义好PV和PVC后，kubectl apply创建，最后在Pod配置里引用PVC名字就完事了。PV像库存的硬盘，PVC就是申请单，配对成功就能用啦！

1. 创建PersistentVolume（PV）

   • 定义PV资源文件（如nfs-pv.yaml），指定存储类型、容量和访问模式：

     apiVersion: v1
     kind: PersistentVolume
     metadata:
     name: my-pv
     spec:
     capacity:
      storage: 10Gi
     accessModes:
      - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain
     nfs:
      path: /nfs_share
      server: 192.168.1.100

   • 执行 kubectl apply -f nfs-pv.yaml

2. 创建PersistentVolumeClaim（PVC）

   • 定义PVC资源文件（如app-pvc.yaml），声明所需存储：

     apiVersion: v1
     kind: PersistentVolumeClaim
     metadata:
     name: my-pvc
     spec:
     accessModes:
      - ReadWriteOnce
     resources:
      requests:
        storage: 5Gi

   • 执行 kubectl apply -f app-pvc.yaml

3. 在Pod中挂载PVC

   • 在Pod定义中通过volumes和volumeMounts关联PVC：

     apiVersion: v1
     kind: Pod
     metadata:
     name: my-pod
     spec:
     containers:
      - name: app
        image: nginx
        volumeMounts:
          - mountPath: /data
            name: storage
     volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: my-pvc

4. 验证

   • 检查PV/PVC绑定状态：kubectl get pv,pvc
   • 进入Pod写入测试文件：kubectl exec my-pod -- touch /data/testfile

在Kubernetes集群中设置和使用Persistent Volumes (PV)与Persistent Volume Claims (PVC)需遵循以下步骤及注意事项：

1. 核心流程

• 静态配置：
  1. 管理员创建PV，定义容量、访问模式（如ReadWriteOnce）、存储后端（如NFS、Ceph）及回收策略（Retain/Delete）。
  2. 用户创建PVC，指定所需存储大小及访问模式。
  3. K8s通过StorageClass或标签匹配PVC与PV，完成绑定。
• 动态配置：
  1. 预先定义StorageClass，指定Provisioner（如AWS EBS、Azure Disk）。
  2. 用户创建PVC时引用StorageClass，自动触发PV创建。

2. 实践经验

• 存储后端选择：
  • 本地存储（hostPath）适用于测试，但缺乏高可用；生产环境推荐Ceph、云存储等分布式方案。
  • 访问模式需与后端兼容，例如NFS支持ReadWriteMany，而块存储（如EBS）仅支持ReadWriteOnce。
• 回收策略：
  • Retain：删除PVC后保留PV及数据，需手动清理，适合关键数据。
  • Delete：自动删除PV及后端存储，慎用于生产环境。
• 动态供给优化：
  • 为不同存储类型（SSD/HDD）创建多StorageClass，通过storageClassName区分。
  • 监控存储配额，避免资源耗尽导致PVC挂起。

3. 常见挑战与解决方案

• PVC/PV绑定失败：
  • 原因：容量不足、访问模式冲突或StorageClass不匹配。
  • 排查：使用kubectl describe pvc <name>查看事件日志，调整PVC需求或修复PV配置。
• 数据持久化风险：
  • 场景：PV回收策略为Delete时，误删PVC导致数据丢失。
  • 方案：生产环境优先使用Retain策略，结合备份工具（Velero）定期快照。
• 多Pod挂载冲突：
  • 问题：多个Pod以ReadWriteOnce挂载同一PVC引发写入竞争。
  • 解决：使用支持ReadWriteMany的存储（如NFS），或通过StatefulSet控制单实例访问。
• 性能瓶颈：
  • 网络存储延迟：对IO敏感的应用（数据库）可采用本地PV（需结合节点亲和性），但需容忍节点故障时的数据迁移成本。

4. 运维建议

• 监控与告警：
  • 监控PVC使用率（如Prometheus+Granfana），设置阈值告警。
  • 检查PV状态是否为Released（可能需手动清理）。
• 权限控制：
  • 限制用户创建PVC的StorageClass权限，避免资源滥用。
  • 使用RBAC约束敏感操作（如删除PV）。

示例YAML片段：

# 静态PV示例（NFS）
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.0.0.1
    path: /data
---
# 动态PVC示例（AWS EBS）
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-ebs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: aws-ssd

通过上述实践，可平衡存储可靠性、性能及运维复杂度，适应不同业务场景需求。

在Kubernetes集群中设置和使用Persistent Volumes（PV）与Persistent Volume Claims（PVC）的核心步骤如下：

1. PV创建：由管理员预先定义存储资源，通过YAML文件指定容量、访问模式（如ReadWriteOnce）、存储类型（如NFS、云存储）及回收策略（Retain/Delete）。
2. PVC申请：用户声明存储需求（如容量、访问模式），Kubernetes控制器根据PVC条件自动绑定匹配的PV。
3. Pod挂载：在Pod配置中通过volumes字段引用PVC名称，并在容器内通过volumeMounts指定挂载路径。

最佳实践：

• 使用StorageClass实现动态供应，避免手动创建PV（尤其适用于云平台如AWS EBS、GCP PD）。
• 监控PV/PVC状态（kubectl get pv,pvc）确保绑定成功。
• 有状态服务优先选用StatefulSet，配合PVC模板实现稳定存储。
• 生产环境建议设置ReclaimPolicy为Retain，防止误删数据。

关键配置示例：

# PV定义（静态）
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity: {storage: 10Gi}
  accessModes: [ReadWriteOnce]
  persistentVolumeReclaimPolicy: Retain
  nfs: {server: 10.0.0.1, path: "/data"}

# PVC申请
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes: [ReadWriteOnce]
  resources: {requests: {storage: 5Gi}}

通过解耦存储供应与消费，PV/PVC机制有效支持了Kubernetes应用的无状态化与数据持久化需求。