Stateful workloads (databases, queues, clustered stores) ना स्थिर ओळख आणि टिकाऊ storage लागते — ज्या गोष्टी Deployment पुरवत नाही. StatefulSet Pods ना स्थिर नावे व क्रमबद्ध lifecycle देते; PersistentVolumes (PV) आणि PersistentVolumeClaims (PVC) त्यांना Pod पेक्षा जास्त काळ टिकणारे storage देतात.
Deployment Pods are INTERCHANGEABLE: random names (web-7f9-abc), any order, share
nothing per-Pod. That's perfect for stateless apps — but a database replica needs:
→ a STABLE network identity (so peers can find it: db-0, db-1, db-2)
→ its OWN durable disk that survives restarts/rescheduling
→ ORDERED, controlled startup/scaling (bring up db-0 before db-1)
StatefulSet provides exactly these.
Stable NAMES → pod-0, pod-1, pod-2 (ordinal, not random)
Stable DNS → db-0.db.default.svc... via a headless Service
Stable STORAGE → each Pod gets its OWN PVC (db-0 keeps its disk across restarts)
Ordered ops → create/scale up in order 0,1,2…; terminate in reverse
StorageClass → the "how to provision" template (e.g. AWS gp3, fast-ssd)
PVC → a REQUEST for storage ("I need 20Gi, ReadWriteOnce") ← app-facing
PV → the ACTUAL provisioned volume bound to the PVC ← cluster-facing
Dynamic provisioning: a PVC referencing a StorageClass auto-creates a matching PV.
App → PVC → (StorageClass provisions) → PV → real disk (EBS, PD, Ceph, NFS…)
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: db
spec:
serviceName: db # स्थिर DNS साठी headless Service
replicas: 3
selector:
matchLabels: { app: db }
template:
metadata:
labels: { app: db }
spec:
containers:
- name: db
image: postgres:16
ports: [{ containerPort: 5432 }]
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
volumeClaimTemplates: # प्रत्येक Pod ला या template मधून स्वतःचा PVC/PV मिळतो
- metadata:
name: data
spec:
accessModes: [ReadWriteOnce]
storageClassName: fast-ssd
resources:
requests: { storage: 20Gi }
# स्थिर per-Pod DNS देणारी headless Service (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
clusterIP: None # headless
selector: { app: db }
ports: [{ port: 5432 }]
ReadWriteOnce (RWO) → mounted read-write by ONE node (most block storage: EBS/PD)
ReadOnlyMany (ROX) → read-only by many nodes
ReadWriteMany (RWX) → read-write by many nodes (needs NFS/CephFS/EFS)
⚠ Deleting a StatefulSet does NOT delete its PVCs by default (data is preserved).
⚠ Reclaim policy (Retain/Delete) decides what happens to the PV when the PVC is removed.
⚠ Kubernetes gives identity+storage, but app-level clustering/replication is YOUR job
(often via an Operator, e.g. for Postgres/Kafka).
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db # db-0, db-1, db-2 (स्थिर, क्रमबद्ध)
stateful workloads योग्यरित्या चालवणे हा Kubernetes चा अधिक कठीण भागांपैकी एक आहे, त्यामुळे StatefulSets व persistent storage समजून घेणे हे खऱ्या production परिणामांसह येणारे senior-स्तरीय ज्ञान आहे. मूळ अंतर्दृष्टी अशी की Deployments का कमी पडतात: त्यांचे Pods अदलाबदल करण्याजोगे असतात (random नावे, कोणताही क्रम, per-Pod state नाही), जे stateless services साठी आदर्श पण स्थिर ओळख (peers ना db-0, db-1, db-2 DNS ने शोधता यावी म्हणून), स्वतःचा टिकाऊ disk जो restarts व rescheduling टिकवतो, आणि क्रमबद्ध, नियंत्रित startup व scaling लागणाऱ्या databases व clustered stores साठी चुकीचे. StatefulSet नेमक्या याच हमी देते, आणि ते storage abstractions सोबत जोडले जाते: PersistentVolumeClaim हा storage साठीचा ऍप्लिकेशन-facing request आहे, PersistentVolume हा प्रत्यक्ष provision केलेला volume आहे, आणि StorageClass dynamic provisioning सक्षम करतो — volumeClaimTemplates प्रत्येक Pod ला स्वतःचा PVC/PV देऊन. सूचनांमध्येच senior engineers त्यांचे मोल सिद्ध करतात: access modes (RWO विरुद्ध RWX आणि कोणते backends त्यांना support करतात), StatefulSet हटवल्याने त्याचे PVCs default नुसार जपले जातात ही वस्तुस्थिती, PV च्या भवितव्याचे नियमन करणारे reclaim policy, आणि — निर्णायकपणे — Kubernetes ओळख व storage पुरवते पण ऍप्लिकेशन-स्तरीय replication व clustering ही तुमची जबाबदारी राहते, बहुतेकदा Operator कडे सोपवली जाते. data टिकाऊपणा व अचूक stateful वर्तन क्षमाशील नाही (चुका म्हणजे data loss किंवा split-brain) म्हणून, StatefulSets, PVs/PVCs व त्यांच्या सूचनांवर प्रभुत्व मिळवणे databases व इतर stateful systems Kubernetes वर विश्वासार्हपणे चालवण्यासाठी मूलभूत आहे.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या