State persistence preserves application data beyond the lifetime of the process, container, or pod using it. It becomes necessary when a service stores information that must survive storage-user replacement rather than being recreated from scratch. section 9.1.1 section 10.5
Kubernetes represents persistent storage separately from the pods that consume it. An application can request storage properties instead of naming a particular device, allowing the cluster to match an existing volume or provision one. section 10.0 section 10.1
Persistent storage is distinguished by how it relates to application lifecycles:
- PersistentVolumes represent storage intended to outlive the pods using them; PersistentVolumeClaims provide the application-facing claim for storage. section 10.0 section 10.5
- Static provisioning uses an existing matching volume, while dynamic provisioning lets the cluster create suitable storage. section 10.0 section 10.1
- Ephemeral storage can be associated with an individual pod, whereas persistent storage is designed to retain data independently of that pod. section 10.5
A quiz database without persistence
A Quiz API and MongoDB initially run in one pod. After inserting a question, the API returns it through its random-question endpoint. Shutting down MongoDB and counting the questions afterward returns 0, demonstrating that the database needs a volume if its data must survive container replacement. section 9.1.1
Listing 9.1 The quiz pod with no volume
apiVersion: v1
kind: Pod
metadata:
name: quiz
spec: #1
containers:
- name: quiz-api #2
image: luksa/quiz-api:0.1 #2
ports:
- name: http #3
containerPort: 8080 #3
- name: mongo #3
image: mongo #3
Inspect the initial pod manifest to see the Quiz API and MongoDB containers before a volume is added. section 9.1.1
$ kubectl exec -it quiz -c mongo -- mongosh kiada --quiet --eval "db.questions.countDocuments()" 0 #1
Inspect the post-shutdown query showing that MongoDB contains no questions when its data has not been persisted. section 9.1.1
