StatefulSet ve Deployment Arasindaki Farklar: Kritik Noktalar

Kubernetes kullanan ekiplerde en yaygin mimari hatalardan biri, stateful workload'u Deployment ile calistirmak veya stateless bir servisi gereksiz yere StatefulSet'e koymaktir. Kisa vadede calisir gibi gorunse de uzun vadede veri kaybi, rollout sorunlari ve operasyonel karmaşa yaratir.

Bu yazida StatefulSet ve Deployment arasindaki farklari teknik detaylariyla inceleyecegiz.

Kisa Cevap

Deployment: Stateless uygulamalar icin.
StatefulSet: Kimlik, sira ve kalici disk gerektiren stateful uygulamalar icin.

Cizim: Deployment Mimarisi

Deployment (stateless)

            +--------------------+
            |    Deployment      |
            +---------+----------+
                      |
        +-------------+-------------+
        |             |             |
    +---v---+     +---v---+     +---v---+
    | pod A |     | pod B |     | pod C |
    +---+---+     +---+---+     +---+---+
        |             |             |
        +-------------+-------------+
                      |
               Service (L4/L7)

Pods birbirinin yerine gecebilir, ad ve disk baglantisi kalici degildir.

Cizim: StatefulSet Mimarisi

StatefulSet (stateful)

            +---------------------+
            |    StatefulSet      |
            +----------+----------+
                       |
         sirali olusum / sirali update
                       |
     +-----------------+-----------------+
     |                 |                 |
+----v-----+     +-----v----+      +-----v----+
| pod-0    |     | pod-1    |      | pod-2    |
| stable id|     | stable id|      | stable id|
+----+-----+     +-----+----+      +-----+----+
     |                 |                 |
 +---v----+        +---v----+        +---v----+
 | pvc-0  |        | pvc-1  |        | pvc-2  |
 +--------+        +--------+        +--------+

Her pod kendi kalici diski ve sabit ag kimligi ile yasar.

Temel Farklar (Teknik Ozeti)

Kimlik
- Deployment podlari degisebilir kimlige sahiptir.
- StatefulSet podlari name-ordinal formatinda sabittir (db-0, db-1).
Storage
- Deployment'da PVC paylasimi mimariye baglidir, pod bireysel disk kimligi garanti edilmez.
- StatefulSet her pod icin ayrik PVC yaratir (volumeClaimTemplates).
Olusturma/Silme Sirasi
- Deployment podlari paralel olusur/silinir.
- StatefulSet varsayilan olarak sirali olusturur/siler (0 -> 1 -> 2).
Update Davranisi
- Deployment rolling update stateless yaklasimla hizlidir.
- StatefulSet update stratejisi daha kontrolludur; state migration senaryolari icin kritiktir.

Hangi Serviste Hangisi?

Deployment icin uygun workloadlar

HTTP API servisleri
Web frontend/BFF katmani
Stateless workerlar
Cache-aside pattern kullanan ve state'i disarida tutan servisler

StatefulSet icin uygun workloadlar

PostgreSQL, MySQL, MongoDB node'lari
Kafka, ZooKeeper, etcd benzeri cluster uyeleri
Replica identity gerektiren queue/state engine'leri
Her podun kendine ait data diskine ihtiyac duydugu durumlar

Kritik Noktalar: StatefulSet Kullanirken

1) Headless Service Gerekliligi

StatefulSet podlarini DNS ile tekil adreslemek icin headless service kullanilir:

serviceName: my-db-headless

Bu sayede my-db-0.my-db-headless gibi deterministik host isimleri elde edilir.

2) volumeClaimTemplates Dogru Boyutlandirma

Yanlis disk boyutu secimi veya storage class secimi performansi direkt etkiler. Disk IO sinirlarini test etmeden production'a cikmak risklidir.

3) PodDisruptionBudget (PDB)

Bakim veya node drain aninda tum replica'larin ayni anda dusmesini engellemek icin PDB kritik rol oynar.

4) Backup + Restore Stratejisi

PVC var diye "veri guvende" varsayimi yanlistir. Periyodik yedek, restore tatbikati ve RPO/RTO hedefleri tanimli olmali.

5) Ordered vs Parallel Pod Management

Default sirali yonetim guvenli ama yavas olabilir. Uygun senaryoda Parallel ile hiz kazanabilirsiniz; ancak cluster software'inizin bu davranisa uyumlu oldugundan emin olun.

Kritik Noktalar: Deployment Kullanirken

1) Gercekten Stateless misin?

Uygulama local dosya yaziyor veya process memory'de kritik state tutuyorsa deployment semantigiyle cakisabilir.

2) Readiness / Liveness Probe

Yanlis probe konfigrasyonu rolling update sirasinda kesinti uretebilir.

3) HPA ile Birlikte Davranis

Autoscaling politikalari application startup suresiyle uyumlu olmali. Aksi halde pod churn artar.

4) Session Management

Session local memory'de ise replica artinca tutarsizlik olur. Session'i Redis gibi merkezi store'a tasimak gerekir.

Ornek YAML: Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
        - name: api
          image: ghcr.io/example/api:1.0.0
          ports:
            - containerPort: 8080

Ornek YAML: StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres-headless
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 100Gi

Sık Yapilan Hatalar

Stateful database'i Deployment ile calistirmak
StatefulSet kullaniminda backup stratejisini atlamak
Probe/PDB/anti-affinity tanimlarini eksik birakmak
Storage performansini (IOPS/throughput) test etmeden yayina cikmak

Karar Cercevesi (Pratik)

Su sorulara "evet" diyorsan StatefulSet dusun:

Her replica'nin sabit kimlige ihtiyaci var mi?
Her replica kendi kalici diskini mi tutmali?
Baslangic/siralama semantigi kritik mi?

Cevaplar "hayir" ise Deployment cogu zaman daha basit ve daha dogru secimdir.

Sonuc

StatefulSet vs Deployment secimi bir Kubernetes YAML tercihi degil, uygulamanin state modelinin dogru tanimidir. Yanlis secim ilk gun degil, olcek buyudugunde problem yaratir.

Basit kural:

State yok -> Deployment
State var + kimlik/sira/disk kritik -> StatefulSet

Dogru yerde dogru primitive kullanmak, uzun vadede en buyuk operasyonel kazanimi saglar.