PV/PVC存储容量配置作用及Pod存储空间限制方法咨询

一、核心配置的实际作用 #

• PV 的 spec.capacity.storage：这是集群存储资源的总量声明，标记该PV的最大可用容量，核心作用是和PVC的存储请求做匹配——PVC申请的存储大小不能超过PV容量，否则无法绑定。它只是资源调度层面的匹配条件，并非对Pod实际写入的强制限制。
• PVC 的 spec.resources.requests.storage：这是Pod通过PVC向集群申请的存储资源量，K8s会根据这个值筛选容量足够的PV进行绑定。同样，这只是申请额度，默认情况下不会阻止Pod写入超过该值的数据。

二、存储限制未生效的原因 #

1. 存储类不支持硬配额：像hostPath、local这类本地存储，或未配置配额的NFS，本身没有文件系统层面的容量限制机制，K8s层面的PV/PVC声明无法做到强制约束。
2. 未启用命名空间存储配额：如果没在目标命名空间配置StorageQuota，PVC可以随意申请超预期的存储容量，且即使申请了10G，Pod依然能超量写入。
3. 底层存储无配额设置：比如云存储卷未开启容量限制，或NFS服务器没给共享目录设置磁盘配额，K8s的声明无法穿透到底层做强制限制。

三、有效实现存储容量限制的方法 #

1. 选用支持硬限制的存储类 #

优先选择自带容量强制限制的存储方案：

• 云厂商块存储（AWS EBS、Azure Disk、GCP PD）：这类存储卷是固定容量的块设备，写入超过预设容量会直接触发磁盘满错误，天然支持硬限制。
• 配置了磁盘配额的NFS：在NFS服务器端给共享目录设置用户/目录配额（比如用quota或edquota命令），之后PV挂载该目录，Pod写入超过配额时会被阻止。

2. 配置命名空间级StorageQuota #

在目标命名空间创建存储配额，限制PVC的总容量和单PVC容量，示例配置：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: your-ns
spec:
  hard:
    persistentvolumeclaims: "8" # 限制该命名空间内PVC数量
    requests.storage: "80Gi" # 限制总申请存储量
    requests.storage.storageclass.storage.k8s.io/gp2: "40Gi" # 针对特定存储类的限制

注意：这个配置仅限制PVC的申请额度，要实现Pod写入限制，仍需底层存储支持硬配额。

3. 本地存储/hostPath的配额处理 #

如果必须用本地存储，需要在节点上预先给存储目录设置文件系统级配额：

• 创建固定大小的镜像文件并挂载为loop设备：

  # 创建10G的镜像文件
  fallocate -l 10G /node-storage/pv-demo.img
  # 格式化为ext4文件系统
  mkfs.ext4 /node-storage/pv-demo.img
  # 挂载到指定目录
  mount -o loop /node-storage/pv-demo.img /mnt/pv-demo
  

  然后在PV的hostPath中指定/mnt/pv-demo，此时Pod写入超过10G会触发磁盘满错误，实现硬限制。

附：常见无效配置示例分析 #

比如你用了hostPath类型的PV/PVC：

# PV
apiVersion: v1
kind: PersistentVolume
metadata:
  name: demo-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/node-storage
---
# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  resources:
    requests:
      storage: 10Gi
  accessModes:
    - ReadWriteOnce

这种情况下，/mnt/node-storage是节点上的普通目录，无任何配额限制，所以Pod可以写入超过10G的数据——K8s仅完成了PV和PVC的容量匹配，不会对实际写入做强制约束。

内容的提问来源于stack exchange，提问作者Dave Pearce