Adres:Batıkent Mh. 8910 Sk. 6. Etap 1H No: 18 Yeni Toki Eyyübiye / Şanlıurfa (Yeni Alım Satım Karşısı)
Telefon:0 (545) 528 88 93
eMail: info@alestaweb.com

info@alestaweb.com
0 (545) 528 88 93

18.02.2026 01:52 Haber

ArgoCD ile GitOps: 2026'da Kubernetes Deployment'ı Nasıl Yapılır? | Alesta Web

ArgoCD GitOps Kubernetes DevOps Continuous Delivery

ArgoCD ile GitOps: 2026'da Kubernetes Deployment'ı Nasıl Yapılır?

18 Şubat 2026 Alesta Web Teknik Ekibi ~12 dakika okuma

Modern yazılım dünyasında bir şeyin çok net hale geldiğini görüyoruz: elle yapılan deployment'lar artık kabul görmüyor. Her environment için farklı komutlar çalıştırmak, "acaba staging ile prod aynı mı?" diye terlemek, gece yarısı rollback paniklerine girmek — bunlar artık DevOps ekiplerinin kabul etmediği senaryolar. 2026 itibarıyla bu sorunların çözümü GitOps ve onun en popüler aracı olan ArgoCD üzerinden konuşuluyor.

Alesta Web olarak müşteri projelerinde ArgoCD'yi aktif olarak kullanıyoruz ve bu rehberde sıfırdan production-ready bir GitOps pipeline'ı nasıl kurarsınız, ApplicationSet ile multi-cluster yönetimi nasıl yaparsınız, sık yapılan hataları nasıl önlersiniz — bunların hepsini ele alacağız.

Bu rehberde ne öğreneceksiniz? ArgoCD kurulumu, GitOps temel prensipleri, App of Apps pattern, ApplicationSet ile çoklu ortam yönetimi, Helm/Kustomize entegrasyonu, secrets yönetimi, sync wave stratejileri ve production best practices.

GitOps Nedir ve Neden Önemlidir?

GitOps, 2017'de Weaveworks tarafından tanımlanmış bir operasyon modelidir. Özü şu: Git reponuz, cluster'ınızın tek gerçek kaynağıdır (single source of truth). İstediğiniz her şey YAML ya da JSON olarak Git'e yazılır; bir araç sürekli olarak cluster'ın bu tanımla uyumlu kalmasını sağlar. Bu araç ArgoCD'dir.

Geleneksel CI/CD'de Jenkins ya da GitHub Actions, cluster'a doğrudan kubectl apply komutu gönderir. Push-based denen bu modelde pipeline, cluster'a erişim yetkisine sahip olmak zorundadır. GitOps'ta ise tam tersi: cluster, repo'yu kendisi izler ve değişiklikleri kendisi çeker (pull-based). Bu fark küçük gibi görünse de güvenlik açısından devrimseldir.

Özellik	Geleneksel CI/CD	GitOps (ArgoCD)
Deployment tetikleyicisi	Pipeline push eder	Cluster pull eder
Cluster erişimi	CI sisteminde kubeconfig	Sadece ArgoCD'de
Drift tespiti	Manuel ya da yok	Otomatik, sürekli
Rollback	Pipeline yeniden tetiklenir	Git revert = anında rollback
Audit log	CI sisteminde dağınık	Git history = tam kayıt
Multi-cluster	Karmaşık, elle yönetim	ApplicationSet ile otomatik

ArgoCD Nedir? Neden Bu Kadar Popüler?

ArgoCD, CNCF (Cloud Native Computing Foundation) bünyesinde graduated statüsünde bir proje. GitHub'da 18.000'i aşkın yıldıza sahip ve 2026 itibarıyla en sık kullanılan GitOps aracı konumunda. Rakibi FluxCD'nin tersine, ArgoCD güçlü bir web arayüzüyle geliyor — bu da özellikle ekip içi iletişim ve görselleştirme açısından büyük avantaj sağlıyor.

Alesta Web'in müşteri projelerinde ArgoCD'yi tercih etmesinin birkaç temel sebebi var: Canlı sync durumu takibi, Helm ve Kustomize desteğinin ootb (out of the box) gelmesi, SSO entegrasyonu, RBAC granülerliği ve özellikle ApplicationSet ile onlarca uygulamayı tek template'ten yönetebilmek.

2026 İstatistiği: CNCF anketine göre kuruluşların %84'ü Kubernetes kullanıyor ya da değerlendiriyor. Bu kuruluşların giderek artan bölümü ArgoCD'yi standart CD aracı olarak benimsemiş durumda.

ArgoCD Kurulumu (Production-Ready)

Hızlı bir test için standalone kurulum yeterlidir, ama production için HA (High Availability) kurulum şarttır. Aşağıda her iki senaryo da gösterilmiştir.

1. Namespace ve Temel Kurulum

# ArgoCD namespace oluştur kubectl create namespace argocd # Standalone kurulum (dev/test için) kubectl apply -n argocd -f \ https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml # HA kurulum (production için - önerilen) kubectl apply -n argocd -f \ https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/ha/install.yaml # Kurulumu doğrula kubectl get pods -n argocd kubectl get svc -n argocd

2. ArgoCD CLI Kurulumu

# Linux/macOS curl -sSL -o argocd-linux-amd64 \ https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64 sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd rm argocd-linux-amd64 # Versiyon kontrolü argocd version

3. İlk Giriş ve Şifre Değiştirme

# Başlangıç şifresini al argocd admin initial-password -n argocd # Port-forward ile UI'a eriş (geçici) kubectl port-forward svc/argocd-server -n argocd 8080:443 # CLI ile giriş yap argocd login localhost:8080 # Şifreyi hemen değiştir! argocd account update-password

Güvenlik Uyarısı: Production'da ArgoCD UI'ı doğrudan internete açmayın. Bir Ingress + TLS sertifikası ya da VPN arkasında tutun. SSO (Dex, Okta, GitHub OAuth) entegrasyonunu mutlaka yapılandırın.

İlk Uygulamanızı Deploy Etmek

ArgoCD'de bir uygulamayı tanımlamak için Application adında bir Kubernetes custom resource kullanırsınız. Bu resource, "hangi Git repo'sundaki hangi path'i, hangi cluster'daki hangi namespace'e deploy et" sorusunu yanıtlar.

# app.yaml - Application manifest apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-app namespace: argocd labels: app.kubernetes.io/name: my-app team: backend spec: project: default source: repoURL: https://github.com/myorg/my-app-config targetRevision: main path: kubernetes/overlays/production destination: server: https://kubernetes.default.svc namespace: production syncPolicy: automated: prune: true # Git'ten silinen kaynakları cluster'dan da sil selfHeal: true # Manuel değişiklikleri otomatik geri al syncOptions: - CreateNamespace=true - PrunePropagationPolicy=foreground retry: limit: 5 backoff: duration: 5s factor: 2 maxDuration: 3m

# Uygulamayı uygula kubectl apply -f app.yaml # Durumu kontrol et argocd app get my-app argocd app sync my-app # Manuel sync tetikle argocd app wait my-app # Sync tamamlanana kadar bekle

App of Apps Pattern: GitOps'u Ölçeklendirmek

Birden fazla uygulamanız olduğunda her biri için ayrı ayrı Application manifest'i oluşturmak yerine "App of Apps" pattern kullanılır. Bu yaklaşımda bir "root" Application, diğer tüm Application'ları yönetir. Böylece ArgoCD'nin kendi konfigürasyonu da Git'te saklanmış olur.

Alesta Web projelerinde bu pattern'i standart olarak kullanıyoruz: bir apps/ dizini altında her servis için ayrı bir Application yaml, bir de bunları yöneten root Application. Yeni bir servis eklemek istediğinizde tek yapmanız gereken apps/ dizinine yeni bir yaml eklemek ve commit atmak.

# repo yapısı gitops-repo/ ├── apps/ │ ├── root-app.yaml # Root Application (bunu elle kur) │ ├── frontend.yaml # Frontend Application │ ├── backend-api.yaml # Backend API Application │ ├── worker.yaml # Worker Application │ └── monitoring.yaml # Monitoring stack Application ├── kubernetes/ │ ├── frontend/ │ ├── backend-api/ │ ├── worker/ │ └── monitoring/ └── helm-charts/

# root-app.yaml - Tüm apps/ klasörünü izler apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: root namespace: argocd spec: project: default source: repoURL: https://github.com/myorg/gitops-repo targetRevision: HEAD path: apps destination: server: https://kubernetes.default.svc namespace: argocd syncPolicy: automated: prune: true selfHeal: true

ApplicationSet ile Multi-Cluster ve Multi-Environment Yönetimi

ApplicationSet, ArgoCD'nin en güçlü özelliklerinden biridir. Tek bir template tanımından dinamik olarak onlarca Application üretebilirsiniz. 2026'da birden fazla ortam (dev, staging, prod) ya da birden fazla cluster yöneten ekiplerin olmazsa olmazı haline geldi.

Alesta Web'de müşteri projelerinde genellikle üç environment bulunur. ApplicationSet sayesinde bu üç ortamı tek bir YAML dosyasıyla yönetiyoruz. Yeni bir environment eklemek istediğinizde sadece generators listesine bir satır eklemeniz yeterli.

# applicationset-envs.yaml - List Generator örneği apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: my-app-environments namespace: argocd spec: generators: - list: elements: - env: dev cluster: dev-cluster values_file: values-dev.yaml - env: staging cluster: staging-cluster values_file: values-staging.yaml - env: production cluster: prod-cluster values_file: values-prod.yaml template: metadata: name: 'my-app-{{env}}' labels: env: '{{env}}' spec: project: '{{env}}' source: repoURL: https://github.com/myorg/my-app-config targetRevision: main path: helm/my-app helm: valueFiles: - '{{values_file}}' destination: server: '{{cluster}}' namespace: my-app syncPolicy: automated: prune: true selfHeal: '{{env}} == production ? false : true'

İpucu: Production ortamında selfHeal: false ve automated.prune: false ayarlarını değerlendirin. Manual onay gerektiren bir PR workflow'u ile production'a güvenli deployment yapabilirsiniz.

Helm ve Kustomize Entegrasyonu

ArgoCD, Helm chart'larını ve Kustomize overlay'lerini doğrudan destekler. Çoğu ekibin ayrı bir Helm templating adımı çalıştırmasına gerek yoktur — ArgoCD sync sırasında bunu otomatik olarak halleder.

Helm ile Uygulama Tanımı

spec: source: repoURL: https://github.com/myorg/my-app-config targetRevision: main path: helm/my-app helm: releaseName: my-app valueFiles: - values.yaml - values-production.yaml values: | image: tag: "1.5.2" replicaCount: 3 resources: requests: memory: "256Mi" cpu: "100m"

Kustomize ile Uygulama Tanımı

spec: source: repoURL: https://github.com/myorg/my-app-config targetRevision: main path: kubernetes/overlays/production # Kustomize overlay kustomize: namePrefix: prod- commonLabels: env: production

Sync Waves ile Sıralı Deployment

Birden fazla kaynağın belirli bir sırayla uygulanması gerektiğinde — örneğin önce namespace ve configmap, sonra deployment, en son ingress — sync wave annotation'ı kullanılır. Bu özellik özellikle veritabanı migration'larını API deployment'ından önce çalıştırmanız gerektiğinde hayat kurtarır.

Alesta Web'in bir müşteri projesinde migration job'ları, API pod'larından önce çalışması gerekiyordu. Sync wave bunu YAML düzeyinde garanti altına aldı, başka bir CI/CD mantığına gerek kalmadı.

# Wave -1: Önce infrastructure kaynakları apiVersion: v1 kind: ConfigMap metadata: name: app-config annotations: argocd.argoproj.io/sync-wave: "-1" --- # Wave 0: Migration job (default) apiVersion: batch/v1 kind: Job metadata: name: db-migration annotations: argocd.argoproj.io/sync-wave: "0" --- # Wave 1: Ana uygulama (migration bittikten sonra) apiVersion: apps/v1 kind: Deployment metadata: name: api annotations: argocd.argoproj.io/sync-wave: "1" --- # Wave 2: En son ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: api-ingress annotations: argocd.argoproj.io/sync-wave: "2"

Secrets Yönetimi: En Kritik Konu

GitOps'ta en sık sorulan soru şudur: "Secret'larımı Git'e koyamam, ama her şeyin Git'te olması gerekiyor — ne yapayım?" 2026'da bu sorunun iki yaygın cevabı var: Sealed Secrets ve External Secrets Operator.

Sealed Secrets Yaklaşımı

Bitnami'nin Sealed Secrets aracı, secret'larınızı cluster'a özgü bir public key ile şifrelemenizi sağlar. Şifreli versiyonu (SealedSecret) Git'e commitleyebilirsiniz — cluster dışında kimse çözemez.

# Sealed Secrets controller'ı kur helm repo add sealed-secrets \ https://bitnami-labs.github.io/sealed-secrets helm install sealed-secrets -n kube-system \ --set-string fullnameOverride=sealed-secrets-controller \ sealed-secrets/sealed-secrets # kubeseal CLI ile secret şifrele kubectl create secret generic my-secret \ --from-literal=DB_PASSWORD=supersecret \ --dry-run=client -o yaml | \ kubeseal --format yaml > my-sealed-secret.yaml # Şifreli dosyayı artık Git'e ekleyebilirsin git add my-sealed-secret.yaml git commit -m "Add sealed database credentials"

External Secrets Operator Yaklaşımı

# External Secrets Operator - AWS Secrets Manager örneği apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: db-credentials spec: refreshInterval: 1h secretStoreRef: kind: ClusterSecretStore name: aws-secrets-manager target: name: db-credentials creationPolicy: Owner data: - secretKey: DB_PASSWORD remoteRef: key: production/myapp/db property: password

Öneri: HashiCorp Vault entegrasyonu için ESO (External Secrets Operator) mükemmel çalışıyor. Vault zaten altyapınızda varsa ESO'yu tercih edin; yoksa Sealed Secrets daha az karmaşıklık getirir.

ArgoCD RBAC ile Takım Yönetimi

Büyük organizasyonlarda farklı takımların farklı uygulamalara erişimi olması gerekir. ArgoCD'nin Projects ve RBAC sistemi bunu zarif biçimde çözer.

# argocd-rbac-cm.yaml - RBAC konfigürasyonu apiVersion: v1 kind: ConfigMap metadata: name: argocd-rbac-cm namespace: argocd data: policy.default: role:readonly policy.csv: | # Backend takımı kendi uygulamalarını yönetebilir p, role:backend-team, applications, sync, backend-project/*, allow p, role:backend-team, applications, get, backend-project/*, allow p, role:backend-team, applications, update, backend-project/*, allow # Frontend takımı sadece kendi projelerini görebilir p, role:frontend-team, applications, get, frontend-project/*, allow p, role:frontend-team, applications, sync, frontend-project/*, allow # Platform ekibi tam yetkili g, platform-team, role:admin # GitHub grup atamaları g, myorg:backend, role:backend-team g, myorg:frontend, role:frontend-team g, myorg:platform, role:admin

Monitoring ve Alerting: Prometheus + Grafana Entegrasyonu

ArgoCD, Prometheus metriklerini varsayılan olarak /metrics endpoint'inden expose eder. Bunları scrape eden bir Prometheus stack ve Grafana ile ArgoCD'nin tüm sync durumlarını, uygulama sağlığını ve hata oranlarını izleyebilirsiniz.

Alesta Web olarak müşterilere önerdiğimiz alerting kuralları şunlar: sync başarısız olduğunda, uygulama "Degraded" durumuna geçtiğinde veya 30 dakikadan uzun süredir "Progressing" durumundaysa otomatik alarm gönder. Bu üç kural, deployment sorunlarının %90'ını erkenden yakalar.

# PrometheusRule - ArgoCD alertleri apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: argocd-alerts namespace: monitoring spec: groups: - name: argocd rules: - alert: ArgoCDAppNotSynced expr: argocd_app_info{sync_status!="Synced"} == 1 for: 10m labels: severity: warning annotations: summary: "ArgoCD app {{ $labels.name }} is not synced" - alert: ArgoCDAppUnhealthy expr: argocd_app_info{health_status!="Healthy"} == 1 for: 5m labels: severity: critical annotations: summary: "ArgoCD app {{ $labels.name }} is unhealthy"

ArgoCD vs FluxCD: 2026'da Hangisini Seçmeli?

Bu soruyu Alesta Web'e en sık soran müşterilerimiz oluyor. Kısa cevap: çoğu ekip için ArgoCD daha iyi bir başlangıç noktası. Uzun cevap ise bağlama göre değişir.

ArgoCD'yi tercih edin: Ekibinizde Kubernetes konusunda farklı yetkinlik seviyeleri varsa, görsel bir dashboard ekip koordinasyonunu kolaylaştıracaksa, hızlı onboarding önemliyse. FluxCD'yi tercih edin: Saf Kubernetes-native yaklaşım istiyorsanız, her şeyin CRD olmasını tercih ediyorsanız, UI gereksiz görünüyorsa ve GitOps purism arıyorsanız.

Kriter	ArgoCD	FluxCD
Web UI	Kapsamlı, güçlü	Yok (üçüncü parti)
GitHub Stars	~18.000+	~6.500+
Öğrenme eğrisi	Orta	Dik
Multi-cluster	ApplicationSet ile güçlü	Native Flux controller
Helm desteği	Native	Native (HelmRelease CRD)
CNCF statüsü	Graduated	Graduated

Production Best Practices: Alesta Web Checklist

Alesta Web ekibi olarak production'a geçmeden önce mutlaka kontrol ettiğimiz maddeleri paylaşıyoruz. Bu listeyi alestaweb.com üzerinden de paylaştığımız proje şablonlarına ekliyoruz.

1 HA Kurulum: ArgoCD'yi en az 2 replica ile çalıştırın. Single point of failure kabul edilemez.

2 SSO Entegrasyonu: Dex, GitHub OAuth ya da Okta ile SSO zorunlu. Başlangıç şifresi kullanımı production'da yasaklı.

3 RBAC: En az yetki prensibi (least privilege). Her takım sadece kendi Project'ine erişebilmeli.

4 Secrets Yönetimi: Düz secret'ları Git'e kesinlikle eklemeyin. Sealed Secrets ya da ESO kullanın.

5 Production selfHeal: Production'da selfHeal dikkatli değerlendirin. Bazı durumlarda manuel onay daha güvenlidir.

6 Image policy: latest tag kullanmayın. Her zaman spesifik bir image tag (veya digest) kullanın.

7 Notification: ArgoCD Notifications ile Slack/Teams/PagerDuty entegrasyonu yapın.

8 Backup: ArgoCD konfigürasyonunu (Application CR'ları dahil) Git'te tutun ve velero ile yedekleyin.

Gerçek Dünya Örneği: Alesta Web Müşteri Vakası

Bir e-ticaret müşterimizin altyapısını ArgoCD ile yönetmeye başlamadan önce şu sorunlar vardı: Deployment'lar el ile yapılıyor, hangi version'ın nerede çalıştığı bilinmiyordu, staging ve prod ortamları arasında konfigürasyon farklılıkları oluşuyordu, ve rollback ortalama 45 dakika alıyordu.

Alesta Web'in ArgoCD kurulumundan 3 ay sonra: Deployment süresi 45 dakikadan 3 dakikaya düştü, rollback artık bir Git revert ve 90 saniyelik sync işlemi, tüm ortamlar aynı Helm chart'tan türetiliyor, prod ile staging arası konfigürasyon sapması sıfır, ve takım deployment yapmaktan korkmaktan çıkıp özgürce feature ship edebilir hale geldi.

Sonuç: GitOps sadece bir araç değil, bir kültür değişimi. Altyapınızı kod gibi yönetmek, denetlenebilir, tekrarlanabilir ve güvenilir deployment'ların temelidir.

Sık Yapılan Hatalar ve Çözümleri

Hata 1 — latest tag kullanımı: image: myapp:latest kullandığınızda ArgoCD sync değişikliği fark edemez. Her deployment için benzersiz bir tag kullanın (git SHA, semver).

Hata 2 — Secret'ları plain text commit etmek: Bu büyük bir güvenlik açığıdır. Kubeseal ya da ESO kullanmadan secret kesinlikle Git'e gitmemeli.

Hata 3 — Tek repo'ya her şeyi koymak: App kodu ve GitOps config'i ayrı repolar olmalı. App repo'su build tetikler, config repo'su deploy tetikler. Bu ayrım audit ve güvenlik için kritiktir.

Hata 4 — RBAC ihmal etmek: Herkesin admin yetkisi olduğu ArgoCD kurulumları güvenlik felaketidir. En az bir admin ve read-only roller tanımlayın, takımlara proje bazlı erişim verin.

Sonuç: GitOps 2026'da Artık Opsiyonel Değil

2026 itibarıyla ArgoCD ve GitOps metodolojisi, Kubernetes üzerinde çalışan ekipler için fiili standart haline gelmiş durumda. CNCF verilerine göre Kubernetes kullanan kuruluşların giderek artan bir oranı GitOps prensiplerini benimsemiş. Bu eğilim önümüzdeki yıllarda da ivme kazanarak devam edecek.

Alesta Web olarak müşterilerimize şunu söylüyoruz: ArgoCD'yi kurmak bir günlük iş, ama getirdiği güven, hız ve denetlenebilirlik kümülatif olarak kariyerinizdeki en iyi yatırımlardan biri olacak. Declarative deployment, drift detection, tek tuşla rollback — bunlar artık lüks değil, temel gereksinim.

Eğer ArgoCD kurulumu, GitOps pipeline tasarımı ya da multi-cluster yönetimi konusunda yardıma ihtiyacınız varsa Alesta Web ekibi her zaman burada. alestaweb.com üzerinden bizimle iletişime geçin.

Kaynaklar: