Stateful workload கள் (database கள், queue கள், clustered store கள்) நிலையான அடையாளம் மற்றும் நீடித்த storage தேவை — ஒரு Deployment வழங்காத விஷயங்கள். ஒரு StatefulSet Pod களுக்கு நிலையான பெயர்களையும் ordered lifecycle ஐயும் தருகிறது; PersistentVolume கள் (PV) மற்றும் PersistentVolumeClaim கள் (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 # headless Service for stable DNS
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: # each Pod gets its OWN PVC/PV from this template
- metadata:
name: data
spec:
accessModes: [ReadWriteOnce]
storageClassName: fast-ssd
resources:
requests: { storage: 20Gi }
# The headless Service that gives stable per-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) → 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 (stable, ordered)
Stateful workload களை சரியாக இயக்குவது Kubernetes-இன் கடினமான பகுதிகளில் ஒன்று, எனவே StatefulSet களையும் persistent storage ஐயும் புரிந்துகொள்வது நிஜமான production விளைவுகளைக் கொண்ட senior-level அறிவு. மைய நுண்ணறிவு Deployment கள் ஏன் குறைபடுகின்றன என்பது: அவற்றின் Pod கள் interchangeable (random பெயர்கள், எந்த வரிசையிலும், per-Pod state இல்லை), stateless service களுக்கு ideal ஆனால் நிலையான அடையாளம் (peer கள் db-0, db-1, db-2 ஐ DNS மூலம் கண்டறிய), அவற்றின் சொந்த நீடித்த disk restart மற்றும் rescheduling ஐத் தாண்டி நிலைக்க, மற்றும் ordered, controlled startup மற்றும் scaling தேவைப்படும் database கள் மற்றும் clustered store களுக்குத் தவறானது. ஒரு StatefulSet சரியாக இந்த உத்தரவாதங்களை வழங்குகிறது, மேலும் அது storage abstraction களுடன் இணைகிறது: ஒரு PersistentVolumeClaim என்பது storage-க்கான application-facing request, ஒரு PersistentVolume என்பது உண்மையில் provision செய்யப்பட்ட volume, மற்றும் ஒரு StorageClass dynamic provisioning ஐ இயலச்செய்கிறது — volumeClaimTemplates ஒவ்வொரு Pod-க்கும் அதன் சொந்த PVC/PV ஐத் தருகிறது. எச்சரிக்கைகள் தான் senior engineer கள் தமது மதிப்பை நிரூபிக்கும் இடம்: access mode கள் (RWO vs RWX மற்றும் எந்த backend கள் அவற்றை ஆதரிக்கின்றன), ஒரு StatefulSet ஐ delete செய்வது default-ஆக அதன் PVC களைப் பாதுகாக்கிறது என்ற உண்மை, PV-இன் விதியை ஆளும் reclaim policy, மற்றும் — முக்கியமாக — Kubernetes அடையாளத்தையும் storage ஐயும் வழங்குகிறது ஆனால் application-level replication மற்றும் clustering உங்கள் பொறுப்பாகவே இருக்கிறது, பெரும்பாலும் ஒரு Operator-க்கு ஒப்படைக்கப்படுகிறது. Data durability மற்றும் சரியான stateful நடத்தை மன்னிக்காதவை (தவறுகள் data இழப்பு அல்லது split-brain ஐக் குறிக்கின்றன) என்பதால், StatefulSet கள், PV/PVC கள், மற்றும் அவற்றின் எச்சரிக்கைகளைத் தேர்ச்சி பெறுவது Kubernetes-இல் database களையும் பிற stateful system களையும் நம்பகமாக இயக்குவதற்கு அடிப்படையானது.
விரிவான பதில்களுடன் கூடிய IT நேர்காணல் கேள்விகளின் நூலகம் — Junior முதல் Senior வரை.
நன்கொடை