Namespace depths-n0bpsd exists. No PVs exist yet:
sh
kubectl get pvCreate a volume
A 2Gi ReadWriteOnce PV with Retain and no class. PVs are cluster-scoped: no -n.
sh
kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: archive-pv
spec:
capacity:
storage: 2Gi
accessModes: [ReadWriteOnce]
persistentVolumeReclaimPolicy: Retain
storageClassName: ""
hostPath:
path: /mnt/archive
EOF
kubectl get pvSTATUS is Available. CLAIM is empty.
Claim it
A claim with storageClassName: "" binds statically. Ask for 1Gi:
sh
kubectl apply -n depths-n0bpsd -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: archive
spec:
accessModes: [ReadWriteOnce]
storageClassName: ""
resources:
requests:
storage: 1Gi
EOF
kubectl get pvc -n depths-n0bpsd
kubectl get pvThe claim is Bound to archive-pv. The PV's CLAIM column reads depths-n0bpsd/archive. A 1Gi request bound a 2Gi volume: the binder picks the smallest Available PV that fits, and this was the only one.
A claim nothing fits
Create backups, same shape, asking for 5Gi:
sh
kubectl apply -n depths-n0bpsd -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: backups
spec:
accessModes: [ReadWriteOnce]
storageClassName: ""
resources:
requests:
storage: 5Gi
EOF
kubectl get pvc backups -n depths-n0bpsd
kubectl describe pvc backups -n depths-n0bpsdPending. The last Events line gives the reason. That reason is the answer to one objective.
Give it a volume
Create a PV large enough, with the same empty class. Name it backups-pv, 10Gi:
sh
kubectl get pvc -n depths-n0bpsdThe claim binds on the next pass without any change to the claim itself.