ReadOnlyMany模式下Persistent Volume的Capacity参数及PVC存储请求作用咨询

I get why this feels confusing—when you're dealing with read-only storage, it's not obvious why we even need to declare capacity or request storage. Let's unpack this step by step, using your example configurations as a reference.

1. What the PV's capacity.storage means (even for ReadOnlyMany) #

• First, let's be clear: capacity.storage is a logical declaration, not a hard enforcement of the underlying storage's size (especially true for hostPath like your example).
• For ReadOnlyMany (ROX) PVs, this value serves two key purposes:
  • It signals to Kubernetes how much storage this PV is "advertising" to the cluster.
  • It’s critical for the PVC-PV binding process: Kubernetes will only bind a PVC to this PV if the PVC’s requests.storage is less than or equal to this value.
• In your example, the PV declares 50Gi—this doesn’t mean /foo/bar is exactly 50Gi (Kubernetes doesn’t check that for hostPath), but it tells the cluster "this PV can satisfy PVCs requesting up to 50Gi of storage in ROX mode".

2. What the PVC's resources.requests.storage does for ReadOnlyMany #

• Even with ROX access, the storage request is all about matching to a compatible PV.
• The PVC is essentially saying: "I need a read-only PV that has at least X amount of advertised capacity". Kubernetes will scan all available ROX PVs and pick one where capacity.storage >= requests.storage.
• In your example, the PVC requests 1Mi—since the PV’s 50Gi is way larger than 1Mi, Kubernetes will happily bind them together.
• A common misconception: people think "since it's read-only, I don't need to request storage". But without this value, Kubernetes has no way to filter and match the right PV for your PVC (you could end up with a PV advertised as 1Gi when you need one advertised as 100Gi, even if the actual storage is bigger).

Let's walk through your example end-to-end #

Your PV config:

spec:
  storageClassName: manual
  capacity:
    storage: 50Gi
  accessModes:
    - ReadOnlyMany
  hostPath:
    path: "/foo/bar"

Your PVC config:

spec:
  storageClassName: manual
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 1Mi

• When you apply these, Kubernetes will check three things:
  1. Do the PV and PVC share the same storageClassName? Yes (manual).
  2. Do their access modes match? Yes (ReadOnlyMany).
  3. Is the PV's capacity >= the PVC's request? Yes (50Gi >= 1Mi).
• So the PVC gets bound to the PV, and your pod can mount /foo/bar as read-only storage.

Key Notes to Remember #

• For hostPath (and many other storage types), Kubernetes doesn’t validate that the actual underlying storage matches the PV’s capacity—it’s up to you to ensure /foo/bar has the space you need (though since it's read-only, you're just accessing existing data anyway).
• The capacity/request system works the same for ROX as it does for read-write modes—it’s all about the binding logic, not enforcing storage limits (unless your storage provider supports quota enforcement, which is a separate feature).

内容的提问来源于stack exchange，提问作者Sam London