An open-data PVC requests an access mode the provisioner cannot offer, and binding fails. What rule explains the failure?
Select an answer to reveal the explanation.
Short Explanation
You can’t order a “shared writable” pizza from a shop that only sells single slices—the backend has to support the access mode you ask for. If the PVC wants RWX and the disk type is RWO-only, binding fails. Modes aren’t decoration kubelet rewrites away.
Full Explanation
When an open-data PVC requests an access mode the provisioner cannot offer and binding fails, the rule is that requested PVC accessModes must be supported by the PersistentVolume or provisioner backend. You cannot order a shared writable pizza from a shop that only sells single slices—if the PVC wants RWX and the disk type is RWO-only, binding or provisioning fails. Access modes participate in matching; they are not decoration.
Any accessModes string is not accepted with kubelet converting unsupported modes at mount time. accessModes are not cosmetic labels that never participate in binding. CSI does not ignore accessModes whenever allowVolumeExpansion is true.
Exam caveat: static PVs must advertise compatible accessModes; dynamic classes fail at provision time when the driver rejects the mode. Read events carefully to distinguish “no PV match” from “driver unsupported.”
Operational check: compare PVC accessModes to StorageClass/PV capabilities, adjust to a supported mode or different class, and re-apply until the claim Binds for the open-data workload. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.