Canary dağıtımı etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Canary dağıtımı etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

17 Aralık 2025 Çarşamba

Kubernetes’te Argo Rollouts ile Canary Dağıtımı: Adım Adım Kurulum ve Ölçüme Dayalı Otomasyon

Özet

Canary dağıtımı, üretimde yeni sürümü küçük bir trafik yüzdesiyle deneyerek hataları erken yakalamayı hedefleyen, modern ve güvenli bir yayınlama tekniğidir. Bu yazıda, Kubernetes üzerinde Argo Rollouts kullanarak canary dağıtımı nasıl kurulur, NGINX Ingress ile trafik nasıl paylaştırılır ve Prometheus ile ölçüme dayalı otomatik promosyon/geri alma (rollback) nasıl yapılır adım adım anlatıyorum.

Neden Argo Rollouts?

Argo Rollouts, Kubernetes’in Deployment nesnesine gelişmiş progressive delivery yetenekleri ekleyen bir CRD (Custom Resource Definition) çözümüdür. Canary, Blue/Green, A/B testleri, metric tabanlı onaylar, otomatik rollback ve NGINX/ALB/Istio gibi çoklu trafik yöneticileri desteği sunar. Tek komutla izleme ve görselleştirme sağlayan kubectl argo rollouts eklentisi ile süreç oldukça şeffaftır.

Gereksinimler

- Kubernetes 1.21+ bir küme (yerelde kind/minikube veya bulutta managed).
- kubectl ve yönettiğiniz namespace üzerinde yetki.
- NGINX Ingress Controller (canary anotasyonlarını destekleyen sürüm).
- Prometheus (temel HTTP başarı oranı ölçümü için).

Kurulum

1) Argo Rollouts CRD ve kontrol düzlemini kurun:
kubectl apply -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

2) Komut satırı eklentisini yükleyin (macOS örneği):
brew install argoproj/tap/kubectl-argo-rollouts
Linux/Windows için ikili dosyayı Argo Rollouts sürüm sayfasından indirip PATH’e ekleyebilirsiniz.

3) NGINX Ingress Controller kurulu değilse resmi manifest ya da Helm chart ile kurun. Trafik yönlendirme için Rollout nesnesinde trafficRouting: nginx kullanacağız.

Manifest Tasarımı

Canary stratejisinde iki Service kullanılır: stable ve canary. Ingress, Argo Rollouts tarafından ağırlıklandırılmış şekilde bu Service’lere trafik dağıtır. Aşağıdaki örnekler özlü tutulmuştur; isimleri ve etiketleri kendi uygulamanıza göre uyarlayın.

Stable ve Canary Service (aynı selector’ı paylaşır, Rollouts yönetir):
apiVersion: v1
kind: Service
metadata:
  name: myapp-stable
spec:
  selector:
   app: myapp
  ports:
  - port: 80
    targetPort: 8080

apiVersion: v1
kind: Service
metadata:
  name: myapp-canary
spec:
  selector:
   app: myapp
  ports:
  - port: 80
    targetPort: 8080

Ingress (Argo Rollouts, bu Ingress’i kullanarak NGINX canary anotasyonlarıyla ağırlık verir):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
 - host: myapp.example.com
   http:
    paths:
    - path: /
     pathType: Prefix
     backend:
      service:
       name: myapp-stable
       port:
        number: 80

AnalysisTemplate (Prometheus ile başarı oranı ölçümü):
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service
  metrics:
  - name: http-success-rate
   interval: 30s
   count: 3
   successCondition: result[0] >= 0.99
   failureLimit: 1
   provider:
    prometheus:
     address: http://prometheus-server.monitoring.svc.cluster.local:9090
     query: sum(rate(http_requests_total{service="{{args.service}}",code=~"2.."}[1m])) / sum(rate(http_requests_total{service="{{args.service}}"}[1m]))

Rollout (canary adımları, NGINX trafik yönlendirme ve metrik analizi ile):
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 4
  selector:
   matchLabels:
    app: myapp
  template:
   metadata:
    labels:
     app: myapp
   spec:
    containers:
    - name: web
     image: ghcr.io/org/myapp:1.1.0
     ports:
     - containerPort: 8080
  strategy:
   canary:
    canaryService: myapp-canary
    stableService: myapp-stable
    trafficRouting:
     nginx:
      stableIngress: myapp-ingress
    steps:
    - setWeight: 20
    - pause: { duration: 120 }
    - analysis:
      templates:
      - templateName: success-rate
       args:
       - name: service
        value: myapp
    - setWeight: 50
    - pause: { duration: 120 }

Dağıtımı Başlatma ve İzleme

Manifestleri uygulayın: kubectl apply -f . Ardından rollout durumunu canlı izleyin: kubectl argo rollouts get rollout myapp -w. Eklenti, hangi adımda olunduğunu, mevcut ağırlığı ve analiz sonuçlarını gösterir. Metrikler eşik altında kalırsa Argo Rollouts otomatik rollback yapar; eşik üstünde ise bir sonraki adıma geçer ve sonunda sürüm terfi eder.

İpuçları ve En Sık Yapılan Hatalar

- Prometheus sorgunuzun doğru label’ları kullandığından emin olun. Bazı exporter’larda HTTP durum etiketi code yerine status olabilir.
- NGINX Ingress sürümünüzün canary anotasyonlarını desteklediğini doğrulayın; aksi halde ağırlıklandırma çalışmaz.
- Düşük trafik ortamlarında oran metrikleri dalgalıdır. interval ve count değerlerini artırmak yalancı negatifleri azaltır.
- Rollout öncesi readinessProbe ve livenessProbe ayarlarını düzgün yapılandırın; aksi halde analiz başlamadan pod’lar çakılabilir.

Performans ve Maliyet Değerlendirmesi

Canary adımları önemlidir çünkü ağ ve uygulama gecikmelerindeki küçük oynamaları yakalar. Ancak her adımda fazladan pod ve ölçüm maliyeti oluşur. Kritik servisler için 20%→50%→100% gibi 2-3 adıma bölmek çoğu senaryoda yeterli olur. Trafik çok yüksekse daha fazla adım ve daha uzun duraklatmalarla güvenlik marjı artırılabilir.

Sonuç

Argo Rollouts, Kubernetes üzerinde canary dağıtımını pratik ve güvenli hale getiriyor. NGINX Ingress ile trafik ağırlıklandırma ve Prometheus ile metrik bazlı doğrulama birleştiğinde, üretimde hataları kullanıcıların küçük bir yüzdesiyle sınırlayıp otomatik geri alma yapabilirsiniz. Küçükten başlayın, metriklerinizi doğrulayın ve ihtiyaçlarınıza göre adım sayısı ile eşikleri düzenleyerek olgun bir progressive delivery akışı elde edin.

23 Ağustos 2025 Cumartesi

Kubernetes'te GitOps ile Canary Dağıtımı: Argo CD ve Istio ile Aşamalar ve İyi Uygulamalar

Giriş

Kubernetes üzerinde hizmet güncellemeleri yaparken "her şey ya hep ya hiç" yaklaşımı risklidir. Canary dağıtımı, yeni sürümü küçük bir kullanıcı kesimine açıp davranışı izleyerek ilerlemeye olanak verir. Bu rehberde GitOps yaklaşımıyla Argo CD kullanarak manifests tabanlı yönetim, Istio ile trafikte kademeli yönlendirme ve temel otomasyon-adımlarını ele alacağız. Amaç, tekrarlanabilir, gözlemlenebilir ve güvenli bir canary süreci kurmaktır.

Önkoşullar

Bu makaledeki adımları uygulayabilmek için aşağıdaki bileşenlere sahip olmalısınız: bir Kubernetes kümesi (1.20+ önerilir), Argo CD kurulumu, Istio servis mesh kurulumu (ingress/gateway dahil), Git deposu (manifests için) ve izleme için Prometheus/Grafana. Ayrıca kubectl, argocd CLI ve gerekli RBAC izinleri gereklidir.

1) Manifests ve GitOps Hazırlığı

Uygulamanızı Kustomize veya Helm ile paketleyin. İki ayrı sürüm manifesti tutmak faydalıdır: v1 ve v2. Git deposunda şunları organize edin: /overlays/stable (v1), /overlays/canary (v2) ve ortak base dosyalar. Argo CD bu repo'yu izleyerek kümedeki kaynakları senkronize eder. Argo CD Application manifesti ile otomatik senkronizasyon veya manuel onay tercih edilebilir.

2) Istio ile Trafik Yönlendirme

Istio VirtualService ve DestinationRule kaynakları ile servis içinde ağırlık bazlı dağıtım yapabilirsiniz. Örnek kısa yapı: bir VirtualService içinde canary için %10, %50 gibi ağırlıklar belirlenir. Örnek kontrol komutu: kubectl -n your-namespace get virtualservice. Canary sürecinde ağırlıkları Git üzerinden değiştirerek Argo CD ile otomatik olarak uygulayabilirsiniz; böylece tüm değişiklikler version kontrolünde kalır.

3) Otomasyon ve Güvenlik: Argo CD + Webhook

Manifests'te ağırlık değişiklikleri bir PR ile yapılır. CI pipeline'ınız bu PR'ı doğrular (lint, güvenlik taramaları). Merge sonrası Argo CD otomatik senkronize eder. Opsiyonel: bir webhook ile Argo CD sync tamamlandığında Prometheus sorguları tetikleyerek sağlık kontrolü başlatabilirsiniz. Eğer belirlenen SLO/SLA dışı metrikler tespit edilirse, otomatik rollback için Argo CD uygulamasına geri alma tetiklenebilir.

4) Gözlemlenebilirlik ve Karar Kriterleri

Canary'nin başarılı sayılması için ölçülebilir kriterler belirleyin: hata oranı, p99 gecikme, throughput ve kullanıcı deneyimi metrikleri. Prometheus'ta sorgular tanımlayın, Grafana panelleri oluşturun ve Alertmanager ile eşik aşımlarında uyarı üretin. Otomasyon için bu uyarılar webhook ile rollback sürecini başlatabilir.

5) İleri Seviye İpuçları

- İzolasyon: Canary pod'larını ayrı bir node pool veya kaynak sınırlamaları ile izole edin. - A/B test yerine istatistiksel güven: Trafik artışlarını küçük adımlarla yapın (örn. %5, %20, %50). - Trafik yönlendirme dışında shadowing ile gerçek üretim trafiğini yeni sürüme de gönderip yalnızca gözlemleyebilirsiniz. - Rollback kriterlerini mutlaka otomatik hale getirin; manuel müdahale süresini minimize edin. - Argo Rollouts kullanmak istiyorsanız, Rollout CRD'si ile Istio'yu entegre ederek daha ileri seviye deneyler ve analizler yapabilirsiniz.

Örnek Komut Akışı

Bir canary adımı için tipik komutlar: git checkout -b feature/canary-weight, manifests'te VirtualService ağırlığını değiştir, git commit && git push. PR merge sonrası Argo CD otomatik olarak uygulamayı senkronize eder: argocd app get my-app ve kubectl -n my-namespace get pods ile doğrulama yapabilirsiniz.

Sonuç

GitOps tabanlı canary dağıtımı, değişikliklerin izlenebilir, geri alınabilir ve tekrarlanabilir olmasını sağlar. Argo CD ile manifest kontrolünü elinizde tutarken Istio trafik yönlendirmesi sayesinde kademeli roll-out'lar yapabilirsiniz. Ancak başarının anahtarı güçlü gözlemlenebilirlik, net kabul kriterleri ve otomatik rollback mekanizmalarıdır. Bu temel adımları uygulayarak üretimde riskleri azaltabilir ve sürüm yayımlarını daha güvenilir hale getirebilirsiniz.