ArgoCD ve GitOps 2026: Kubernetes Continuous Deployment ve Mülakat Soruları

Kubernetes ekosisteminde continuous deployment süreçlerini yönetmek, organizasyonların ölçeklendikçe karşılaştığı en kritik mühendislik problemlerinden biri olmaya devam ediyor. 2026 yılında GitOps yaklaşımı artık bir tercih olmaktan çıkıp fiili standart haline gelirken, ArgoCD bu alandaki en yaygın benimsenen araçlardan biri konumunu sürdürüyor. Declarative konfigürasyonlar, otomatik senkronizasyon ve drift detection gibi yetenekleriyle ArgoCD, Kubernetes üzerindeki deployment süreçlerini hem güvenilir hem de denetlenebilir kılmayı hedefliyor. Bu makale, ArgoCD'nin GitOps prensiplerini nasıl uyguladığını, ileri düzey özelliklerini, rakibi Flux ile karşılaştırmasını ve mülakatlarda sıkça karşılaşılan soruları kapsamlı bir şekilde ele almaktadır.

ArgoCD ile GitOps Uygulaması

ArgoCD, GitOps döngüsü içinde bir reconciliation controller olarak çalışır. Git reposundaki desired state ile cluster üzerindeki actual state arasındaki farkı sürekli izler ve tanımlanan politikalara göre otomatik veya manuel senkronizasyon gerçekleştirir. Bu mekanizmanın temelinde Application custom resource'u yer alır.

Aşağıdaki YAML dosyası, bir ArgoCD Application tanımının temel yapısını göstermektedir:

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/my-web-app-config
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true        # Remove resources deleted from Git
      selfHeal: true     # Revert manual changes in the cluster
    syncOptions:
      - CreateNamespace=true

Bu tanımda dikkat edilmesi gereken birkaç kritik alan bulunmaktadır. syncPolicy.automated bloğu altındaki prune: true ayarı, Git reposundan silinen kaynakların cluster'dan da otomatik olarak kaldırılmasını sağlar. selfHeal: true ise cluster üzerinde manuel olarak yapılan değişikliklerin Git'teki tanımla yeniden uyumlu hale getirilmesini garantiler. Bu iki özellik bir arada, cluster state'inin her zaman Git ile tutarlı kalmasını sağlayan temel GitOps prensibini hayata geçirir.

ArgoCD, kaynak repo olarak hem plain YAML manifests hem Kustomize overlays hem de Helm chart'larını destekler. Yukarıdaki örnekte overlays/production path'i kullanılarak Kustomize tabanlı bir yaklaşım benimsenmiştir; bu yaklaşım, farklı ortamlar için aynı base konfigürasyonun üzerine ortama özgü patch'ler uygulanmasına olanak tanır.

Sync Waves ve Hooks ile Sıralı Deployment

Gerçek dünyadaki deployment senaryoları nadiren tek bir adımdan oluşur. Veritabanı migration'larının uygulama deployment'ından önce çalıştırılması, konfigürasyonların servisten önce oluşturulması veya smoke test'lerin deployment sonrasında tetiklenmesi gibi gereksinimler sıklıkla karşımıza çıkar. ArgoCD, bu tür sıralı operasyonları Sync Waves ve Hooks mekanizmalarıyla yönetir.

Sync Waves, kaynaklara numerik bir öncelik atayarak deployment sırasını belirler. Düşük değerli wave'ler önce çalıştırılır; bir wave'deki tüm kaynaklar healthy duruma geçmeden sonraki wave başlamaz. Hooks ise sync yaşam döngüsü içindeki belirli aşamalarda (PreSync, Sync, PostSync, SyncFail) çalıştırılan tek seferlik işlerdir.

# migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # Runs before wave 0
    argocd.argoproj.io/hook: PreSync      # Executes before main sync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: acme/my-web-app:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never

Bu örnekte db-migrate Job'u, wave değeri -1 ve PreSync hook tipi sayesinde ana uygulama kaynaklarından önce çalıştırılır. hook-delete-policy: HookSucceeded ise başarıyla tamamlanan Job'un otomatik olarak temizlenmesini sağlar. Bu yaklaşım, veritabanı şemasının her zaman uygulama kodundan önce güncellenmesini garantileyerek deployment sırasında oluşabilecek uyumsuzlukların önüne geçer.

Sıralı deployment stratejisi oluşturulurken dikkat edilmesi gereken en önemli nokta, her wave içindeki kaynakların birbirinden bağımsız olarak deploy edilebilir olmasıdır. Wave'ler arası bağımlılıklar açıkça tanımlanmalı ve health check mekanizmaları doğru yapılandırılmalıdır.

Multi-Cluster Yönetimi: ApplicationSets

Birden fazla cluster'a aynı uygulamayı deploy etmek, özellikle farklı bölgeler veya ortamlar için ayrı cluster'lar kullanan organizasyonlarda yaygın bir gerekliliktir. ArgoCD'nin ApplicationSet controller'ı, tek bir tanım üzerinden birden fazla Application oluşturulmasını mümkün kılar.

# applicationset-clusters.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-web-app-all-clusters
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-web-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/acme/my-web-app-config
        targetRevision: main
        path: 'overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

ApplicationSet, clusters generator'ü aracılığıyla env: production etiketine sahip tüm cluster'ları otomatik olarak keşfeder ve her biri için ayrı bir Application oluşturur. Template içindeki {{name}}, {{server}} ve {{metadata.labels.region}} gibi değişkenler, her cluster'ın kendi özelliklerine göre dinamik olarak doldurulur. Bu yaklaşım sayesinde yeni bir production cluster eklendiğinde, uygun etiketler atandığı anda ilgili uygulama otomatik olarak deploy edilmeye başlar.

Generator türleri cluster'larla sınırlı değildir. Git generator ile repo içindeki dizin yapısına göre, list generator ile statik bir liste üzerinden, merge generator ile birden fazla generator'ün kesişimi üzerinden Application'lar oluşturulabilir.

ArgoCD ve Flux Karşılaştırması

GitOps alanındaki iki büyük araç olan ArgoCD ve Flux, farklı mimari tercihleri ve kullanım senaryoları için optimize edilmiştir. Aşağıdaki tablo, 2026 itibarıyla güncel versiyonlarının temel özelliklerini karşılaştırmaktadır:

| Feature | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Architecture | Centralized server with UI | Distributed controllers per cluster | | Web UI | Built-in, polished dashboard | No built-in UI (third-party options) | | Helm support | Renders templates server-side | Native Helm SDK integration | | Multi-cluster | Hub-and-spoke from single instance | Independent installation per cluster | | RBAC | Application-level with SSO | Kubernetes-native RBAC only | | Image automation | Separate Image Updater component | Built-in image reflector/automation | | Progressive delivery | Argo Rollouts integration | Flagger integration | | Resource footprint | Higher (API server, repo server, Redis) | Lower (only needed controllers) |

Seçim kriteri genellikle organizasyonun ihtiyaçlarına bağlıdır. Merkezi yönetim, zengin UI ve güçlü RBAC gereksinimleri olan takımlar ArgoCD'ye yönelirken, hafif kurulum ve dağıtık yönetim tercih eden takımlar Flux'u daha uygun bulabilir. Pratikte, büyük ölçekli organizasyonların bir kısmının her iki aracı da farklı kullanım senaryolarında birlikte kullandığı görülmektedir.

Production için Repository Yapısı

GitOps'un etkinliği, büyük ölçüde repo yapısının ne kadar iyi organize edildiği ile doğrudan ilişkilidir. Kustomize tabanlı bir yaklaşımda, base dizini ortamlar arası paylaşılan kaynak tanımlarını içerirken, overlays dizini her ortam için özel patch'leri barındırır.

# Recommended repository structure
my-web-app-config/
  base/
    deployment.yaml
    service.yaml
    kustomization.yaml
  overlays/
    staging/
      kustomization.yaml       # Patches for staging
      replica-count.yaml
    production/
      kustomization.yaml       # Patches for production
      replica-count.yaml
      hpa.yaml

Bu yapıda base/ dizini, uygulamanın temel Deployment ve Service tanımlarını içerir. overlays/staging/ ve overlays/production/ dizinleri ise Kustomize patch mekanizması aracılığıyla ortama özgü ayarlamaları (replica sayısı, HPA konfigürasyonu, resource limits vb.) uygular. Bu ayrım, kod tekrarını en aza indirirken ortamlar arası farklılıkların açıkça görülür olmasını sağlar.

Production repo yapısında dikkat edilmesi gereken ek noktalar arasında secrets yönetimi (Sealed Secrets veya External Secrets Operator kullanımı), config ve application repolarının birbirinden ayrılması ve branch stratejisinin belirlenmesi yer alır. Config reposunda genellikle main branch'i production'ı, environment-spesifik branch'ler ise ilgili ortamları temsil eder.

ArgoCD 3.4 ile Gelen Yenilikler

ArgoCD 3.4 sürümü, operasyonel esnekliği artıran birkaç önemli özellik sunmaktadır. Bunlardan ilki, belirli cluster'lar için reconciliation'ın geçici olarak duraklatılabilmesidir.

# Pause reconciliation on a specific cluster
apiVersion: v1
kind: Secret
metadata:
  name: prod-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/pause-reconciliation: "true"
stringData:
  server: https://prod-cluster.example.com
  config: |
    { "tlsClientConfig": { "insecure": false } }

Bu özellik, planlanan bakım pencereleri, cluster upgrade'leri veya incident response sırasında ArgoCD'nin cluster üzerinde değişiklik yapmasını engellemek için kullanılır. Annotation "true" olarak ayarlandığında, ilgili cluster'daki tüm Application'lar için senkronizasyon durdurulur; bakım tamamlandığında annotation kaldırılarak normal operasyona dönülür.

İkinci önemli yenilik ise Helm value dosyaları için glob pattern desteğidir:

# Before ArgoCD 3.4
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production.yaml
      - values-production-eu.yaml
      - values-production-eu-secrets.yaml

# With ArgoCD 3.4 value globs
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production*.yaml

Önceki versiyonlarda her value dosyasının tek tek listelenmesi gerekiyordu; bu durum özellikle çok sayıda ortam ve bölge kombinasyonu olan deployment'larda konfigürasyonun karmaşa haline gelmesine neden oluyordu. Glob pattern desteği ile values-production*.yaml gibi bir ifade, values-production.yaml, values-production-eu.yaml ve values-production-eu-secrets.yaml dosyalarının tamamını otomatik olarak kapsar. Bu özellik, büyük ölçekli Helm deployment'larında konfigürasyonun okunabilirliğini önemli ölçüde artırmaktadır.

Mülakat Soruları ve Yanıtları

ArgoCD desired state ile live state arasındaki farkı nasıl tespit eder?

ArgoCD, Git reposundaki manifest'leri render ettikten sonra Kubernetes API aracılığıyla cluster'daki mevcut kaynakların durumunu sorgular. Her iki state'in normalized JSON temsillerini karşılaştırır ve farklılık tespit ettiğinde uygulamayı "OutOfSync" olarak işaretler. Bu karşılaştırma sırasında ArgoCD, Kubernetes tarafından otomatik olarak eklenen alanlar (son applied konfigürasyonlar, managed fields vb.) gibi beklenen farklılıkları filtreler. resource.customizations konfigürasyonu ile hangi alanların karşılaştırmada göz ardı edileceği özelleştirilir.

selfHeal ve prune arasındaki fark nedir ve hangi durumlarda dikkatli olunmalıdır?

selfHeal, cluster üzerinde Git'te tanımlanmayan manuel değişiklikler yapıldığında (örneğin bir Deployment'ın replica sayısının kubectl ile değiştirilmesi) bu değişiklikleri geri alır. prune ise Git reposundan silinen kaynakların cluster'dan da kaldırılmasını sağlar. Her iki özellik de dikkatli yapılandırılmalıdır: selfHeal etkinken HPA (Horizontal Pod Autoscaler) gibi dinamik olarak replica sayısını değiştiren mekanizmalarla çatışma yaşanabilir; bu durumda ilgili alanların karşılaştırma dışında bırakılması gerekir. prune ise yanlış bir commit ile kritik kaynakların silinmesine yol açabileceğinden, production ortamlarında sync window'lar ile birlikte kullanılması tavsiye edilir.

ApplicationSet ile Application arasındaki temel fark nedir?

Application, tek bir uygulama için tek bir hedefe (cluster ve namespace) deployment tanımlar. ApplicationSet ise bir template ve bir veya birden fazla generator aracılığıyla birden fazla Application oluşturur. Generator'lar cluster listesi, Git repo dizin yapısı, statik liste veya pull request gibi kaynaklardan dinamik olarak Application tanımları üretir. Temel avantajı, N adet benzer Application tanımını tek bir ApplicationSet ile yönetebilmektir; bu da özellikle multi-cluster ve multi-tenant senaryolarda operasyonel yükün önemli ölçüde azalmasını sağlar.

Sync Waves başarısız olursa ne olur?

Bir wave içindeki herhangi bir kaynak healthy duruma geçemediği veya bir hook başarısız olduğunda, ArgoCD sync işlemini durdurur ve sonraki wave'leri başlatmaz. Bu davranış, deployment pipeline'ının güvenliğini sağlar; örneğin bir migration Job'u başarısız olursa uygulama kodu deploy edilmez. Başarısız sync işlemi, ArgoCD dashboard'unda ve ilgili notification kanallarında raporlanır. Manuel müdahale veya sorunun Git üzerinden düzeltilmesiyle yeni bir sync tetiklenir.

ArgoCD'de secret yönetimi nasıl yapılır?

GitOps'un temel prensibi olan "her şeyin Git'te olması" ilkesi, hassas veriler söz konusu olduğunda doğrudan uygulanamaz. ArgoCD ekosisteminde secret yönetimi için birkaç yaygın yaklaşım mevcuttur: Bitnami Sealed Secrets ile secret'ların şifrelenerek Git'e commit edilmesi, External Secrets Operator ile secret'ların AWS Secrets Manager, HashiCorp Vault veya GCP Secret Manager gibi harici kaynaklardan çekilmesi, ve SOPS (Secrets OPerationS) ile YAML dosyalarının içeriklerinin şifrelenerek repoda saklanması. Hangi yöntemin seçileceği, organizasyonun mevcut secret yönetim altyapısına ve compliance gereksinimlerine bağlıdır.

ArgoCD performansını ölçeklendirmek için hangi stratejiler uygulanabilir?

Büyük ölçekli deployment'larda ArgoCD performansını optimize etmek için birkaç strateji uygulanır. Repo server'ın cache mekanizması doğru yapılandırılmalı, özellikle büyük Helm chart'ları için manifest generation cache süresi artırılmalıdır. ApplicationSet kullanarak Application tanımlarının sayısı azaltılabilir. Sharding ile farklı cluster'ların farklı ArgoCD controller instance'larına dağıtılması sağlanabilir. Ayrıca, resource tracking için label yerine annotation tracking tercih edilerek label collision riskleri minimize edilir.

Sonuç

ArgoCD ve GitOps ekosistemi, 2026 yılında Kubernetes deployment süreçlerinin yönetiminde olgunlaşma dönemini yaşarken, bu alanda derinlemesine bilgi sahibi olmak hem operasyonel mükemmellik hem de kariyer gelişimi açısından büyük önem taşımaktadır. Bu makalede ele alınan konuları özetlemek gerekirse:

• GitOps paradigması, Git reposunu tek doğru kaynak olarak kabul ederek declarative, denetlenebilir ve tekrarlanabilir deployment süreçlerini mümkün kılar.
• ArgoCD Application tanımı, source (Git repo) ve destination (cluster) arasındaki senkronizasyonu otomatikleştiren temel yapıdır; selfHeal ve prune politikaları ile drift önlenir.
• Sync Waves ve Hooks, karmaşık deployment senaryolarında işlemlerin doğru sırada gerçekleştirilmesini garantiler.
• ApplicationSets, multi-cluster ve multi-tenant ortamlarda tek bir tanım üzerinden dinamik Application yönetimini sağlar.
• ArgoCD 3.4, pause reconciliation ve Helm value globs gibi özelliklerle operasyonel esnekliği artırmıştır.
• ArgoCD ve Flux farklı mimari felsefelere sahiptir; seçim, organizasyonun merkezi yönetim, UI ve RBAC ihtiyaçlarına göre şekillenmelidir.
• Mülakat hazırlığı için hem temel kavramların hem de production ortamındaki pratik senaryoların iyi anlaşılması gerekmektedir.