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

Modern yazılım geliştirme süreçlerinde “lokalde çalışıyordu, production’da neden patladı?” sendromunu aşmanın en asil yolu altyapımızı da uygulama kodlarımız gibi sürüm kontrol sistemlerinde tutmaktan geçiyor. İşte bu noktada, Infrastructure as Code (IaC) felsefesinin uygulama dağıtım süreçleriyle evlenmesinden doğan GitOps yaklaşımı devreye giriyor. Günümüzde Kubernetes cluster’larını yönetmenin fiili standardı haline gelen GitOps modelinde, Git repomuz sistemimizin “Single Source of Truth” (Tek Doğruluk Kaynağı) haline geliyor. Peki, bu ekosistemin iki dev oyuncusu olan ArgoCD ve Flux arasından hangisini seçmeliyiz? Bu makalede, iki aracı derinlemesine karşılaştıracak, Helm chart deployment pratiklerine bakacak ve işler ters gittiğinde can simidimiz olacak rollback stratejilerini inceleyeceğiz.

Push-Based vs. Pull-Based: Neden GitOps?

Geleneksel CI/CD pipeline süreçlerinde genellikle “Push-Based” (İtme Odaklı) bir yaklaşım benimseriz. Jenkins, GitLab CI veya GitHub Actions gibi bir araç, uygulamanın imajını build eder ve 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 değil mi? Ancak bu yaklaşımın iki büyük karanlık noktası vardır:

1. Güvenlik Açığı: CI/CD aracınıza cluster üzerinde yüksek yetkili (admin) erişim anahtarları (kubeconfig) vermeniz gerekir. Eğer CI sunucunuz hacklenirse, tüm cluster anahtarlarını teslim etmiş olursunuz.
2. State Drift (Durum Sapması): Cluster üzerinde birisi manuel olarak (örneğin gece yarısı hotfix’i ile) bir deployment’ı değiştirirse, Git repomuzdaki kod ile canlıdaki durum birbirinden sapar. CI aracının bir sonraki tetiklenmesine kadar bu durumdan haberimiz olmaz.

Pull-Based GitOps ise bu problemi tersine çevirir. Cluster içerisine 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 vs. 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ü fazlasıyla ispatlamıştır. Ancak felsefeleri oldukça farklıdır.

1. ArgoCD: Görsel Güç ve Merkezi Yönetim

ArgoCD, kullanıcı dostu web arayüzü (UI) ve merkezi yönetim kabiliyetleriyle öne çıkar. Eğer 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 harika entegre olur. Multi-tenancy desteği mükemmeldir.
• 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” bir yaklaşımla çalışır. Mikrofonu Kubernetes’in kendi controller mimarisine bırakır.

• Modüler Mimari: Flux, GitOps Toolkit adı verilen 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’ı ile 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 Dünyasında Helm Yönetimi

GitOps yaparken Kubernetes manifestlerini doğrudan çiğ YAML olarak tutmak yerine genellikle Helm chart paketlerini kullanırız. Hem ArgoCD hem de Flux, Helm entegrasyonuna sahiptir ancak 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 gerçek bir helm list komutu çalıştırdığınızda bu release’i göremezsiniz; her şey standart Kubernetes kaynakları olarak görünür.

İşte 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 kritik önem taşır. Eğer birisi cluster’da gidip 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’lar aracılığıyla çözer. İlk olarak kaynağı (HelmRepository) tanımlarız, ardından bu kaynaktan beslenen bir HelmRelease kaynağı oluştururuz. Flux, Kubernetes içerisinde 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 Sarpasarınca Ne Yapıyoruz?

Canlıya yeni bir sürüm çıktık ve loglar bir anda kırmızıya boyandı. Geleneksel dünyada panikle helm rollback yazarız. Ancak GitOps dünyasında bu bir antipattern’dir! Neden mi? Çünkü cluster üzerinde manuel yapacağınız her rollback, Git reposundaki durumla çelişecektir. GitOps operator’ınız canlı durumu tekrar Git’tekine eşitlemek için (eğer self-heal açıksa) uygulamanızı tekrar hatalı sürüme yükseltecektir. Kısır döngüye hoş geldiniz!

Peki doğru rollback stratejileri nelerdir?

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 koşturulur:

git revert <commit-hash>
git push origin main

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

2. Otomatik Helm Rollback (Automated Remediation)

Bazen uygulamanın ayağa kalkamaması (CrashLoopBackOff) durumunda Git commit’ini bekleyecek vaktimiz olmayabilir. Flux ve ArgoCD bu durumlar için “Auto-Rollback” mekanizmaları sunar.

Flux’ta Rollback Yapılandırması:
Yukarıda paylaştığımız Flux HelmRelease manifestindeki remediation bloğu tam olarak bu işe yarar. Eğer Helm upgrade işlemi 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 eğer senkronizasyon başarısız olursa, otomatik rollback doğrudan ArgoCD Application seviyesinde yönetilebilir. Ancak dikkat edin; eğer Git’teki kod hala 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 kuralları göz önünde bulundurabilirsiniz:

• Ş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.

Her iki araç da günün sonunda sizi manuel müdahalelerin getirdiği güvensiz hislerden kurtaracak ve altyapınızı gerçek anlamda kod olarak yönetmenizi sağlayacaktır. Cluster’ınız kararlı, pipeline’larınız yeşil kalsın!