Statefulness means that an application depends on retained state to function. That state must survive restarts and relocation, so stateful workloads require more careful storage, identity, and scaling decisions than stateless workloads. section 16.1.1
Stateful workloads differ from stateless replicas in several practical ways:
- Replicas cannot always be added or removed freely because each instance may own or depend on particular state. section 16.1.1
- Shared state requires storage that supports concurrent read-write access; otherwise, each replica needs its own volume. section 16.1.1
- A replacement instance must retain the former instance’s network identity and state rather than behaving as an interchangeable copy. section 16.1.2
Scaling the Quiz service
Scaling the Quiz Deployment from one to three replicas can leave new pods unable to start when all replicas use one ReadWriteOnce volume. A MongoDB container may fail because another instance already holds the database lock. section 16.1.1
Kubernetes manages stateful workloads with StatefulSets. Each replica receives an ordinal name and its own PersistentVolumeClaim, while a headless Service can provide a stable DNS record even after pod relocation. StatefulSets also control creation and deletion order, update behavior, and claim retention; complex applications may require Operators. section 16.1.2 section 16.5
$ kubectl scale deploy quiz --replicas 3 deployment.apps/quiz scaled
Inspect the practical failure mode by scaling the Quiz Deployment and then checking the resulting pods. section 16.1.1
