StatefulSet, PersistentVolume/Claim nedir ve Kubernetes'te stateful workload'ları nasıl çalıştırırsınız?

Question

IT Interview Practice · Accepted Answer

Stateful workload'lar (veritabanları, kuyruklar, cluster'lı store'lar) **kararlı kimliğe** ve **kalıcı depolamaya** ihtiyaç duyar — bir Deployment'ın sağlamadığı şeyler. Bir **StatefulSet** Pod'lara kararlı adlar ve sıralı yaşam döngüsü verir; **PersistentVolume (PV)** ve **PersistentVolumeClaim (PVC)** onlara Pod'dan daha uzun ömürlü depolama verir.

## Deployment'lar neden yeterli değil

```text
Deployment Pod'ları BİRBİRİNİN YERİNE GEÇEBİLİR: rastgele adlar (web-7f9-abc), herhangi bir sıra,
Pod başına hiçbir şey paylaşmaz. Bu stateless app'ler için mükemmeldir — ama bir veritabanı replica'sının:
  → KARARLI bir ağ kimliğine ihtiyacı var (böylece peer'lar onu bulur: db-0, db-1, db-2)
  → restart/yeniden schedule'dan sağ çıkan KENDİ kalıcı diskine
  → SIRALI, kontrollü başlatma/ölçekleme (db-1'den önce db-0'ı ayağa kaldır)
StatefulSet tam olarak bunları sağlar.
```

## StatefulSet garantileri

```text
Kararlı ADLAR     → pod-0, pod-1, pod-2 (sıra numaralı, rastgele değil)
Kararlı DNS       → headless Service üzerinden db-0.db.default.svc...
Kararlı DEPOLAMA  → her Pod KENDİ PVC'sini alır (db-0 restart'lar boyunca diskini korur)
Sıralı işlemler   → 0,1,2… sırasıyla oluştur/ölçek büyüt; tersten sonlandır
```

## Kalıcı depolama: PV, PVC, StorageClass

```text
StorageClass → "nasıl provision edilir" şablonu (örn. AWS gp3, fast-ssd)
PVC          → bir depolama İSTEĞİ ("20Gi, ReadWriteOnce lazım")   ← uygulamaya dönük
PV           → PVC'ye bağlanan GERÇEK provision edilmiş volume       ← cluster'a dönük
Dinamik provisioning: bir StorageClass'a atıfta bulunan PVC eşleşen bir PV'yi otomatik oluşturur.

App → PVC → (StorageClass provision eder) → PV → gerçek disk (EBS, PD, Ceph, NFS…)
```

## Pod başına depolamaya sahip bir StatefulSet

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # kararlı DNS için headless Service
  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:      # her Pod bu şablondan KENDİ PVC/PV'sini alır
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Pod başına kararlı DNS veren headless Service (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'lar & uyarılar

```text
ReadWriteOnce (RWO)  → TEK bir node tarafından okuma-yazma mount edilir (çoğu blok depolama: EBS/PD)
ReadOnlyMany (ROX)   → birçok node tarafından salt-okunur
ReadWriteMany (RWX)  → birçok node tarafından okuma-yazma (NFS/CephFS/EFS gerektirir)
⚠ Bir StatefulSet'i silmek varsayılan olarak PVC'lerini SİLMEZ (veri korunur).
⚠ Reclaim policy (Retain/Delete), PVC kaldırıldığında PV'ye ne olacağına karar verir.
⚠ Kubernetes kimlik+depolama verir, ama uygulama seviyesi cluster'lama/replikasyon SİZİN işiniz
  (çoğu zaman bir Operator ile, örn. Postgres/Kafka için).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (kararlı, sıralı)
```

## Neden önemli

Stateful workload'ları doğru çalıştırmak Kubernetes'in daha zor parçalarından biridir; bu yüzden StatefulSet'leri ve kalıcı depolamayı anlamak, gerçek production sonuçları olan senior seviye bir bilgidir. Çekirdek içgörü, Deployment'ların *neden* yetersiz kaldığıdır: Pod'ları birbirinin yerine geçebilir (rastgele adlar, herhangi bir sıra, Pod başına state yok); bu stateless servisler için idealdir ama **kararlı kimliğe** (peer'ların `db-0`, `db-1`, `db-2`'yi DNS ile bulabilmesi için), restart ve yeniden schedule'dan sağ çıkan **kendi kalıcı diskine** ve **sıralı, kontrollü** başlatma ve ölçeklemeye ihtiyaç duyan veritabanları ve cluster'lı store'lar için yanlıştır. Bir **StatefulSet** tam olarak bu garantileri sağlar ve depolama soyutlamalarıyla eşleşir: bir **PersistentVolumeClaim** uygulamaya dönük depolama isteğidir, bir **PersistentVolume** gerçek provision edilmiş volume'dur ve bir **StorageClass** dinamik provisioning'i mümkün kılar — `volumeClaimTemplates` her Pod'a kendi PVC/PV'sini verir. Uyarılar, senior mühendislerin ekmeğini kazandığı yerdir: **access mode'lar** (RWO vs RWX ve hangi backend'lerin desteklediği), bir StatefulSet'i silmenin varsayılan olarak **PVC'lerini koruması**, PV'nin akıbetini yöneten **reclaim policy** ve — kritik olarak — Kubernetes'in kimlik ve depolama sağladığı ama **uygulama seviyesi replikasyon ve cluster'lamanın sizin sorumluluğunuzda kaldığı**, çoğu zaman bir Operator'a devredildiği gerçeği. Veri kalıcılığı ve doğru stateful davranış affetmez olduğundan (hatalar veri kaybı veya split-brain demektir), StatefulSet'lere, PV/PVC'lere ve uyarılarına hâkim olmak, Kubernetes'te veritabanlarını ve diğer stateful sistemleri güvenilir çalıştırmanın temelidir.

Deployment'lar neden yeterli değil

StatefulSet garantileri

Kalıcı depolama: PV, PVC, StorageClass

Pod başına depolamaya sahip bir StatefulSet

Access mode'lar & uyarılar

Neden önemli

İlgili sorular