Flux CD ile Kubernetes GitOps: Kapsamlı Kurulum ve Yapılandırma Rehberi

Kubernetes ortamlarında uygulama dağıtımı ve konfigürasyon yönetimi gün geçtikçe karmaşıklaşıyor. Ekiplerin birden fazla cluster, environment ve uygulama ile uğraştığı durumlarda manuel deployment süreçleri hata yapma riskini artırıyor ve operasyonel overheadı yükseltiyor. Bu noktada GitOps metodolojisi, altyapı ve uygulama yönetiminde devrim niteliğinde bir yaklaşım sunuyor. GitOps'un temel prensibi, sistemin istenen durumunu Git repositorylerinde declaratif olarak tanımlamak ve bu durumu otomatik olarak cluster'a senkronize etmektir. Flux CD, bu prensibi hayata geçiren en güçlü açık kaynak araçlarından biridir ve CNCF graduated projesi olarak endüstri standardı haline gelmiştir.

Bu makalede Flux CD'nin mimarisinden kurulumuna, temel konseptlerinden ileri düzey kullanım senaryolarına kadar kapsamlı bir inceleme yapacağız. Özellikle çoklu tenant destekleyen clusterlarda güvenli kullanım, Helm entegrasyonu ve Kustomize ile birlikte kullanımı detaylı örneklerle ele alacağız.

Flux CD Nedir ve Neden Kullanılmalıdır

Flux CD, Kubernetes clusterlarını Git repositorylerinden ve diğer kaynaklardan gelen declarative konfigürasyonlarla senkronize eden bir set Kubernetes controller'ından oluşur. Geleneksel CI/CD pipeline'larının aksine, Flux sürekli olarak cluster'ın mevcut durumunu Git'de tanımlanan istenen durumla karşılaştırır ve farklılıkları otomatik olarak düzeltir. Bu yaklaşım, "single source of truth" prensibini uygulayarak altyapı kodunun her zaman güncel ve izlenebilir olmasını sağlar.

Flux'un temel avantajları arasında tamamen Git-merkezili çalışması, built-in UI olmaması (bu da saldırı yüzeyini azaltır), küçük footprint (yaklaşık 150 MB RAM), multi-cluster yönetim desteği ve güçlü multi-tenancy özellikleri yer alır. ArgoCD ile karşılaştırıldığında, Flux daha minimal bir yaklaşım benimser ve CLI-first bir deneyim sunar. Ancak her iki araç da aynı problemi çözer ve seçim ekip tercihlerine bağlıdır.

Flux Bileşenleri ve Mimarisi

Flux CD, dört ana controller'dan oluşur ve her biri belirli bir sorumluluk alanına sahiptir. Source Controller, Git repositoryler, Helm repositoryleri, OCI artifactları ve S3 bucketları gibi kaynaklardan içerik çeker. Kustomize Controller, bu kaynaklardan gelen manifestleri işler ve Kustomize overlay'leri uygulayarak cluster'a deploy eder. Helm Controller, Helm chart release'lerini yönetir ve chart güncellemelerini takip eder. Notification Controller ise Flux olaylarını Slack, Microsoft Teams, Discord gibi harici sistemlere bildirir.

Bu controller'lar Kubernetes custom resource definitions (CRD) üzerinden yönetilir. Kullanıcılar YAML manifestleri oluşturarak Flux'a ne deploy edeceğini, hangi aralıklarla kontrol edeceğini ve hangi koşullarda bildirim göndereceğini belirtir. Tüm bu konfigürasyonlar Git'te version-controlled olarak tutulur ve her değişiklik audit trail bırakır.

Flux CLI Kurulumu ve Bootstrap Süreci

Flux'u bir Kubernetes cluster'ına kurmak için öncelikle flux CLI'ın yerel makineye kurulması gerekir. Linux sistemlerde aşağıdaki komutla kurulum yapılabilir:

curl -s https://fluxcd.io/install.sh | sudo bash

Kurulum tamamlandıktan sonra flux versiyonunu kontrol edin:

flux --version

Flux'un cluster'da çalışabilmesi için belirli ön koşulların sağlanması gerekir. Kubernetes 1.20 veya üzeri bir cluster, kubectl konfigürasyonu ve cluster-admin yetkileri yeterlidir. Ön koşulları kontrol etmek için:

flux check --pre

GitHub ile Bootstrap

Flux bootstrap komutu, tüm Flux bileşenlerini cluster'a kurar ve bir Git repository'si ile bağlar. Bu tek komut, source-controller, kustomize-controller, helm-controller ve notification-controller'ları oluşturur, gerekli CRD'leri yükler ve repository'den cluster'a senkronizasyonu başlatır. Bootstrap için bir GitHub personal access token gerekir ve bu token repo yetkisine sahip olmalıdır.

Aşağıdaki örnek, GitHub kullanarak Flux'u bootstrap etme sürecini gösterir:

export GITHUB_TOKEN=<your-token>
export GITHUB_USER=<your-username>
export GITHUB_REPO=<your-repo-name>

flux bootstrap github   --owner=$GITHUB_USER   --repository=$GITHUB_REPO   --branch=main   --path=./clusters/production   --personal

Bu komut çalıştırıldığında Flux, belirtilen GitHub repository'sinde clusters/production dizinini oluşturur ve Flux bileşen manifestlerini bu dizine commit eder. Ardından bu manifestleri cluster'a uygular ve repository'yi izlemeye başlar. Artık cluster'ın durumu tamamen Git tarafından kontrol ediliyor demektir.

Flux Temel Kaynakları

Flux ile çalışırken anlaşılması gereken birkaç temel custom resource vardır. GitRepository, bir Git repository'sinin Flux tarafından izlenmesini sağlar. HelmRepository, Helm chart repositorylerini tanımlar. Kustomize, Kubernetes manifestlerinin Kustomize ile işlenmesini yönetir. HelmRelease ise Helm chart deploymantlarını declaratif olarak tanımlar.

GitRepository Oluşturma

Bir GitRepository kaynağı, Flux'un hangi repository'yi hangi branch veya tag'i izleyeceğini belirtir:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: applications
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/myorg/applications
  ref:
    branch: main
  secretRef:
    name: github-credentials

Bu örnekte, applications repository'sinin main branch'i her dakika kontrol edilir. Credentials kullanılarak private repository'lere de erişilebilir. interval alanı, Flux'un kaynağı ne sıklıkla kontrol edeceğini belirler ve GitOps döngüsünün hızını belirler.

HelmRepository Tanımlama

Helm chart'ları için bir HelmRepository oluşturmak, Flux'a chart kaynaklarını bildirir:

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 1h
  url: https://charts.bitnami.com/bitnami
  type: "public"

Bitnami repository'si public olduğu için secret gerekmez. Private Helm repository'ler için credentials secret olarak tanımlanmalı ve secretRef ile referans verilmelidir. interval değeri, repository'nin indeksini ne sıklıkla yenileyeceğini belirler.

Kustomization ve HelmRelease Kullanımı

Flux'un gücü, Kustomize ve Helm entegrasyonlarında yatar. Bu iki araç kombinasyonu, farklı environment'lar için farklı konfigürasyonlar tanımlamayı ve tek bir base manifest setinden production, staging, development ortamları oluşturmayı mümkün kılar.

Kustomization ile Uygulama Deploy Etme

Bir Kustomization kaynağı, GitRepository'den gelen manifestlerin nasıl uygulanacağını belirtir:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 10m
  path: "./apps/myapp"
  prune: true
  sourceRef:
    kind: GitRepository
    name: applications
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: myapp
      namespace: myapp
  timeout: 5m

Bu konfigürasyonda, myapp uygulaması her 10 dakikada bir kontrol edilir. path alanı, GitRepository'deki hangi dizinin uygulanacağını belirtir. prune: true parametresi, artık Git'de bulunmayan kaynakların cluster'dan silinmesini sağlar. healthChecks ise deployment'ın sağlıklı kabul edilmesi için gerekli koşulları tanımlar.

HelmRelease ile Chart Deploy Etme

HelmRelease, Helm chart'larını Flux ile declaratif olarak deploy etmeyi sağlar:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis
  namespace: cache
spec:
  interval: 30m
  chart:
    spec:
      chart: redis
      version: "18.x"
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
  targetNamespace: cache
  values:
    architecture: standalone
    auth:
      enabled: true

Bu örnek, Bitnami repository'sinden Redis chart'ını version 18.x ile deploy eder. values alanı, chart'a özgü değerleri belirtir ve traditional Helm values dosyaları ile aynı formatı kullanır. interval, chart güncellemelerinin ne sıklıkla kontrol edileceğini belirler.

Multi-Tenancy ve Güvenlik

Flux CD, paylaşılan Kubernetes clusterlarında birden fazla tenant'ın güvenli bir şekilde çalışmasını destekler. Multi-tenancy yapılandırması, tenant'ların birbirlerinin kaynaklarına erişmesini engellemek ve her tenant'ın yalnızca kendi namespace'lerinde çalışmasını sağlamak için Kubernetes RBAC ve namespace izolasyonunu kullanır.

Multi-Tenancy Lockdown

Flux'u multi-tenant bir cluster'da güvenli şekilde çalıştırmak için bootstrap sırasında özel argumentler kullanılmalıdır:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - gotk-components.yaml
  - gotk-sync.yaml
patches:
  - patch: |
    - op: add
      path: /spec/template/spec/containers/0/args/-
      value: --no-cross-namespace-refs=true
    target:
      kind: Deployment
      name: "(kustomize-controller|helm-controller|notification-controller|image-reflector-controller|image-automation-controller)"
  - patch: |
    - op: add
      path: /spec/template/spec/containers/0/args/-
      value: --no-remote-bases=true
    target:
      kind: Deployment
      name: "kustomize-controller"
  - patch: |
    - op: add
      path: /spec/template/spec/containers/0/args/-
      value: --default-service-account=default
    target:
      kind: Deployment
      name: "(kustomize-controller|helm-controller)"

Bu konfigürasyon, Flux controller'larını çeşitli güvenlik kısıtlamalarıyla çalıştırır. --no-cross-namespace-refs, Flux custom resource'larına cross-namespace erişimini engeller, böylece bir tenant diğer tenant'ın kaynaklarına erişemez. --no-remote-bases, Kustomize remote base'lerini devre dışı bırakarak yalnızca Flux Sources'un cluster durumunu etkilemesini sağlar. --default-service-account ise service account belirtilmeyen Kustomization ve HelmRelease'lerin default service account kullanmasını engeller.

Service Account Impersonation

Flux'un en güçlü güvenlik özelliklerinden biri service account impersonation'dır. Her Kustomization veya HelmRelease, spec.serviceAccountName alanında bir service account belirterek, Flux controller'larının o service account'un yetkileriyle kaynak oluşturmasını sağlar:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: team-alpha
  namespace: team-alpha
spec:
  serviceAccountName: team-alpha-deploy
  interval: 5m
  path: "./apps"
  prune: true
  sourceRef:
    kind: GitRepository
    name: team-alpha-repo

Bu örnekte, team-alpha-deploy service account, Kustomization'ın oluşturduğu tüm kaynaklar için kullanılır. Platform admin, bu service account'a yalnızca team-alpha namespace'inde yetki vererek, tenant'ın cluster'ın geri kalanını etkilemesini engeller.

Flux ile CI/CD Pipeline Entegrasyonu

Flux CD, mevcut CI/CD pipeline'larını tamamlayıcı bir rol üstlenir. Geleneksel CI/CD sistemleri (GitLab CI, GitHub Actions, Jenkins) kod derleme, test çalıştırma ve container image oluşturma işlemlerini yaparken, Flux CD deployment ve konfigürasyon senkronizasyonunu üstlenir. Bu ayrım, sorumlulukların net şekilde ayrılmasını ve "separation of concerns" prensibinin uygulanmasını sağlar.

Image Update Automation

Flux, container image güncellemelerini otomatik olarak takip edebilir ve Git'te manifest güncellemeleri yapabilir. Bu özellik, ImageRepository ve ImagePolicy kaynakları kullanılarak etkinleştirilir:

apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
  name: myapp
  namespace: flux-system
spec:
  image: registry.myorg.com/myapp
  interval: 1m
---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
  name: myapp
  namespace: flux-system
spec:
  imageRef: myapp
  policy:
    semver:
      range: ">=1.0.0 2.0.0"
---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 1m
  sourceRef:
    kind: GitRepository
    name: applications
  git:
    branch: main
  commit:
    author:
      email: flux@myorg.com
      name: flux
  update:
    path: "./apps/myapp"

Bu konfigürasyon, myapp image'ının yeni versiyonlarını takip eder ve semver politikasına göre uygun güncellemeleri yapar. ImageUpdateAutomation, her yeni image push edildiğinde apps/myapp dizinindeki manifestleri güncelleyecek ve commit edecektir. Bu sayede image güncellemeleri tamamen otomatik hale gelir.

En İyi Uygulamalar ve İpuçları

Flux CD kullanırken production ortamlarında güvenlik ve güvenilirlik için bazı en iyi uygulamaları takip etmek önemlidir. İlk olarak, tüm Flux konfigürasyonlarını Git'te tutun ve bu repository'leri ayrı ayrı yönetin. Platform yöneticileri için bir "infrastructure" repository, tenant'lar için ayrı repository'ler kullanılması önerilir. İkinci olarak, multi-tenancy lockdown'ı paylaşılan clusterlarda mutlaka etkinleştirin. Üçüncü olarak, health check'leri tanımlayarak deployment'ların sağlıklı olduğundan emin olun.

Notification konfigürasyonu, operasyonel görünürlük için kritiktir. Slack, Microsoft Teams veya webhook tabanlı sistemler için bildirimler kurarak, Flux'un başarısız veya başarılı senkronizasyonları hakkında bilgi alın. Ayrıca, Flux loglarını düzenli olarak gözden geçirin ve olası sorunları erken tespit edin. Son olarak, Flux versiyonlarını düzenli olarak güncelleyin ve güncellemeleri önce staging ortamında test edin.

Sonuç

Flux CD, Kubernetes GitOps implementasyonu için güçlü ve esnek bir çözümdür. Tamamen Git-merkezili yaklaşımı, küçük footprint'i, güçlü multi-tenancy desteği ve güvenlik özellikleri onu enterprise ortamları için ideal kılar. Özellikle ArgoCD'nin sunduğu web UI'ya ihtiyaç duymayan, CLI-odaklı ekipler için Flux, daha minimalist ve güvenli bir alternatif sunar.

Bu makalede ele aldığımız konular, Flux CD'ye başlamak ve production'da güvenli şekilde kullanmak için gerekli temel bilgileri kapsar. Controller'ların mimarisi, bootstrap süreci, temel kaynaklar (GitRepository, HelmRepository, Kustomization, HelmRelease), multi-tenancy konfigürasyonu ve en iyi uygulamalar, Flux ile etkili GitOps pipeline'ları oluşturmak için bilmeniz gereken temel konulardır. Flux CD'yi kullanarak Kubernetes deployment süreçlerinizi otomatikleştirebilir, güvenliği artırabilir ve operasyonel overhead'ı azaltabilirsiniz.