Çfarë janë StatefulSet-et, PersistentVolume/Claim-et, dhe si drejton workload-e stateful në Kubernetes?

Question

IT Interview Practice · Accepted Answer

Workload-et stateful (database, radhë, kohë të grumbulluara) kanë nevojë për **identitet të qëndrueshëm** dhe **storage të qëndrueshëm** — gjëra që një Deployment nuk i ofron. Një **StatefulSet** u jep Pod-eve emra të qëndrueshëm dhe cikël jete të renditur; **PersistentVolume (PV)** dhe **PersistentVolumeClaim (PVC)** u japin storage që mbijeton Pod-in.

## Pse Deployment-et nuk mjaftojnë

```text
Pod-et e Deployment janë TË KËMBYESHËM: emra të rastësishëm (web-7f9-abc), çdo renditje, nuk ndajnë
asgjë për çdo Pod. Kjo është perfekte për app stateless — por një replica database ka nevojë për:
  → një IDENTITET rrjeti TË QËNDRUESHËM (që peer-at ta gjejnë: db-0, db-1, db-2)
  → disk-un E VET të qëndrueshëm që mbijeton restart-e/rischeduling
  → nisje/scaling TË RENDITUR, të kontrolluar (ngri db-0 para db-1)
StatefulSet ofron pikërisht këto.
```

## Garancitë e StatefulSet

```text
EMRA të qëndrueshëm  → pod-0, pod-1, pod-2 (rendorë, jo të rastësishëm)
DNS i qëndrueshëm    → db-0.db.default.svc... nëpërmjet një headless Service
STORAGE i qëndrueshëm → çdo Pod merr PVC-në E VET (db-0 mban disk-un e tij nëpër restart-e)
Operacione të renditura → krijo/scale up në renditje 0,1,2…; përfundo në të kundërt
```

## Storage i qëndrueshëm: PV, PVC, StorageClass

```text
StorageClass → template-i "si të sigurohet" (p.sh. AWS gp3, fast-ssd)
PVC          → një KËRKESË për storage ("Më duhen 20Gi, ReadWriteOnce")   ← nga ana e app-it
PV           → volume-i FAKTIK i siguruar i lidhur me PVC-në               ← nga ana e cluster-it
Sigurim dinamik: një PVC që referon një StorageClass krijon automatikisht një PV që përputhet.

App → PVC → (StorageClass siguron) → PV → disk real (EBS, PD, Ceph, NFS…)
```

## Një StatefulSet me storage për çdo Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service për DNS të qëndrueshëm
  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:      # çdo Pod merr PVC/PV-në E VET nga ky template
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Headless Service që jep DNS të qëndrueshëm për çdo 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 mode & paralajmërime

```text
ReadWriteOnce (RWO)  → mount-uar read-write nga NJË node (shumica e block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only nga shumë node
ReadWriteMany (RWX)  → read-write nga shumë node (kërkon NFS/CephFS/EFS)
⚠ Fshirja e një StatefulSet NUK i fshin PVC-t e tij si default (të dhënat ruhen).
⚠ Reclaim policy (Retain/Delete) vendos çfarë i ndodh PV-së kur PVC-ja hiqet.
⚠ Kubernetes jep identitet+storage, por clustering/replication në nivel app është PUNA JOTE
  (shpesh nëpërmjet një Operator, p.sh. për Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (të qëndrueshëm, të renditur)
```

## Pse ka rëndësi

Drejtimi i workload-eve stateful në mënyrë të saktë është një nga pjesët më të vështira të Kubernetes, kështu që të kuptuarit e StatefulSet-eve dhe storage-it të qëndrueshëm është njohuri e nivelit senior me pasoja reale production. Njohuria thelbësore është *pse* Deployment-et mbeten mangët: Pod-et e tyre janë të këmbyeshëm (emra të rastësishëm, çdo renditje, pa gjendje për çdo Pod), që është ideale për service stateless por e gabuar për database dhe kohë të grumbulluara që kanë nevojë për **identitet të qëndrueshëm** (që peer-at të gjejnë `db-0`, `db-1`, `db-2` sipas DNS), **disk-un e vet të qëndrueshëm** që mbijeton restart-e dhe rescheduling, dhe nisje e scaling **të renditur, të kontrolluar**. Një **StatefulSet** ofron pikërisht këto garanci, dhe çiftohet me abstraksionet e storage-it: një **PersistentVolumeClaim** është kërkesa nga ana e aplikacionit për storage, një **PersistentVolume** është volume-i faktik i siguruar, dhe një **StorageClass** mundëson sigurim dinamik — me `volumeClaimTemplates` që i japin çdo Pod PVC/PV-në e vet. Paralajmërimet janë aty ku inxhinierët senior fitojnë bukën: **access mode** (RWO vs RWX dhe cilët backend i mbështesin), fakti që fshirja e një StatefulSet **ruan PVC-t e tij** si default, **reclaim policy** që qeveris fatin e PV-së, dhe — vendimtare — që Kubernetes ofron identitet dhe storage por **replication dhe clustering në nivel aplikacioni mbeten përgjegjësia jote**, shpesh e deleguar te një Operator. Meqë qëndrueshmëria e të dhënave dhe sjellja e saktë stateful janë të pafalshme (gabimet do të thonë humbje të dhënash ose split-brain), zotërimi i StatefulSet-eve, PV/PVC-ve, dhe paralajmërimeve të tyre është themelor për të drejtuar database dhe sisteme të tjera stateful në mënyrë të besueshme në Kubernetes.

Pse Deployment-et nuk mjaftojnë

Garancitë e StatefulSet

Storage i qëndrueshëm: PV, PVC, StorageClass

Një StatefulSet me storage për çdo Pod

Access mode & paralajmërime

Pse ka rëndësi

Pyetje të ngjashme