Cloud Intermediate
Kubernetes — Stateful Workloads in Practice¶
KubernetesStatefulSetDatabasesStorage 6 min read
Running stateful applications on Kubernetes. Databases, message brokers, storage classes and data persistence.
Stateful vs Stateless¶
- Stable hostname —
mysql-0,mysql-1 - Ordered deployment — 0 → 1 → 2
- Stable storage — PVC per pod
- Headless Service — DNS per pod
PostgreSQL StatefulSet¶
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgresql
spec:
serviceName: postgresql
replicas: 3
template:
spec:
containers:
- name: postgres
image: postgres:16-alpine
ports:
- containerPort: 5432
env:
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
resources:
requests:
cpu: 500m
memory: 1Gi
livenessProbe:
exec:
command: ["pg_isready", "-U", "postgres"]
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: [ReadWriteOnce]
storageClassName: fast-ssd
resources:
requests:
storage: 100Gi
Recommended Operators¶
- CloudNativePG — PostgreSQL (CNCF sandbox)
- Percona Operators — MySQL, MongoDB, PostgreSQL
- Strimzi — Apache Kafka
- Redis Operator — Spotahome
Operators handle: failover, backup, restore, upgrades, connection pooling, monitoring.
Storage Best Practices¶
reclaimPolicy: Retainfor data- SSD StorageClass for databases
- CSI VolumeSnapshot for point-in-time recovery
- Do not use
ReadWriteManyfor databases - Test disaster recovery scenarios
Summary¶
Stateful workloads on K8s are production-ready. Prefer operators and always test failover and restore.
Need Help with Implementation?¶
Our team has experience designing and implementing modern architectures. We’re happy to help.