Persist Data with a PVC

Use your browser to download either ivia-chapter-10.tar.gz or ivia-chapter-10.zip. The archive is self-contained; you do not need this tutorial repository.

cd ~/Downloads
tar -xzf ivia-chapter-10.tar.gz
cd ivia-chapter-10

Set-Location "$HOME\Downloads"
Expand-Archive -Path ivia-chapter-10.zip -DestinationPath . -Force
Set-Location ivia-chapter-10

All remaining relative paths in this chapter start from that extracted directory.

minikube addons enable ingress
kubectl label node minikube ivia.ch/nodetype=app --overwrite
minikube image build -t simple-backend:persistent persistent-app/backend
minikube image build -t simple-frontend:persistent persistent-app/frontend

Inspect the important values:

grep -n -E 'type:|replicaCount:|pvcs:|mountPath:|storage:|storageClassName:' \
  persistent-app/values.yaml

The backend is a one-replica StatefulSet. Its unnamed claim becomes simple-app-backend-0, requests 1Gi, uses ReadWriteOnce, and mounts at /data. We use a StatefulSet here because stable Pod identity pairs well with a dedicated volume claim.

helm upgrade --install simple-app \
  oci://harbor.ivia.ch/ivia-generic-helm-chart/ivia-generic-helm-chart \
  --version 4.8.0 -n tutorial --atomic --timeout 5m \
  -f persistent-app/values.yaml

kubectl get statefulset,pods,pvc -n tutorial
kubectl wait --for=condition=Ready pod \
  -l app.kubernetes.io/component=backend \
  -n tutorial --timeout=180s

You should see the PVC Bound and the backend Pod 1/1 Running.

Ensure hostnames resolve before calling the API. On Windows, add hosts entries if Chapter 9 did not already (Administrator PowerShell):

$ip = minikube ip
Add-Content `
  -Path "$env:WINDIR\System32\drivers\etc\hosts" `
  -Value "$ip simple-app.test api.simple-app.test"

MINIKUBE_IP=$(minikube ip)
curl --fail --resolve api.simple-app.test:80:$MINIKUBE_IP \
  -H 'Origin: http://simple-app.test' \
  -H 'Content-Type: application/json' \
  -d '{"text":"I survived a Pod restart!"}' \
  http://api.simple-app.test/api/messages
curl --fail --resolve api.simple-app.test:80:$MINIKUBE_IP \
  http://api.simple-app.test/api/messages

$ip = minikube ip
# Optional: prove routing without relying only on hosts
curl.exe --fail --resolve "api.simple-app.test:80:$ip" `
  -H "Origin: http://simple-app.test" `
  -H "Content-Type: application/json" `
  -d "{\"text\":\"I survived a Pod restart!\"}" `
  http://api.simple-app.test/api/messages
curl.exe --fail --resolve "api.simple-app.test:80:$ip" `
  http://api.simple-app.test/api/messages

Delete only the Pod, not the claim:

BACKEND_POD=$(kubectl get pod -n tutorial \
  -l app.kubernetes.io/component=backend \
  -o jsonpath='{.items[0].metadata.name}')
kubectl delete pod "$BACKEND_POD" -n tutorial
kubectl wait --for=condition=Ready pod \
  -l app.kubernetes.io/component=backend \
  -n tutorial --timeout=180s

curl --fail --resolve api.simple-app.test:80:$MINIKUBE_IP \
  http://api.simple-app.test/api/messages

curl.exe --fail --resolve "api.simple-app.test:80:$ip" `
  http://api.simple-app.test/api/messages

Both list responses should still contain I survived a Pod restart!.

This KISS design is educational, not horizontally scalable. A ReadWriteOnce claim is normally mounted read-write by one node, and SQLite expects one shared local file. Two backend replicas could contend for the file or be unable to mount it as intended. For multiple replicas, use a networked database such as PostgreSQL, add migrations and backups, and keep API Pods stateless.

A StatefulSet gives stable Pod identity and ordered replacement; the PVC gives durable storage. Neither automatically provides backups, replication, encryption, or disaster recovery.

You have walked a complete cloud-native path:

• Built immutable images and ran them locally
• Deployed with the IVIA generic Helm chart instead of one-off manifests
• Externalized configuration and practiced Secrets carefully
• Used probes and events to investigate failures
• Connected React and FastAPI through Ingress and CORS
• Separated replaceable compute from durable PVC storage

Reflection

1. How would you explain DevOps to a friend using this tutorial as the example?
2. Which step in the path feels most fragile on a shared laptop cluster, and why?
3. Where would you keep durable data if you needed three API replicas tomorrow?

Concrete next steps

• Deploy a second small service and call it from the backend.
• Replace SQLite with a networked database and keep API Pods stateless.
• Experiment with raising frontend replicas after Chapter 5’s stretch exercise.
• Continue with Appendix Chapters 11 (networking diagnostics) and 12 (GitLab CI).