Stateful workloads
Stateful workloads
Stateless apps are easy: kill a Pod, start another. State changes the rules.
Should it run in Kubernetes at all?
| Run it in the cluster when | Keep it outside when |
|---|---|
| an operator handles failover, backup, upgrades | nobody on the team can operate the database |
| storage is solid (CSI, snapshots, tested restores) | storage is “an NFS share somebody set up” |
| you want the same tooling for everything | a managed service (Azure SQL, RDS) fits the need |
The building blocks
graph TB
SS[StatefulSet or operator CR] --> P0[pod-0] & P1[pod-1]
P0 --> V0[(PVC data-0)]
P1 --> V1[(PVC data-1)]
V0 & V1 --> SC[StorageClass -> CSI]
PDB[PodDisruptionBudget] -.protects.-> P0 & P1
AA[anti-affinity / topology spread] -.spreads.-> P0 & P1
| Concern | Tool |
|---|---|
| stable identity, one volume per replica | StatefulSet volumeClaimTemplates |
| replicas on different nodes / zones | pod anti-affinity, topologySpreadConstraints |
| maintenance without losing quorum | PodDisruptionBudget |
| slow start (recovery, replay) | startupProbe |
| more space | allowVolumeExpansion: true + edit the PVC |
| point-in-time copy | VolumeSnapshot (CSI) / application backup |
| failover, replication, upgrades | an operator |
Access modes decide the design
- RWO (block storage, most cloud disks): one node at a time - one PVC per replica, replication done by the application.
- RWX (NFS, CephFS, Azure Files): shared - convenient, but two writers on one database file is corruption, not high availability.
Backups are part of the design
A replica is not a backup: a DROP TABLE is replicated in milliseconds. Plan
application-consistent backups (database dump, operator backups to object
storage) and test the restore - Lab 39.