1. GİRİŞ

GitOps, modern bulut‑native operasyonların bel kemiği hâline geldi. Declarative altyapı yönetimi ve Git'i "single source of truth" olarak kullanma yaklaşımı, altyapı değişikliklerinin izlenebilir, geri alınabilir ve otomatik olarak uygulanabilir olmasını sağlıyor. Ancak GitOps tek başına bir araç değil; doğru uygulanmadığında operasyonel karmaşıklığı artırabilir. Bu nedenle GitOps mimarilerinde kullanılan pattern'leri anlamak, kuruluşun ölçeğine ve gereksinimlerine göre uygun bir yapı seçmek kritik.

Bu konu neden bugün önemli?

• Kubernetes ve çoklu cluster kullanımının artması, manifest yönetimini merkezileştirme ihtiyacını doğurdu.
• Regülasyon, audit ve güvenlik gereksinimleri, altyapı değişikliklerinin Git üzerinden takip edilmesini zorunlu hale getiriyor.
• İş hızının artması, daha tutarlı, otomatik ve güvenli deploy süreçleri gerektiriyor.

Kimler için önemli?

• Platform mühendisleri, DevOps/SRE ekipleri
• Kubernetes ile çalışan ekipler ve mimarlar
• Güvenlik, compliance ve yönetişim ekipleri

Hangi problemleri çözüyor?

• Konfigürasyon drift'i ve manuel değişiklik sonucu oluşan tutarsızlıklar
• Yetersiz audit, rollback ve sürüm takibi
• Scale‑up/scale‑out süreçlerinde tekrar eden insan hataları

2. KAVRAMSAL TEMELLER

2.1 GitOps'un temel ilkeleri

1. Declarative state: Sistem istenen durum (desired state) olarak tanımlanır.
2. Git as single source of truth: Tüm konfigürasyon ve manifest'ler Git'te saklanır.
3. Pull model: Controller/agent Git'i çeker ve gerçek durumu reconcile eder.
4. PR tabanlı değişim: Değişiklikler PR/merge workflow'u ile yapılır, CI validasyonları çalışır.
5. Observability ve safeties: Değişikliklerin etkileri telemetry ile izlenir ve policy guardrail'lar uygulanır.

2.2 Ana bileşenler

• Git repos (app, env, infra, policies)
• Controller: ArgoCD, Flux veya custom operator
• CI: PR validation, lint, policy check, image scanning
• Secrets store: Vault, SealedSecrets, External Secrets
• Policy engines: OPA/Gatekeeper, Conftest

2.3 Terminoloji

• App of Apps: Bir üst manifest ile birden fazla uygulamayı yöneten pattern.
• Bootstrap: Yeni cluster veya kontrol düğümü kurulum süreci.
• Reconcile loop: Controller'ın periyodik veya event‑tabanlı Git kontrolü.

3. NASIL ÇALIŞIR? — Mimariden Pattern'lere

3.1 Mono‑repo vs Multi‑repo

Repo stratejisi GitOps'un kalbidir. İki temel yaklaşım vardır:

Mono‑repo

• Tüm uygulama manifest'leri, environment konfigürasyonları ve policy'ler tek bir repo'da tutulur.
• Avantajlar: Kolay global arama, tek yerden değişiklik, atomic commit'ler.
• Dezavantajlar: Repo büyüdükçe performans sorunları, erişim kontrolü granülerliği zorlaşır.

Multi‑repo

• Uygulama bazlı veya environment bazlı repo ayrımları vardır (app repo, infra repo, env repo).
• Avantajlar: Granüler erişim kontrolü, controller yükü dağıtılabilir, takım sınırları netleşir.
• Dezavantajlar: Cross‑repo değişiklik koordinasyonu zordur; global görünürlük azalır.

Seçim organizasyon ölçeği, takım yapısı ve governance gereksinimlerine bağlıdır. Genelde küçük/orta ölçek için mono‑repo, büyük ve çok takımlı organizasyonlar için multi‑repo tercih edilir.

3.2 App of Apps pattern

"App of Apps" pattern'i, üst seviye bir uygulamanın (root app) diğer uygulamaların manifest'lerini referans gösterdiği yapıdır. ArgoCD'de yaygın kullanılır.

• Avantaj: Merkezi bootstrap, multi‑cluster yönetimi, kolay uygulama kaydı.
• Kullanım: Platform takımı, onboarding prosesleri ve self‑service developer portal'lar için uygundur.

3.3 Multi‑cluster ve federation pattern'leri

Organizasyonlar sıklıkla birkaç cluster yönetir: prod, staging, dev veya bölgesel cluster'lar. Multi‑cluster pattern'leri şunları içerir:

• Single control plane: Tek controller, birden çok cluster'ı yönetir (ArgoCD application per cluster).
• Dedicated controllers: Her cluster için ayrı controller instance'ları; izolasyon ve ölçek avantajı sağlar.
• Federation / multi‑control plane: Birden çok control plane'in federasyonu ile global durum yönetimi.

Güvenlik ve ölçek açısından genelde dedicated controllers + app of apps kombinasyonu tercih edilir. Böylece controller'ların yetkileri sınırlandırılabilir ve bootstrapping süreci izlenebilir.

3.4 Policy as Code ve guardrail'lar

GitOps'un güvenli olması için policy as code entegrasyonu zorunludur. OPA/Gatekeeper veya Conftest gibi araçlarla aşağıdaki kontroller CI veya admission aşamasında uygulanır:

• Namespace, resource quota veya limit range politikaları
• Image registry allowlist ve image digest pin zorunluluğu
• Network policy ve security context kontrolü
• RBAC ve service account limitleri

3.5 Secrets yönetimi

GitOps ile secrets yönetimi kritik bir konudur. Temel pattern'ler şunlardır:

• External Secrets: Secrets referansı Git manifest'lerinde tutulur, gerçek secret runtime'da Vault, AWS Secrets Manager veya Key Vault tarafından çekilir.
• SealedSecrets: Şifrelenmiş secret'lar Git'te tutulur; cluster tarafındaki controller bunları açar.
• Vault + Agent: Pod başlatıldığında Vault agent secret'ı çekip mount eder veya sidecar sağlar.

Hangi pattern seçilirse seçilsin, secret'ların Git'te düz metin olarak tutulmaması temel kuraldır.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Canary ve Progressive Delivery ile GitOps

Canary ve progressive delivery ile GitOps'u birleştirerek manifest'lerde canary politikaları ve traffic splitting parametreleri tanımlanır. Controller, bu parametrelere göre servise yeni sürümü kademeli olarak uygular; metriğe göre promote veya rollback kararları alınır.

Uber — Büyük ölçekli multi‑cluster yönetimi

Uber benzeri organizasyonlar, App of Apps pattern'i ile cluster bootstrapping, region‑specific config ve RBAC yönetimini otomatikleştirir. Yeni cluster kurulumlarında GitOps bootstrap repo'ları kullanılır.

Amazon / Büyük kuruluşlar — Policy & Compliance

OPA/Gatekeeper benzeri policy mekanizmalarıyla manifest'lerin compliance kontrolleri PR aşamasında çalıştırılır. Ayrıca runtime admission controller'lar ile de politika enforcement yapılır.

OpenAI / MLOps — Model rollout'larda GitOps

MLOps senaryolarında model serving konfigürasyonları, canary inference ve model metadata Git reposunda tutulur; controller bu metadata'ya göre serving sistemini reconcile eder.

Stripe — Audit ve hızlı rollback

Finansal sistemlerde her değişiklik commit ve PR geçmişi ile izlenir; gerektiğinde hızlı revert ile eski konfigürasyon geri yüklenir. Ayrıca feature flag adoption ile müşteri cohort'ları bazında risk kontrolü sağlanır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Tekrar üretilebilirlik ve audit: Tüm değişiklikler Git'te kayıtlıdır.
• Geliştirici deneyimi: Git tabanlı workflow geliştiriciler için doğaldır.
• Güvenlik: Pull model ve least privilege politikaları uygulanabilir.
• Otomasyon ile ölçek: Yeni cluster veya uygulama onboarding otomatikleştirilebilir.

Sınırlamalar

• Başlangıç maliyeti ve öğrenme eğrisi: Repo düzeni, bootstrap ve policy konfigürasyonu zaman alır.
• Tooling bağımlılığı: ArgoCD/Flux sürüm, plugin veya entegrasyon sorunları operasyonu etkileyebilir.
• Secrets yönetimi karmaşıklığı: Yanlış pattern seçimi ciddi güvenlik riskleri doğurur.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Repository & Organizasyon

• Repo stratejisini dokümante edin ve takım ihtiyaçlarına göre belirleyin.
• Environment konfigürasyonlarını ayırın; secrets'ı Git dışına taşıyın.
• App of Apps pattern ile onboarding sürecini otomatikleştirin.

CI ve Validation

• PR pipeline'larında manifest lint, helm template/ kustomize build, policy checks ve image digest pin kontrolleri çalıştırın.
• SBOM, dependency scanning ve container image scanning ile supply chain güvenliğini sağlayın.

Security & Operations

• Controller rolünü least‑privilege ile sınırlandırın; RBAC ve network politikalarını net belirleyin.
• Admission controller ve runtime policy enforcement (OPA/Gatekeeper) kullanın.
• Reconcile metriklerini toplayın ve controller health monitoring kurun.

8. SIK YAPILAN HATALAR

• Secrets'ı Git'te tutmak veya yanlış şifreleme yöntemleri kullanmak.
• PR validation süreçlerini atlamak — manifest'lerin doğrudan merge edilmesi risklidir.
• Controller'a geniş yetkiler vermek; principle of least privilege'ı ihmal etmek.
• Repo büyüdüğünde controller scalability planı yapmamak.

9. GELECEK TRENDLER

1. Policy‑driven GitOps: Policy as code, compliance otomasyonu ve continuous compliance akışları daha entegre hale gelecek.
2. AI destekli manifest optimizasyonu: ML tabanlı öneriler, drift tespiti ve canary karar destek sistemleri gelişecek.
3. Federated GitOps: Çoklu kontrol düzlemi ve federated state yönetimi, edge ve IoT uygulamalarına yönelik gelişecek.
4. GitOps for Data & Models: MLOps ve veri platformları için GitOps pattern'leri standartlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Mono‑repo mu yoksa multi‑repo mu tercih etmeliyim?

   Organizasyonun ölçeği, takım yapısı ve erişim kontrol gereksinimlerine göre karar verin. Küçük ekipler için mono‑repo hızlı başlar; büyük, çok takımlı organizasyonlar için multi‑repo daha uygundur.

2. Secrets'ı Git'te tutabilir miyim?

   Genelde hayır. SealedSecrets veya external secrets pattern'leri ile Git'te yalnızca şifrelenmiş veya referans biçiminde tutmalısınız.

3. ArgoCD mi Flux mu?

   Her iki araç da güçlüdür. ArgoCD zengin UI ve app of apps yetenekleriyle; Flux lightweight ve Git‑centric felsefesiyle öne çıkar. Seçim ihtiyaçlarınıza bağlıdır.

4. GitOps performans sorunları nasıl çözülür?

   Repo partitioning, app of apps, controller horizontal scaling ve reconcile frekansını optimize ederek performans iyileştirilir.

5. Rollback nasıl yapılır?

   Git revert veya eski commit'e dönüş yapılarak; controller reconcile ile cluster eski duruma geri çekilir. Stateful rollback'ler için ek planlama gerekir.

6. GitOps'u kademeli nasıl devreye alırım?

   Küçük bir non‑critical servis veya staging environment ile başlayın; PR validation, policy integration ve secrets patternlerini test ederek kademeli genişleyin.

7. Policy as code nerede çalıştırılmalı?

   Hem CI pipeline'da (PR validation) hem de runtime admission (Gatekeeper) aşamasında çalıştırılmalıdır — çift katmanlı güvenlik sağlar.

8. GitOps ile nasıl ölçüm alırım?

   Reconcile latency, drift rate, controller error rate, deployment frequency ve mean time to recovery (MTTR) gibi metrikleri toplayın.

Anahtar Kavramlar

App of Apps

Üst seviye bir manifest ile alt uygulamaları yönetme deseni.

Reconcile

Controller'ın gerçek durumu istenen duruma getirme döngüsü.

Policy as Code

Uyumluluk ve güvenlik kurallarının kod olarak ifade edilmesi ve otomatik validasyonu.

SealedSecrets / External Secrets

Secrets yönetimi için kullanılan GitOps‑uyumlu pattern'ler.

Pull Model

Controller'ın Git'ten manifestleri çekip uyguladığı model; güvenlik avantajı sağlar.

Öğrenme Yol Haritası

1. 0–1 ay: Kubernetes, YAML manifest'ler, Helm ve Kustomize temel bilgisi.
2. 1–3 ay: ArgoCD veya Flux kurulumu, basit GitOps workflow'u ile küçük bir uygulamayı deploy edin.
3. 3–6 ay: Policy as code (OPA/Gatekeeper), SBOM, image scanning ve secrets pattern'lerini entegre edin.
4. 6–12 ay: Multi‑cluster GitOps, app of apps, canary automation ve controller scaling konularında deneyim kazanın.
5. 12+ ay: Federated GitOps, GitOps for edge, ve MLOps/GitOps birleşimi konularında uzmanlaşın.