GitOps ile Infrastructure as Code: ArgoCD ve Flux Karşılaştırması

“Lokalde çalışıyordu, production’da neden patladı?” sendromunu aşmanın en sağlam yolu, altyapıyı da uygulama kodu gibi sürüm kontrol sisteminde tutmaktan geçiyor. Infrastructure as Code (IaC) felsefesinin uygulama dağıtım süreçleriyle birleşmesinden doğan GitOps yaklaşımı tam bunu yapar. Kubernetes cluster’larını yönetmenin fiili standardı haline gelen GitOps modelinde Git repomuz sistemin “Single Source of Truth” (Tek Doğruluk Kaynağı) olur.

Peki, bu ekosistemin iki büyük oyuncusu ArgoCD ve Flux arasından hangisini seçmeliyiz? Bu yazıda iki aracı karşılaştırıyor, Helm chart deployment pratiklerine bakıyor ve işler ters gittiğinde can simidimiz olacak rollback stratejilerini inceliyoruz.

Push-based ve pull-based: Neden GitOps?

Geleneksel CI/CD pipeline’larında genellikle “Push-Based” (İtme Odaklı) bir yaklaşım kullanırız. Jenkins, GitLab CI veya GitHub Actions gibi bir araç uygulamanın imajını build eder, ardından kubectl apply veya helm upgrade komutlarıyla hedef Kubernetes cluster’ına bağlanıp değişikliği push eder. Kulağa kolay geliyor, ama bu yaklaşımın iki büyük karanlık noktası var:

1. Güvenlik açığı: CI/CD aracınıza cluster üzerinde yüksek yetkili (admin) erişim anahtarları (kubeconfig) vermeniz gerekir. CI sunucunuz hacklenirse tüm cluster anahtarlarını teslim etmiş olursunuz.
2. State drift (durum sapması): Cluster üzerinde biri elle (örneğin gece yarısı hotfix’iyle) bir deployment’ı değiştirirse Git repomuzdaki kod ile canlıdaki durum birbirinden sapar. CI aracı bir sonraki sefer tetiklenene kadar bundan haberimiz olmaz.

Pull-based GitOps bu problemi tersine çevirir. Cluster içine kurduğumuz bir operator (ArgoCD veya Flux) Git repomuzu sürekli izler (polling veya webhook ile). Repoda yeni bir commit gördüğünde aradaki farkı algılar ve cluster’ı Git’teki durumla eşitlemek için “pull” eder. Dışarıya hiçbir credential sızmaz, cluster kendi kendini yönetir.

ArgoCD ve Flux: Mimari ve felsefe farkları

İki araç da CNCF (Cloud Native Computing Foundation) bünyesinde mezun (graduated) projelerdir ve production ortamlarında rüştünü ispatlamıştır. Felsefeleri ise oldukça farklıdır.

1. ArgoCD: Görsel güç ve merkezi yönetim

ArgoCD, web arayüzü (UI) ve merkezi yönetim kabiliyetleriyle öne çıkar. Organizasyonunuzda çok sayıda developer varsa ve onların Kubernetes kaynaklarını görsel olarak izlemesini, loglara erişmesini, senkronizasyon durumunu canlı grafiklerle görmesini istiyorsanız ArgoCD tam size göredir.

• CRD yapısı: Temel olarak Application ve AppProject Custom Resource Definition (CRD) yapılarını kullanır.
• SSO entegrasyonu: Dex aracılığıyla Keycloak, Okta, GitHub gibi kimlik sağlayıcılarla iyi entegre olur. Multi-tenancy desteği güçlüdür.
• Yönetim tarzı: Web UI üzerinden manuel tetikleme (Sync) yapılmasına izin verir (opsiyonel olarak kapatılabilir).

2. Flux (Flux v2): Kubernetes native ve minimalist

Flux, Kubernetes felsefesine sıkı sıkıya bağlıdır. Bir web arayüzü barındırmaz (üçüncü parti CLI veya UI araçları hariç). Tamamen “Git-first” ve “declarative” çalışır, işi Kubernetes’in kendi controller mimarisine bırakır.

• Modüler mimari: Flux, GitOps Toolkit denen bağımsız controller’lardan oluşur (Source Controller, Kustomize Controller, Helm Controller, Notification Controller).
• Çoklu cluster (multi-cluster) kolaylığı: Git repolarını hiyerarşik olarak tarayıp düzinelerce cluster’ı tek bir Flux instance’ıyla yönetmek oldukça esnektir.
• CLI gücü: fluxctl (artık sadece flux) CLI’ı, terminal bağımlısı mühendislerin rüyalarını süsleyecek seviyededir.

Hızlı karşılaştırma tablosu

Multi-Tenancy

Özellik	ArgoCD	Flux v2
Kullanıcı Arayüzü (UI)	Var (Çok güçlü ve detaylı)	Yok (CLI odaklı / Üçüncü parti eklentiler var)
Mimari	Monolitik Operator / API Server	Mikroservis / Modüler Controller’lar
Helm Desteği	Var (Client-side render eder)	Var (Dedicated Helm Controller kullanır)
Yerleşik (AppProject nesneleri ile)	Kubernetes RBAC ve Namespace izolasyonu ile

GitOps’ta Helm yönetimi

GitOps yaparken Kubernetes manifestlerini çiğ YAML olarak tutmak yerine genellikle Helm chart paketlerini kullanırız. ArgoCD de Flux da Helm ile entegre çalışır, ama işleyişleri farklıdır.

ArgoCD ile Helm dağıtımı

ArgoCD, Helm chart’ı Git’ten veya harici bir Helm repo’sundan okur. Arka planda helm template komutunu çalıştırarak saf manifestleri üretir ve bunları cluster’a uygular. Yani cluster’da helm list çalıştırdığınızda bu release’i göremezsiniz, her şey standart Kubernetes kaynakları olarak görünür.

ArgoCD için örnek bir declarative Application manifesti:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kertenkerem-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://charts.bitnami.com/bitnami'
    chart: nginx
    targetRevision: 15.0.0
    helm:
      valueFiles:
        - values.yaml
      parameters:
        - name: service.type
          value: ClusterIP
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Buradaki selfHeal: true parametresi önemlidir. Biri cluster’da kubectl edit ile Nginx deployment’ının replika sayısını değiştirirse ArgoCD bunu anında yakalar ve saniyeler içinde Git’teki duruma (örneğin 3 replikaya) geri döndürür.

Flux ile Helm dağıtımı

Flux ise işi Kubernetes native controller’larla çözer. Önce kaynağı (HelmRepository) tanımlarız, ardından bu kaynaktan beslenen bir HelmRelease oluştururuz. Flux, Kubernetes içinde gerçek Helm release’leri oluşturur.

İlk adım: Helm repository tanımlama

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 1h
  url: https://charts.bitnami.com/bitnami

İkinci adım: HelmRelease kaynağı

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: kertenkerem-api
  namespace: production
spec:
  interval: 15m
  chart:
    spec:
      chart: nginx
      version: '15.x'
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
      interval: 1h
  install:
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3
  values:
    service:
      type: ClusterIP

Rollback stratejileri: İşler sarpa sarınca ne yapıyoruz?

Canlıya yeni bir sürüm çıktık ve loglar bir anda kırmızıya boyandı. Geleneksel yöntemde panikle helm rollback yazarız. GitOps’ta ise bu bir antipattern’dir, çünkü cluster üzerinde elle yapacağınız her rollback Git reposundaki durumla çelişir. GitOps operator’ınız canlı durumu tekrar Git’tekine eşitlemek için (self-heal açıksa) uygulamanızı yeniden hatalı sürüme yükseltecektir. Kısır döngüye hoş geldiniz.

Doğru rollback stratejileri şunlar:

1. “Git revert” stratejisi (The Pure GitOps Way)

En temiz, en denetlenebilir rollback yöntemi Git geçmişini geriye almaktır.
Hatalı deployment’a sebep olan commit belirlenir ve lokalde şu komut çalıştırılır:

git revert <commit-hash>
git push origin main

GitOps operator’ı değişikliği algılar ve yeni “eski” versiyonu cluster’a uygular. Böylece audit log’larımızda kimin, ne zaman, neden rollback yaptığının kaydı kalır.

2. Otomatik Helm rollback (Automated Remediation)

Uygulama ayağa kalkamadığında (CrashLoopBackOff) Git commit’ini bekleyecek vaktimiz olmayabilir. Flux ve ArgoCD bu durumlar için “Auto-Rollback” mekanizmaları sunar.

Flux’ta rollback yapılandırması:
Yukarıdaki Flux HelmRelease manifestindeki remediation bloğu tam olarak bu işe yarar. Helm upgrade başarısız olursa (örneğin readiness probe’lar geçemezse) Flux otomatik olarak bir önceki çalışan Helm release sürümüne geri döner (rollback).

ArgoCD’de rollback yapılandırması:
ArgoCD’de senkronizasyon başarısız olursa otomatik rollback doğrudan ArgoCD Application seviyesinde yönetilebilir. Ancak Git’teki kod hâlâ hatalı sürümü işaret ediyorsa ve ArgoCD “Auto-Sync” modundaysa sürekli bir loop oluşabilir. Bu yüzden ArgoCD’de genellikle Progressive Delivery araçları (Argo Rollouts) ile birlikte Canary veya Blue/Green deployment stratejileri tercih edilir.

Hangisini seçmelisiniz?

Yol ayrımındaysanız şu basit kurallara bakabilirsiniz:

• Şu durumlarda ArgoCD seçin: Yazılım geliştirme ekipleriniz cluster durumunu izlemek için terminale mahkum kalmak istemiyorsa, SSO entegreli şık bir dashboard şartsa ve uygulama gruplarını mantıksal projeler halinde (multi-tenancy) izole etmek istiyorsanız.
• Şu durumlarda Flux seçin: Kubernetes felsefesine sıkı sıkıya bağlı kalmak istiyorsanız, kaynak tüketimi (resource footprint) sizin için kritikse, cluster içinde ekstra bir web server/UI çalıştırmak istemiyor ve tamamen Git entegrasyonuna güveniyorsanız.

İki araç da sizi manuel müdahalelerin getirdiği güvensizlikten kurtarır ve altyapınızı gerçekten kod olarak yönetmenizi sağlar. Cluster’ınız kararlı, pipeline’larınız yeşil kalsın!