ما هي StatefulSets وPersistentVolumes/Claims، وكيف تشغّل الـ workloads ذات الحالة (stateful) على Kubernetes؟

Question

IT Interview Practice · Accepted Answer

تحتاج الـ workloads ذات الحالة (قواعد البيانات، الطوابير، المخازن العنقودية) إلى **هويّة ثابتة** و**تخزين دائم** — وهي أشياء لا يوفّرها الـ Deployment. يمنح الـ **StatefulSet** الـ Pods أسماءً ثابتةً ودورة حياة مرتّبة؛ وتمنحها **PersistentVolumes (PV)** و**PersistentVolumeClaims (PVC)** تخزيناً يبقى بعد فناء الـ Pod.

## لماذا لا تكفي الـ Deployments

```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            # Service من نوع headless لأجل 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:      # كل Pod يحصل على PVC/PV خاص به من هذا القالب
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# الـ Service من نوع headless الذي يمنح DNS ثابتاً لكل Pod (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## أنماط الوصول والتحذيرات

```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 (ثابتة، مرتّبة)
```

## لماذا يهم

تشغيل الـ workloads ذات الحالة بشكل صحيح من أصعب أجزاء Kubernetes، لذا فإن فهم StatefulSets والتخزين الدائم معرفة بمستوى كبير (senior) لها تبعات إنتاجية حقيقية. الاستنتاج الجوهري هو *لماذا* تقصّر الـ Deployments: فـ Pods الخاصة بها قابلة للتبديل (أسماء عشوائية، أيّ ترتيب، دون حالة خاصة بكل Pod)، وهذا مثالي للخدمات عديمة الحالة لكنه خطأ لقواعد البيانات والمخازن العنقودية التي تحتاج إلى **هويّة ثابتة** (كي يجد الأقران `db-0` و`db-1` و`db-2` عبر DNS)، و**قرصها الدائم الخاص** الذي يبقى عبر إعادة التشغيل وإعادة الجدولة، و**بدء وتوسيع مرتّب ومتحكّم فيه**. يوفّر الـ **StatefulSet** هذه الضمانات بالضبط، ويقترن بتجريدات التخزين: فالـ **PersistentVolumeClaim** هو طلب التخزين الموجّه للتطبيق، والـ **PersistentVolume** هو الوحدة المُوفَّرة الفعلية، والـ **StorageClass** يمكّن التوفير الديناميكي — مع `volumeClaimTemplates` الذي يمنح كل Pod الـ PVC/PV الخاص به. التحذيرات هي حيث يثبت المهندسون الكبار جدارتهم: **أنماط الوصول** (RWO مقابل RWX وأيّ الخلفيّات تدعمها)، وحقيقة أن حذف StatefulSet **يحفظ الـ PVCs الخاصة به** افتراضياً، و**سياسة الاستعادة (reclaim policy)** التي تحكم مصير الـ PV، و — بشكل حاسم — أن Kubernetes يوفّر الهويّة والتخزين لكن **النسخ المتماثل والعنقدة على مستوى التطبيق تبقى مسؤوليتك**، وغالباً تُفوَّض إلى Operator. ولأن ديمومة البيانات والسلوك الصحيح لذي الحالة لا يغتفران الأخطاء (فالأخطاء تعني فقدان البيانات أو انقسام الدماغ (split-brain))، فإن إتقان StatefulSets وPVs/PVCs وتحذيراتها أساسٌ لتشغيل قواعد البيانات وسائر الأنظمة ذات الحالة بموثوقية على Kubernetes.

لماذا لا تكفي الـ Deployments

ضمانات StatefulSet

التخزين الدائم: PV، PVC، StorageClass

StatefulSet مع تخزين خاص لكل Pod

أنماط الوصول والتحذيرات

لماذا يهم

أسئلة ذات صلة