Docker'dan Kubernetes'e Geçiş — Ne Zaman, Nasıl ve Neden?

Neden Bu Soruyu Sormak Gerekiyor?

"Kubernetes mi kullanalım?" sorusu, her büyüyen ekibin bir noktada kafasını çarptığı tavandır. Cevap sandığınızdan çok daha bağlamsal — ve çoğu zaman yanlış zamanda sorulur.

Docker Compose ile 3 servis yönetirken gayet mutlu olabilirsiniz. Ama 15 servis, 4 ortam (dev/staging/prod/hotfix), 2 farklı cloud region ve "şu servis neden çöktü?" sorusuyla boğuşmaya başladığınızda, tablo değişir.

Bu yazıda somut bir büyüme senaryosu üzerinden gideceğiz.

Faz 1: Docker Compose Dönemi (0–5 Servis)

Başlangıçta her şey basittir:

# docker-compose.yml
services:
  api:
    build: ./api
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/app
  db:
    image: postgres:15
    volumes:
      - pg_data:/var/lib/postgresql/data

Bu aşamada Kubernetes gereksizdir. Docker Compose'un avantajları:

• Hızlı onboarding — docker compose up ile 5 dakikada çalışır
• Düşük complexity — Yeni katılımcılar kolayca kavrar
• Yerel geliştirme — Production ile aynı network yapısı

Geçiş düşünme: Henüz değil.

Faz 2: İlk Acı Noktaları (5–15 Servis)

Servis sayısı arttıkça şu problemler baş gösterir:

1. Sıfır-downtime deployment yok

# Compose ile rolling update yok — servis durur
docker compose up -d --force-recreate api
# Bu sürede API cevap vermiyor

2. Resource limiting elle

Bir servis hafızayı yutmaya başladığında tüm host etkilenir. Compose'da memory limit tanımlayabilirsiniz ama enforcement Kubernetes kadar robust değildir.

3. Multi-host imkânsız

Tek sunucu yetmemeye başladığında Compose duvara çarpar. Swarm bir çözüm ama ekosistemi Kubernetes kadar olgunlaşmış değil.

Geçiş düşünme: Sıfır-downtime deployment veya multi-host ihtiyacı doğduğunda.

Faz 3: Kubernetes Zorunlu Hale Gelir (15+ Servis)

Şu kriterlerin ikisi veya daha fazlası geçerliyse geçiş kaçınılmazdır:

• 3'ten fazla ortam (staging, canary, prod-eu, prod-us...)
• Servisler arası circuit breaking ihtiyacı
• Horizontal pod autoscaling (trafik dalgalanması)
• GitOps workflow (ArgoCD / Flux)
• Compliance gereksinimleri (network policy, RBAC)

Geçiş Süreci — Yapılan Yaygın Hatalar

❌ Hata 1: Her şeyi bir anda taşımak

"Büyük patlama" migrasyonu neredeyse her zaman başarısız olur. Doğrusu:

Hafta 1: Stateless servisleri taşı
Hafta 2: Stateful servisleri (DB) dışarıda bırak, managed servis kullan
Hafta 3: Ingress + cert-manager kur
Hafta 4: Monitoring (Prometheus/Grafana) ekle

❌ Hata 2: Helm chart yazmadan önce raw YAML ile başlamak

Raw YAML başlangıçta kolay görünür ama 20 servis sonra kopyala-yapıştır cehennemi olur. Doğrudan Helm veya Kustomize ile başlayın.

❌ Hata 3: Resource request/limit tanımlamamak

# YANLIŞ — limitsiz container
containers:
  - name: api
    image: myapp:latest

# DOĞRU
containers:
  - name: api
    image: myapp:latest
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "512Mi"
        cpu: "500m"

Limitsiz container, node'u OOMKill'e sürükler ve komşu podları etkiler.

Hangi Araçlarla Başlamalı?

Sonuç

Docker → Kubernetes geçişi bir prestij meselesi değil, operasyonel bir zorunluluk olduğunda yapılmalıdır. Erken geçiş, gereksiz complexity getirir; geç geçiş, production acılarını uzatır.

Servis sayınız 10'u geçiyor ve sıfır-downtime deployment istiyorsanız — hazırlanmaya başlayın.