რა არის StatefulSet-ები, PersistentVolume/Claim-ები და როგორ უშვებთ stateful workload-ებს Kubernetes-ზე?

Question

IT Interview Practice · Accepted Answer

Stateful workload-ებს (მონაცემთა ბაზები, რიგები, კლასტერიზებული საცავები) სჭირდებათ **სტაბილური იდენტობა** და **მდგრადი მეხსიერება** — რასაც Deployment არ იძლევა. **StatefulSet** აძლევს Pod-ებს სტაბილურ სახელებსა და მოწესრიგებულ სასიცოცხლო ციკლს; **PersistentVolume-ები (PV)** და **PersistentVolumeClaim-ები (PVC)** აძლევენ მათ მეხსიერებას, რომელიც Pod-ს გადაურჩება.

## რატომ არ არის საკმარისი Deployment-ები

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

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

## მდგრადი მეხსიერება: 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 თითო-Pod-ზე მეხსიერებით

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service სტაბილური 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:      # ამ template-იდან თითო Pod თავის PVC/PV-ს იღებს
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# 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 }]
```

## Access mode-ები და გაფრთხილებები

```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 (სტაბილური, მოწესრიგებული)
```

## რატომ არის ეს მნიშვნელოვანი

stateful workload-ების სწორად გაშვება Kubernetes-ის ერთ-ერთი უფრო რთული ნაწილია, ამიტომ StatefulSet-ებისა და მდგრადი მეხსიერების გაგება senior-დონის ცოდნაა რეალური production შედეგებით. ძირითადი შეხედულება არის *რატომ* ჩამორჩება Deployment-ები: მათი Pod-ები ურთიერთშენაცვლებადია (შემთხვევითი სახელები, ნებისმიერი რიგი, თითო-Pod მდგომარეობის გარეშე), რაც იდეალურია stateless სერვისებისთვის, მაგრამ არასწორია მონაცემთა ბაზებისა და კლასტერიზებული საცავებისთვის, რომლებსაც სჭირდებათ **სტაბილური იდენტობა** (რომ peer-ებმა `db-0`, `db-1`, `db-2` DNS-ით იპოვონ), **საკუთარი მდგრადი დისკი**, რომელიც restart-ებსა და გადაგეგმვას გადაურჩება, და **მოწესრიგებული, კონტროლირებადი** გაშვება და მასშტაბირება. **StatefulSet** სწორედ ამ გარანტიებს იძლევა და ის მეხსიერების აბსტრაქციებთან იწყვილება: **PersistentVolumeClaim** არის აპლიკაციაზე ორიენტირებული მოთხოვნა მეხსიერებაზე, **PersistentVolume** არის რეალურად გამოყოფილი volume, ხოლო **StorageClass** დინამიურ გამოყოფას (provisioning) აძლიერებს — სადაც `volumeClaimTemplates` თითოეულ Pod-ს საკუთარ PVC/PV-ს აძლევს. გაფრთხილებებია, სადაც senior ინჟინრები თავიანთ ღირებულებას ამტკიცებენ: **access mode-ები** (RWO vs RWX და რომელი backend-ები უჭერენ მხარს), ის ფაქტი, რომ StatefulSet-ის წაშლა ნაგულისხმევად **მისი PVC-ების შენარჩუნებას** ახდენს, **reclaim policy**, რომელიც PV-ის ბედს განსაზღვრავს, და — კრიტიკულად — რომ Kubernetes იდენტობასა და მეხსიერებას იძლევა, მაგრამ **აპლიკაციის დონის რეპლიკაცია და კლასტერიზაცია თქვენი პასუხისმგებლობა რჩება**, ხშირად Operator-ს დელეგირებული. რადგან მონაცემთა მდგრადობა და სწორი stateful ქცევა შეუწყნარებელია (შეცდომები ნიშნავს მონაცემთა დაკარგვას ან split-brain-ს), StatefulSet-ების, PV/PVC-ებისა და მათი გაფრთხილებების დაუფლება ფუნდამენტურია მონაცემთა ბაზებისა და სხვა stateful სისტემების Kubernetes-ზე საიმედოდ გასაშვებად.

რატომ არ არის საკმარისი Deployment-ები

StatefulSet-ის გარანტიები

მდგრადი მეხსიერება: PV, PVC, StorageClass

StatefulSet თითო-Pod-ზე მეხსიერებით

Access mode-ები და გაფრთხილებები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები