Stateful workloads (databases, queues, clustered stores) को स्थिर पहचान और टिकाऊ storage चाहिए — जो एक Deployment प्रदान नहीं करता। एक StatefulSet Pods को स्थिर नाम और क्रमबद्ध lifecycle देता है; PersistentVolumes (PV) और PersistentVolumeClaims (PVC) उन्हें ऐसा storage देते हैं जो Pod से अधिक जीता है।
Deployment Pods आपस में बदले जा सकते हैं (INTERCHANGEABLE): यादृच्छिक नाम (web-7f9-abc), कोई भी
क्रम, प्रति-Pod कुछ साझा नहीं। stateless apps के लिए यह उत्तम है — पर एक database replica को चाहिए:
→ एक स्थिर network पहचान (ताकि peers इसे ढूँढ सकें: db-0, db-1, db-2)
→ अपनी ख़ुद की टिकाऊ disk जो restarts/rescheduling में बची रहे
→ क्रमबद्ध, नियंत्रित startup/scaling (db-1 से पहले db-0 लाना)
StatefulSet ठीक यही प्रदान करता है।
स्थिर NAMES → pod-0, pod-1, pod-2 (ordinal, यादृच्छिक नहीं)
स्थिर DNS → एक headless Service के ज़रिए db-0.db.default.svc...
स्थिर STORAGE → हर Pod को अपना PVC मिलता है (db-0 restarts में अपनी disk रखता है)
क्रमबद्ध ops → 0,1,2… क्रम में create/scale up; उल्टे क्रम में terminate
StorageClass → "कैसे provision करें" template (जैसे AWS gp3, fast-ssd)
PVC → storage के लिए एक REQUEST ("मुझे 20Gi, ReadWriteOnce चाहिए") ← app-सामने
PV → PVC से bound असली provisioned volume ← cluster-सामने
Dynamic provisioning: एक StorageClass को referencing करता PVC मिलान 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 }
# वह headless Service जो स्थिर प्रति-Pod DNS देता है (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) → EK node द्वारा read-write mount (अधिकांश block storage: EBS/PD)
ReadOnlyMany (ROX) → कई nodes द्वारा read-only
ReadWriteMany (RWX) → कई nodes द्वारा read-write (NFS/CephFS/EFS चाहिए)
⚠ एक StatefulSet मिटाने से default रूप से उसके PVCs नहीं मिटते (data सुरक्षित रहता है)।
⚠ Reclaim policy (Retain/Delete) तय करती है कि PVC हटने पर PV का क्या हो।
⚠ Kubernetes पहचान+storage देता है, पर app-स्तरीय clustering/replication आपकी ज़िम्मेदारी है
(अक्सर एक Operator के ज़रिए, जैसे 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 आपस में बदले जा सकते हैं (यादृच्छिक नाम, कोई भी क्रम, कोई प्रति-Pod state नहीं), जो stateless services के लिए आदर्श है पर उन databases और clustered stores के लिए ग़लत है जिन्हें स्थिर पहचान चाहिए (ताकि peers db-0, db-1, db-2 को DNS से ढूँढ सकें), अपनी टिकाऊ disk जो restarts और rescheduling में बची रहे, और क्रमबद्ध, नियंत्रित startup तथा scaling चाहिए। एक StatefulSet ठीक यही गारंटियाँ प्रदान करता है, और यह storage abstractions के साथ जोड़ी बनाता है: एक PersistentVolumeClaim storage के लिए application-सामने वाला अनुरोध है, एक PersistentVolume असली provisioned volume है, और एक StorageClass dynamic provisioning सक्षम करता है — volumeClaimTemplates हर Pod को उसका अपना PVC/PV देते हुए। चेतावनियाँ ही वहाँ हैं जहाँ senior इंजीनियर अपना मूल्य साबित करते हैं: access modes (RWO बनाम RWX और कौन-से backends उन्हें समर्थन देते हैं), यह तथ्य कि एक StatefulSet मिटाने से default रूप से उसके PVCs सुरक्षित रहते हैं, reclaim policy जो PV के भाग्य को नियंत्रित करती है, और — महत्वपूर्ण रूप से — यह कि Kubernetes पहचान और storage देता है पर application-स्तरीय replication और clustering आपकी ज़िम्मेदारी बनी रहती है, जो अक्सर एक Operator को सौंपी जाती है। चूँकि data की टिकाऊपन और सही stateful व्यवहार निर्मम हैं (ग़लतियों का मतलब data हानि या split-brain), StatefulSets, PVs/PVCs और उनकी चेतावनियों में महारत Kubernetes पर databases और अन्य stateful सिस्टमों को विश्वसनीय रूप से चलाने की नींव है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें