Skip to main content

Assignment 2: Run a stateful workload with a PVC

Goal: Run a workload that keeps its data by claiming persistent storage from the lab's NFS StorageClass, and prove the data survives the Pod being deleted and rescheduled.

Where: From the Jumpbox (kubectl/helm/k9s ready). Persistent storage comes from the NFS server at 10.100.100.12, exposed as a ReadWriteMany (RWX) StorageClass. Cluster workers are 10.100.100.8/.9/.10.

Tasks

  1. Work in your own namespace (reuse the one from Assignment 1, or kubectl create namespace <yourname>).
  2. Find the lab's NFS StorageClass name: kubectl get storageclass. Note the exact name — you'll put it in storageClassName.
  3. Write a PersistentVolumeClaim named data with accessModes: [ReadWriteMany], storageClassName: <nfs-class>, and resources.requests.storage: 1Gi. Apply it and confirm kubectl get pvc -n <yourname> shows STATUS: Bound. Note the PV it bound to with kubectl get pv.
  4. Write a Deployment named recorder (1 replica) running busybox:1.36 that appends a timestamped line to a file on the mounted volume every few seconds, e.g. command: sh -c "while true; do echo \"$(date) from $(hostname)\" >> /data/log.txt; sleep 5; done". Mount the data PVC at /data.
  5. Apply it, wait until Running, then read the file: kubectl exec deploy/recorder -n <yourname> -- cat /data/log.txt. Confirm lines are accumulating.
  6. Prove persistence: delete the Pod (kubectl delete pod <recorder-pod> -n <yourname>), let the Deployment recreate it, then cat /data/log.txt again — the old lines must still be there, with new ones appended after the gap.
  7. Prove RWX sharing: scale recorder to 3 replicas. They may land on different workers. Exec into each and confirm they are all reading/writing the same /data/log.txt (you'll see lines from multiple hostnames). This only works because the StorageClass is ReadWriteMany.
  8. Inspect the reclaim policy of your PV: kubectl get pv <name> -o jsonpath='{.spec.persistentVolumeReclaimPolicy}'. Write one sentence in your README on what would happen to the data if you deleted the PVC.

Deliverable

YAML manifests (pvc.yaml, deployment.yaml) plus a README.md showing: the bound PVC/PV, the file contents before and after the Pod delete (to prove persistence), output from at least two replicas writing to the same file (to prove RWX), and your one-sentence note on the reclaim policy.

Acceptance criteria — you're done when:

  • kubectl get pvc data -n <yourname> shows Bound to a PV from the NFS StorageClass.
  • The PVC uses accessModes: [ReadWriteMany].
  • The recorder Pod mounts the PVC at /data and is appending to /data/log.txt.
  • After deleting the Pod and letting it be recreated, the earlier log lines are still present (persistence proven).
  • With 3 replicas, more than one Pod hostname appears in the same /data/log.txt (RWX sharing proven).
  • Your README states the PV's reclaim policy and what happens to data on PVC deletion.
  • Applying kubectl apply -f . into a clean namespace reproduces the whole setup.

Hints

  • PVC stuck in Pending? Check kubectl describe pvc data -n <yourname> for events — usually a wrong/missing storageClassName or an access mode the class doesn't support.
  • Re-read the Persistent Storage lesson, especially the PV/PVC/StorageClass flow diagram and the RWO-vs-RWX section.
  • A single RWO claim would block multiple Pods on different nodes — that is exactly why this assignment requires RWX.
  • Use kubectl get pods -o wide -n <yourname> to confirm your replicas really landed on different workers (.8/.9/.10).
  • To exec into a specific replica: kubectl get pods -n <yourname>, then kubectl exec <pod> -n <yourname> -- cat /data/log.txt.
  • Blocked for >~30 min after re-reading the lessons? Bring what you've tried to your mentor.

No comments to display

Back to top