Namespace depths-1l3xq2p is empty. The cluster has one StorageClass:
sh
kubectl get scCreate the claim
Apply a 1Gi ReadWriteOnce claim named market-data. No storageClassName, so it gets the default class:
sh
kubectl apply -n depths-1l3xq2p -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: market-data
spec:
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 1Gi
EOF
kubectl get pvc -n depths-1l3xq2pSTATUS is Pending. Read the reason:
sh
kubectl describe pvc market-data -n depths-1l3xq2pThe last Events line names it. That is the answer to the second objective.
Mount it
A Deployment whose Pod mounts the claim is the consumer the class is waiting for:
sh
kubectl apply -n depths-1l3xq2p -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: market-db
spec:
replicas: 1
selector:
matchLabels:
app: market-db
template:
metadata:
labels:
app: market-db
spec:
containers:
- name: db
image: postgres:16
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
volumes:
- name: data
persistentVolumeClaim:
claimName: market-data
EOFsh
kubectl get pvc,pv -n depths-1l3xq2p
kubectl get pods -n depths-1l3xq2pThe claim is Bound. A PV appeared with a generated name; the provisioner created it. Read the VOLUME column of the claim: its prefix is the last answer.
console
$ kubectl get pvc -n depths-abc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
market-data Bound pvc-5b1e0c7a-8d3f-4f8a-9d4e-2c6b1a7f0e21 1Gi RWO local-path 40sProve the data survives the Pod
sh
kubectl delete pod -n depths-1l3xq2p -l app=market-db
kubectl get pods,pvc -n depths-1l3xq2pThe Deployment creates a new Pod. The claim stays Bound to the same volume. The Pod changed; the storage did not.