Create a new PersistentVolumeClaim • Name: pv-volume • Class: csi-hostpath-sc • Capacity: 10Mi Create a new Pod which mounts the PersistentVolumeClaim as a volume: • Name: web-server • Image: nginx…

Question

Exhibits

Explanation

Kubernetes PVC + Pod Volume Mount - Explanation

Overall Goal

This task tests your understanding of Kubernetes persistent storage: how to request storage (PVC), attach it to a workload (Pod), and dynamically resize it. The correct approach follows the Kubernetes storage lifecycle - claim first, then consume - because a Pod cannot reference storage that doesn't exist yet.

Step 1: Create the PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-volume
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: csi-hostpath-sc
  resources:
    requests:
      storage: 10Mi

Why this is necessary: A PVC is a request for storage. It tells Kubernetes "I need 10Mi of storage from the csi-hostpath-sc StorageClass." The StorageClass determines the provisioner that creates the backing PersistentVolume (PV). Without the PVC existing first, the Pod spec will be invalid and the Pod will fail to schedule.

Key details:

• storageClassName: csi-hostpath-sc - must match an existing StorageClass; mismatching leaves the PVC in Pending state forever
• accessModes: ReadWriteOnce - the Pod spec must use the same access mode; a mismatch causes a bind failure
• 10Mi capacity - the initial size before the later resize

Step 2: Create the Pod that mounts the PVC

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
  - name: web-server
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: pv-storage
  volumes:
  - name: pv-storage
    persistentVolumeClaim:
      claimName: pv-volume

Why this is necessary: The Pod consumes the PVC by referencing it by name. The two-part pattern (volumes at the Pod level + volumeMounts inside the container) is intentional - it decouples the storage source from how the container uses it.

What /usr/share/nginx/html accomplishes: This is nginx's default web root. Mounting here means nginx serves content from the persistent volume, surviving Pod restarts.

If you skip the volumes stanza but keep volumeMounts: The Pod fails validation immediately - volumeMounts entries must reference a named volume defined in volumes.

If you create the Pod before the PVC: The Pod enters Pending state and stays there until the PVC is created and bound.

Step 3: Expand the PVC to 70Mi

kubectl edit pvc pv-volume
# change storage: 10Mi → storage: 70Mi

Or with patch:

kubectl patch pvc pv-volume -p '{"spec":{"resources":{"requests":{"storage":"70Mi"}}}}'

Why this works: The csi-hostpath-sc StorageClass supports volume expansion (allowVolumeExpansion: true). Kubernetes delegates the resize to the CSI driver. You can only expand (increase), never shrink - attempting to reduce the size will be rejected.

The --record flag note: kubectl edit and kubectl patch accept --record to annotate the resource with the command that caused the change (kubectl.kubernetes.io/last-applied-configuration). In modern Kubernetes (1.22+) --record is deprecated but still accepted in exam environments. If the question says "record that change," add --record to the patch command.

If the StorageClass didn't have allowVolumeExpansion: true: The edit would be accepted by kubectl but the PVC would show a FileSystemResizeFailed or similar error event - the request is stored but never fulfilled.

What Goes Wrong If Steps Are Out of Order

Memory Tip

Think of it as "Claim → Consume → Resize" - the same order as renting a storage unit: first sign the lease (PVC), then move your stuff in (Pod mount), then call to upgrade the unit size (expand).

The key invariant: storage must exist before it can be used. Every step follows from that.

No community discussion yet for this question.