Kubernetes'te canary deploy: ArgoCD + Argo Rollouts ile pratik

Üretimde “deploy butonuna basıp kahvenizi içmek” mümkündür — eğer doğru altyapı kurulmuşsa. Kubernetes ekosisteminde bu altyapının iki temeli ArgoCD (GitOps) ve Argo Rollouts (gelişmiş deployment stratejileri).

Neden basit Deployment yetmiyor?

Kubernetes’in standart Deployment kaynağı rolling update yapar: pod’lar tek tek değiştirilir. Ama:

• Canary yüzdesi (örneğin %5’e %95) belirleyemezsiniz.
• Otomatik metrik analizi yoktur (hata oranı yükselirse durdur).
• Manuel onay adımı yoktur.

Argo Rollouts, Deployment‘ın yerine geçen bir CRD (Rollout) sunar; canary, blue-green ve experiment stratejileri sağlar.

Asgari canary akışı

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-api
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 10m }
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100

pause duraklatmaları sırasında analysis template çalışır; Prometheus’tan SLI sorgular, eşik altına düşerse otomatik geri-alma yapılır.

AnalysisTemplate örneği

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      successCondition: result[0] >= 0.99
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{job="payment-api",code!~"5.."}[5m]))
            /
            sum(rate(http_requests_total{job="payment-api"}[5m]))

Burada başarı oranı %99 altına düşerse rollout otomatik durur ve eski sürüme döner.

Mono’nun pratiği

Kurulumlarımızda canary akışını şu kararlarla şekillendiriyoruz:

1. Trafik bölme için Service Mesh (Istio veya Linkerd) yerine gateway katmanı (Traefik / Kong) tercih ediyoruz; daha az operasyonel yük.
2. Analiz aralığı en az 5 dakika; daha kısa aralıklarda metrik gürültüsü yanlış tetik veriyor.
3. Otomatik geri-alma şart; manuel “biri bakar” çözümü gece 3’te işlemiyor.
4. Notification kanalı: Slack + Grafana annotation.

Üretimde 80+ servis için ArgoCD + Argo Rollouts kombinasyonunu, son 18 ayda sıfır rollout-kaynaklı olay ile çalıştırdık.

Yaygın tuzaklar

• HPA + Rollouts çakışması. Argo Rollouts replica sayısını yönetir; HPA aynı kaynağa müdahale ederse spec.template değişikliği ile birlikte chaotic davranış olur. Çözüm: HPA’yı Rollout kaynağına yönlendirin.
• Statik kaynak limitleri. Canary’nin %5 trafiği bile pod CPU limit’i düşükse throttling yapar; metrik sapar. Limit + isteklerini ortalama trafik üzerinden plan’layın.
• Stateful servisler. Veritabanı şeması değişen sürümlerde canary doğru çalışmaz. Şema değişiklikleri expand-contract pattern ile ayrı release döngüsünde gönderilmeli.

Sıradaki adımlar

Eğer canary’yi yeni kuruyorsanız: ilk olarak bir non-kritik servis üzerinde 2 hafta deneyin. Analysis template’lerin doğru tetiklendiğini ve rollback’in beklendiği gibi çalıştığını gözlemleyin. Sonra kademeli olarak kritik servislere taşıyın.

İhtiyacınız varsa, DevOps, konteyner ve mikroservis tasarım ve yönetimi kapsamında ekibinize özel canary referans mimarisi kuruyoruz.