ArgoCD

ArgoCD; Kubernetes için pull-based GitOps continuous delivery aracıdır. Argo projesi CNCF’te graduated statüdedir. Çekirdek prensip basittir: kümede çalışan bir controller, Git’teki manifest’leri sürekli izler ve fark gördüğünde kümeyi Git’teki istenen duruma yaklaştırır. Bu yaklaşım, uygulama dağıtımında tek değişim girişi olarak Git ilkesini güçlendirir; ancak cluster dışı veri, secret ve bağımlı servislerin yedeğini tek başına çözmez.

Görsel UI’ı, ArgoCD’yi Flux’tan ayıran en görünür özelliklerden biridir: kaynak ağacı, sync durumu, manifest diff ve rollout health bilgisi tek pencerede görülür. Kurumsal kullanımda asıl karar noktası ise UI değil; repo modeli, yetki sınırları, secret akışı, ortam onayları ve geri dönüş prosedürüdür.

Kurulum seçenekleri

• Resmi manifest: kubectl apply -n argocd -f install.yaml , hızlı başlangıç ve test kümesi için yeterli.
• Helm chart: Community tarafından bakımı yapılan argo-helm chart’ı; values ile HA, ingress ve SSO ayarları tek yerden yönetilir. Üretim kurulumlarında Mono’nun tercihi budur.
• HA kurulum: Üretimde argocd-repo-server ve argocd-application-controller replikaları artırılır; Redis HA modda çalıştırılır.

Tipik akış

1. Geliştirici app-repo‘da PR açar → CI image build/push → CI manifest repo’da image.tag günceller.
2. ArgoCD manifest repo’daki değişikliği algılar → “OutOfSync” durumuna geçer.
3. Staging’de otomatik sync açıksa uygular; production’da çoğu kurgu manuel onay bekler.
4. Sync sonrası health check; aşamalı dağıtım için Argo Rollouts ile canary deploy yazımıza bakın.
5. Hata olursa rollout stratejisine göre otomatik abort veya manuel durdurma; uygulama manifest’i için Git revert, veri katmanı için ayrıca migration/restore planı uygulanır.

Ne zaman doğru tercih değil?

• Kubernetes kullanmayan veya tek VM üzerinde çalışan küçük uygulamalar için ArgoCD gereksiz platform yükü yaratabilir.
• Git’te tutulmayan manuel üretim değişiklikleri normal kabul ediliyorsa GitOps disiplini önce organizasyonel olarak kurulmalıdır.
• Stateful uygulamalarda yalnızca manifest rollback’i yeterli görülüyorsa risk eksik değerlendirilmiştir; schema migration, volume snapshot ve dış servis bağımlılıkları ayrı plan ister.
• CI aracının cluster-admin yetkisiyle doğrudan deploy etmesi kısa vadede hızlı görünebilir; fakat audit, yetki ayrımı ve drift yönetimi ihtiyacı doğduğunda pull-based model daha güvenli olur.

Yaygın sorunlar ve çözümler

• “OutOfSync” sürekli görünüyor: Mutating webhook’lar (örn. service-mesh sidecar enjekte ediyor) tarafından eklenen field’ları ignoreDifferences ile filtreleyin.
• Webhook gecikmesi: ArgoCD Git’i belirli aralıklarla yoklar; bu aralık timeout.reconciliation ayarıyla belirlenir ve varsayılanı dakikalar mertebesindedir. Değişikliğin daha hızlı yansıması gerekiyorsa GitHub/GitLab webhook entegrasyonu kurulmalıdır.
• Sırlar: Git’e şifresiz secret koymayın. Sealed Secrets, External Secrets Operator veya SOPS ile şifreli akış.
• Yavaş büyük repo: Manifest repo’sunu domain’lere ayırın; her takım kendi alt-projesinde.
• Drift uyarısı: SRE ekibine Slack alert; otomatik geri alma istiyorsanız selfHeal: true açıkça etkinleştirilir, istemiyorsanız manuel onay akışı korunur.

Maliyet ve işletme kalemleri

ArgoCD için lisans bedeli yoktur; maliyet çoğunlukla işletme tarafındadır: HA kurulum, SSO/RBAC entegrasyonu, secret yönetimi, manifest repo standardı, uygulama ekiplerinin eğitimi, sürüm yükseltmeleri, yedek/restore tatbikatı ve incident runbook’ları. Alıcı açısından doğru soru “ArgoCD ücretsiz mi?” değil, “GitOps disiplinini kim tasarlayıp sürekli işletecek?” sorusudur.

Resmi kaynaklar

• Argo CD dokümantasyonu: https://argo-cd.readthedocs.io/
• Argo CD GitHub deposu: https://github.com/argoproj/argo-cd
• CNCF Argo proje sayfası: https://www.cncf.io/projects/argo/

Mono’nun yaklaşımı

GitOps sadece “araç kurmak” değil, organizasyonel disiplin gerektirir. Mono’nun ArgoCD kurulumlarında her zaman şu kararları netleştiririz:

• Tek repo mu çoklu repo mu? Genelde iki repo: uygulama kodu (CI ile container image build/push) + ortam manifest’leri (CD’nin tek kaynağı). Image promotion, manifest repo’da tag güncellemesi şeklinde olur.
• App-of-Apps: Her kümenin “root” Application’ı vardır; bu da diğer Application’ları yönetir. Yeni servis eklemek için tek dosya değiştirmek yeterli.
• ApplicationSet: Çoklu ortam (dev/staging/prod) ve çoklu küme senaryolarında uygulama tanımını tek şablona indirir. Ortak Helm chart’ı sabit kalır; her uygulama ve ortam kendi values dosyasıyla ayrışır.
• Sync politikaları: Üretim için manual sync + onay; staging için açıkça etkinleştirilmiş automated sync + self-heal. prune ve selfHeal varsayılan güvenli davranışlar değildir, uygulama bazında seçilir.
• RBAC: Geliştiriciler kendi namespace’lerine sync yetkisi; SRE/platform ekibi cluster-wide.
• Operasyon sorumluluğu: ArgoCD’nin kendi yedeği, sürüm yükseltmeleri, Redis/repo-server kapasitesi, Git provider erişimi, secret controller’ları ve acil rollback runbook’u baştan sahiplenilir.

Sıkça sorulan sorular