X'inhuma l-StatefulSets, PersistentVolumes/Claims, u kif tħaddem workloads stateful fuq Kubernetes?

Question

IT Interview Practice · Accepted Answer

Workloads stateful (databases, queues, clustered stores) jeħtieġu **identità stabbli** u **storage dejjiema** — affarijiet li Deployment ma jipprovdix. **StatefulSet** jagħti lill-Pods ismijiet stabbli u lifecycle ordnat; **PersistentVolumes (PV)** u **PersistentVolumeClaims (PVC)** jagħtuhom storage li jibqa' ħaj wara l-Pod.

## Għaliex id-Deployments mhumiex biżżejjed

```text
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.
```

## Garanziji tal-StatefulSet

```text
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
```

## Storage persistenti: PV, PVC, StorageClass

```text
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…)
```

## StatefulSet b'storage għal kull Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service għal DNS stabbli
  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:      # kull Pod jieħu l-PVC/PV TIEGĦU minn dan it-template
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Il-headless Service li jagħti DNS stabbli għal kull Pod (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Access modes u twissijiet

```text
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).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (stabbli, ordnati)
```

## Għaliex huwa importanti

Li tħaddem workloads stateful b'mod korrett huwa waħda mill-partijiet aktar diffiċli ta' Kubernetes, għalhekk li tifhem l-StatefulSets u l-storage persistenti huwa għarfien tal-livell senior b'konsegwenzi reali fil-produzzjoni. L-għarfien ewlieni huwa *għaliex* id-Deployments ma jaslux: il-Pods tagħhom huma interkambjabbli (ismijiet random, kwalunkwe ordni, l-ebda stat għal kull Pod), li huwa ideali għal services stateless imma ħażin għal databases u clustered stores li jeħtieġu **identità stabbli** (biex il-peers isibu `db-0`, `db-1`, `db-2` bid-DNS), **id-diska dejjiema tagħhom stess** li tibqa' ħajja wara restarts u rescheduling, u **startup u skalar ordnati u kkontrollati**. **StatefulSet** jipprovdi eżatt dawn il-garanziji, u jgħaqqad mal-astrazzjonijiet tal-storage: **PersistentVolumeClaim** hija r-request għall-storage li tħares lejn l-applikazzjoni, **PersistentVolume** huwa l-volum attwali pprovdut, u **StorageClass** jippermetti dynamic provisioning — bil-`volumeClaimTemplates` jagħti lil kull Pod il-PVC/PV tiegħu stess. It-twissijiet huma fejn l-inġiniera senior jaqilgħu ħobżhom: l-**access modes** (RWO vs RWX u liema backends jappoġġawhom), il-fatt li li tħassar StatefulSet **iżomm il-PVCs tiegħu** b'default, ir-**reclaim policy** li tiggverna x-xorti tal-PV, u — b'mod kritiku — li Kubernetes jipprovdi l-identità u l-storage imma **ir-replikazzjoni u l-clustering fil-livell tal-applikazzjoni jibqgħu r-responsabbiltà tiegħek**, spiss iddelegati lil Operator. Peress li d-durabbiltà tad-data u l-imġiba stateful korretta ma jaħfrux (żbalji jfissru telf ta' data jew split-brain), li tqabbad l-StatefulSets, il-PVs/PVCs, u t-twissijiet tagħhom huwa fundamentali biex tħaddem databases u sistemi stateful oħra b'mod affidabbli fuq Kubernetes.

Għaliex id-Deployments mhumiex biżżejjed

Garanziji tal-StatefulSet

Storage persistenti: PV, PVC, StorageClass

StatefulSet b'storage għal kull Pod

Access modes u twissijiet

Għaliex huwa importanti

Mistoqsijiet relatati