Blue-Green ve Canary Deployment Stratejileri: Sıfır Downtime

Uygulama güncellemelerinde kullanıcıların kesinti yaşaması kabul edilemez. Blue-Green deployment iki ortam arasında anlık geçiş yaparken, Canary deployment trafiğin küçük bir yüzdesini yeni sürüme yönlendirerek riski minimize eder. Bu rehberde her iki stratejiyi Kubernetes ve Nginx örnekleriyle karşılaştırıyoruz.

Blue-Green Deployment

Blue-Green deployment'ta iki özdeş ortam bulunur: Blue (mevcut) ve Green (yeni). Yeni sürüm Green ortamına deploy edilir, testler geçtikten sonra trafik Blue'dan Green'e yönlendirilir. Sorun çıkarsa trafik anında Blue'ya geri döner.

blue-green-service.yaml

# Service selector'ını değiştirerek trafik yönlendirme
apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  selector:
    app: web-app
    version: green  # blue -> green geçişi
  ports:
  - port: 80
    targetPort: 3000

Canary Deployment

Canary deployment'ta yeni sürüm önce trafiğin %5-10'una sunulur. Metrikler (hata oranı, latency, CPU) izlenir ve sorun yoksa trafik kademeli olarak artırılır. Nginx Ingress ile ağırlık tabanlı yönlendirme yapılabilir.

canary-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-canary
            port:
              number: 80

Strateji Karşılaştırması

Özellik	Blue-Green	Canary	Rolling Update
Rollback hızı	Anlık (trafik yönlendirme)	Hızlı (canary kaldır)	Yavaş (pod'lar geri alınır)
Kaynak maliyeti	Yüksek (2x ortam)	Düşük (az sayıda canary pod)	En düşük
Risk seviyesi	Düşük (tam test sonrası geçiş)	En düşük (kademeli artış)	Orta
Karmaşıklık	Orta	Yüksek (metrik izleme gerekli)	Düşük (K8s varsayılan)

💡 İpucu: Veritabanı şema değişiklikleri içeren deploy'larda Blue-Green kullanırken dikkatli olun. Backward-compatible migration'lar yazın, aksi halde rollback sırasında veri tutarsızlığı oluşabilir.

Kubernetes temelleri için Kubernetes'e Giriş rehberimizi, GitOps ile otomatik deploy için ArgoCD rehberimizi inceleyin. İzleme için Prometheus + Grafana rehberimize göz atın. Kubernetes Deployment Strategies ve Martin Fowler - Canary Release ek kaynak olarak faydalıdır.

Sıkça Sorulan Sorular

Blue-Green deployment için iki kat kaynak gerekir mi?

Evet, geçiş anında her iki ortam da aktiftir. Ancak geçiş tamamlandıktan sonra eski ortamı kapatabilirsiniz. Bulut ortamında bu maliyet geçici ve yönetilebilirdir.

Canary deployment'ta hangi metrikleri izlemeliyim?

HTTP hata oranı (5xx), yanıt süresi (p95/p99 latency), CPU/bellek kullanımı ve iş mantığı metrikleri (sipariş başarı oranı gibi) izlenmelidir. Eşik değerleri aşıldığında otomatik rollback tetiklenmelidir.

Rolling update ne zaman yeterlidir?

Küçük değişiklikler, backward-compatible güncellemeler ve düşük riskli deploy'lar için Kubernetes'in varsayılan rolling update stratejisi yeterlidir. Büyük özellik değişiklikleri veya veritabanı migration'ları için Blue-Green veya Canary tercih edin.

Argo Rollouts nedir?

Argo Rollouts, Kubernetes'in native Deployment'ını genişleten bir controller'dır. Blue-Green ve Canary stratejilerini otomatik analiz, metrik tabanlı promotion ve otomatik rollback ile destekler.

Sonuç

Blue-Green ve Canary deployment stratejileri ile uygulamalarınızı sıfır downtime ile güncelleyebilirsiniz. Blue-Green hızlı rollback için, Canary kademeli risk azaltma için idealdir. Monitoring altyapınızı kurarak canary metrikleri izleyin ve otomatik rollback kuralları tanımlayın.

Sıfır Downtime Deploy İçin Güçlü Altyapı

Hosted Cloud sunucuları ile uygulamalarınızı kesintisiz güncelleyin.

Bulut Sunucu Planlarını İncele →