Kubernetes CI/CD ve GitOps Araçları: GitLab Agent, GitLab Runner ve Flux CD

Giriş: CI/CD ve GitOps Yaklaşımları

Modern yazılım geliştirme süreçlerinde, uygulamaların hızlı, güvenilir ve sürekli bir şekilde dağıtılması büyük önem taşır. Bu ihtiyacı karşılamak için **Sürekli Entegrasyon ve Sürekli Dağıtım (CI/CD)** ve **GitOps** gibi metodolojiler kullanılır.

**CI/CD (Sürekli Entegrasyon / Sürekli Dağıtım):** Geliştiricilerin kod değişikliklerini sık sık entegre etmelerini, otomatik testlerden geçirmelerini ve üretim ortamlarına otomatik olarak dağıtmalarını sağlayan bir otomasyon döngüsüdür. Genellikle bir "push" modelini izler; yani CI/CD aracı, kaynak kod deposundaki değişiklikleri algılayıp yeni derlemeyi bir hedef ortama (örneğin Kubernetes kümesi) "iter".
**GitOps:** Altyapıyı ve uygulamaları "kod olarak" yönetme prensibine dayanan bir operasyonel çerçevedir. Tüm sistemin istenen durumu Git deposunda bildirimsel olarak tanımlanır. Bir operatör (veya aracı), kümenin mevcut durumunu sürekli olarak Git deposundaki istenen durumla karşılaştırır ve herhangi bir fark algılandığında kümeyi otomatik olarak Git'teki duruma getirir. Bu, bir "pull" modelidir; yani küme içindeki aracı, Git deposundan değişiklikleri "çeker".

Bu belgede, bu yaklaşımları Kubernetes ortamında uygulamanıza yardımcı olacak üç önemli aracı inceleyeceğiz: GitLab Runner (geleneksel CI/CD için), GitLab Agent (GitLab'ın GitOps çözümü) ve Flux CD (genel bir GitOps araç seti).

CI/CD ve GitOps Temel Farkları

CI/CD (Push Tabanlı)

🐙

Git Deposu (Kod)

⟶ 🏃‍♂️

CI/CD İşlem Hattı (Runner)

⟶ ☸️

Kubernetes Kümesi

Değişiklikler CI/CD aracı tarafından kümeye itilir.

GitOps (Pull Tabanlı)

🐙

Git Deposu (İstenen Durum)

⟵ 🤖

Küme İçi Aracı (Agent)

🔄 ☸️

Kubernetes Kümesi

Küme içindeki aracı, Git deposundan değişiklikleri çeker.

1. GitLab Runner

**GitLab Runner**, GitLab CI/CD işlem hatlarını (pipelines) çalıştıran açık kaynaklı bir uygulama veya sunucudur. GitLab CI/CD, yazılım projelerinizi otomatikleştirmek için kullanılan bir sürekli entegrasyon hizmetidir. GitLab Runner, GitLab örneğinizle iletişim kurar, işlem hattı işlerini alır ve bunları kendi ortamında yürütür. Bu ortam, Docker konteynerleri, sanal makineler veya fiziksel sunucular olabilir.

Neden ve Ne İşe Yarar?

**İşlem Hattı Yürütme:** GitLab CI/CD işlem hatlarında tanımlanan tüm adımları (kod derleme, test etme, Docker imajı oluşturma, dağıtım komutlarını çalıştırma) yürütür.
**Ortam Esnekliği:** Linux, Windows, macOS gibi farklı işletim sistemlerinde ve Docker, Kubernetes, SSH gibi çeşitli yürütme ortamlarında çalışabilir. Bu, farklı proje gereksinimlerine uyum sağlamasını sağlar.
**Ölçeklenebilirlik:** İş yükünü dağıtmak için birden fazla Runner kaydedilebilir. Otomatik ölçeklenen (autoscale) Runner'lar, talebe göre dinamik olarak başlatılıp sonlandırılabilir.
**Geleneksel CI/CD:** GitLab Runner, push tabanlı CI/CD yaklaşımlarının temel bileşenidir. Kod değişikliği Git'e itildiğinde, Runner tetiklenir ve tanımlanan işleri çalıştırır.

Çalışma Şekli (Basitleştirilmiş):

Bir GitLab Runner, GitLab sunucusuna kayıt olur ve sürekli olarak yeni işleri bekler. Bir geliştirici koda bir değişiklik yaptığında ve bunu Git deposuna ittiğinde, GitLab CI/CD bu değişikliği algılar ve `.gitlab-ci.yml` dosyasında tanımlanan işlem hattını başlatır. İşlem hattındaki bir iş, kayıtlı bir Runner'a atanır. Runner, işin gerektirdiği ortamı (örneğin bir Docker konteyneri) başlatır, gerekli komutları çalıştırır ve sonuçları (loglar, başarı/başarısızlık durumu) GitLab sunucusuna geri gönderir.

GitLab Runner Akışı

🐙

GitLab Sunucusu

⟶ 🏃‍♂️

GitLab Runner

⟶ ☸️

Kubernetes Kümesi (Dağıtım)

GitLab Runner, GitLab'dan işleri çeker ve kümeye dağıtır.

Örnek `.gitlab-ci.yml` (Kubernetes'e Dağıtım):


# .gitlab-ci.yml
stages:
  - build
  - deploy

build_image:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t registry.gitlab.com/your-group/your-project/my-app:latest .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push registry.gitlab.com/your-group/your-project/my-app:latest
  tags:
    - docker-runner # Belirli bir Docker Runner'da çalıştır

deploy_to_kubernetes:
  stage: deploy
  image: bitnami/kubectl:latest # kubectl içeren bir imaj
  script:
    - kubectl config get-contexts
    - kubectl config use-context your-k8s-cluster # Kubernetes bağlamını seç
    - kubectl apply -f kubernetes/deployment.yaml # Kubernetes manifestini dağıt
  only:
    - main # Sadece 'main' branch'ine yapıldığında çalıştır
  tags:
    - k8s-deploy-runner # Kubernetes'e erişimi olan bir Runner'da çalıştır

2. GitLab Agent (for Kubernetes)

**GitLab Agent (for Kubernetes)**, GitLab'ın Kubernetes için GitOps ve daha güvenli CI/CD dağıtımları sağlamak amacıyla tasarladığı, küme içinde çalışan bir bileşendir. Geleneksel GitLab Runner modelinin aksine, GitLab Agent pull tabanlı (çekme tabanlı) bir yaklaşımla çalışır.

Neden ve Ne İşe Yarar?

**GitOps Yaklaşımı:** Kümenizin istenen durumunu Git deposunda tanımlarsınız. Agent, bu depoyu sürekli izler ve kümenin mevcut durumunu Git'tekiyle senkronize eder. Bu, altyapıyı kod olarak yönetmenizi ve değişikliklerin izlenebilirliğini artırmanızı sağlar.
**Güvenli Küme Bağlantısı:** GitLab CI/CD işlem hatlarından Kubernetes API'ye doğrudan erişim yerine, Agent küme içinde güvenli bir tünel (gRPC tabanlı) oluşturur. Bu, güvenlik açısından daha iyidir çünkü GitLab Runner'ların küme dışında hassas kimlik bilgilerine sahip olmasını gerektirmez.
**Çoklu Küme Yönetimi:** Bir GitLab örneğinden birden fazla Kubernetes kümesini yönetmek için her kümeye bir Agent dağıtabilirsiniz.
**Gelişmiş CI/CD Entegrasyonu:** GitLab CI/CD işlem hatları, Agent aracılığıyla kümeye güvenli bir şekilde dağıtım yapabilir, bu da Push ve Pull modellerini birleştirmenize olanak tanır (CI aşaması push, CD aşaması pull-via-agent).

Çalışma Şekli (Basitleştirilmiş):

GitLab Agent, hedef Kubernetes kümesine bir Pod olarak (genellikle bir Deployment veya DaemonSet) dağıtılır. Bu Agent, GitLab sunucusundaki bir "Agent Sunucusu" ile güvenli, çift yönlü bir gRPC tüneli kurar. GitOps için Agent, kümenin istenen durumunu tanımlayan Kubernetes manifestlerini içeren bir Git deposunu izler. Depoda bir değişiklik algılandığında, Agent bu değişiklikleri otomatik olarak kümeye uygular. CI/CD entegrasyonu için ise, GitLab CI/CD işlem hatları, bu tünel üzerinden güvenli bir şekilde `kubectl` komutlarını çalıştırabilir veya Kubernetes manifestlerini Agent aracılığıyla kümeye uygulayabilir.

GitLab Agent Akışı

🐙

Git Deposu (İstenen Durum)

⟵

🤖

GitLab Agent

🔄 ☸️

Kubernetes Kümesi

GitLab Agent, Git deposundaki istenen durumu kümeye çeker ve senkronize eder.

Örnek Yapılandırma (`.gitlab/agents//config.yaml`):


# .gitlab/agents/my-agent/config.yaml
gitops:
  manifest_projects:
  - id: your-group/your-project/infra-manifests # Kubernetes manifestlerinin bulunduğu repo
    paths:
      - /kubernetes-apps/**/*.yaml # Bu yoldaki tüm YAML dosyalarını senkronize et
ci_access:
  projects:
    - id: your-group/your-project/my-app # Bu projeden CI/CD erişimine izin ver

3. Flux CD

**Flux CD**, CNCF (Cloud Native Computing Foundation) tarafından desteklenen açık kaynaklı bir GitOps araç setidir. Kubernetes kümenizin durumunu otomatik olarak Git deposundaki istenen durumla senkronize etmek için tasarlanmıştır. Flux, tamamen çekme tabanlı (pull-based) bir GitOps modelini takip eder ve küme içinde çalışan denetleyiciler aracılığıyla çalışır.

Neden ve Ne İşe Yarar?

**Bildirimsel GitOps:** Kümenizin tüm istenen durumu (uygulamalar, yapılandırma, altyapı) Git deposunda tanımlanır. Flux, bu Git deposunu tek doğruluk kaynağı olarak kabul eder.
**Otomatik Senkronizasyon:** Git deposundaki değişiklikleri sürekli olarak izler ve kümenin mevcut durumunu Git'teki duruma göre otomatik olarak senkronize eder. Bu, manuel dağıtım hatalarını ortadan kaldırır.
**Kapsamlı GitOps Araç Seti:** Sadece Kubernetes manifestlerini değil, Helm chart'larını, Kustomize yapılandırmalarını ve diğer araçları da yönetebilir.
**Genişletilebilirlik ve Gözlemlenebilirlik:** Olayları, bildirimleri ve sağlık durumunu izlemek için zengin API'ler ve araçlar sunar.
**Satıcıdan Bağımsız:** Herhangi bir Git sağlayıcısına veya Kubernetes dağıtımına özel değildir, bu da yüksek taşınabilirlik sağlar.

Çalışma Şekli (Basitleştirilmiş):

Flux CD, Kubernetes kümesine bir dizi denetleyici Pod'u (örneğin Source Controller, Kustomize Controller, Helm Controller, Notification Controller) olarak dağıtılır. Bu denetleyiciler, belirtilen Git depolarını ve diğer kaynakları (örneğin Helm reposu) sürekli olarak izler. Git deposunda bir değişiklik (commit) olduğunda, Source Controller bunu algılar. Ardından, Kustomize Controller veya Helm Controller gibi ilgili denetleyici, bu değişiklikleri Kubernetes API aracılığıyla kümeye uygular. Eğer kümenin mevcut durumu Git'teki durumdan farklıysa, Flux bunu otomatik olarak Git'teki istenen duruma geri çeker (reconciliation).

Flux CD Akışı

🐙

Git Deposu (İstenen Durum)

⟵

🌊

Flux Denetleyicileri

🔄 ☸️

Kubernetes Kümesi

Flux denetleyicileri, Git deposundaki durumu kümeye sürekli senkronize eder.

Örnek Flux Kaynakları:


# app-source.yaml (Git Deposu Tanımı)
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: my-app-git-repo
  namespace: flux-system
spec:
  interval: 1m0s # Her 1 dakikada bir kontrol et
  url: https://github.com/your-org/my-app-manifests
  ref:
    branch: main # main branch'ini izle
---
# app-kustomization.yaml (Kubernetes Manifest Uygulaması)
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: my-app-kustomization
  namespace: flux-system
spec:
  interval: 5m0s # Her 5 dakikada bir senkronize et
  sourceRef:
    kind: GitRepository
    name: my-app-git-repo # Yukarıdaki GitRepository'yi kullan
  path: "./deploy/production" # Repo içindeki bu yoldaki manifestleri uygula
  prune: true # Git'te olmayan kaynakları sil

GitLab Runner, GitLab Agent ve Flux CD Karşılaştırması

Bu üç araç, Kubernetes ortamında uygulama dağıtımını ve yönetimini otomatikleştirmek için kullanılsa da, farklı yaklaşımlara ve kullanım senaryolarına sahiptirler. Seçiminiz, mevcut altyapınıza, güvenlik gereksinimlerinize ve tercih ettiğiniz operasyonel modele bağlı olacaktır.

Özellik	GitLab Runner	GitLab Agent	Flux CD
Temel Amaç	GitLab CI/CD işlerini yürütmek. Geleneksel CI/CD.	GitLab ile Kubernetes kümeleri arasında güvenli bağlantı; GitOps ve CI/CD entegrasyonu.	Kubernetes kümesini Git'teki istenen duruma göre otomatik olarak senkronize etmek (GitOps).
Dağıtım Yaklaşımı	Push (İtme) tabanlı. Runner, GitLab'dan aldığı komutlarla kümeye dağıtım yapar.	Pull (Çekme) tabanlı GitOps. Agent, Git'ten çeker. CI/CD ile hibrit kullanım mümkün.	Pull (Çekme) tabanlı GitOps. Küme içindeki denetleyiciler Git'ten çeker.
Kurulum Yeri	GitLab sunucusu dışında herhangi bir sunucu/VM/konteyner.	Hedef Kubernetes kümesi içinde (Agentk Pod'u).	Hedef Kubernetes kümesi içinde (bir dizi denetleyici Pod'u).
Küme Bağlantısı	CI/CD ortamından `kubectl` veya diğer araçlarla doğrudan erişim (API anahtarları/kubeconfig gerektirir).	Küme içindeki Agent ve GitLab sunucusu arasında güvenli gRPC tünel. Daha az hassas bilgi dışarıda.	Küme içindeki denetleyiciler Kubernetes API'sine erişir; Git reposuna erişim kendi kimlik bilgileriyle.
GitLab Bağımlılığı	GitLab CI/CD ile çalışmak için zorunlu.	Tamamen GitLab ekosistemine entegre. Yalnızca GitLab ile çalışır.	Git sağlayıcısından bağımsız. GitHub, GitLab, Bitbucket vb. ile çalışabilir.
Ana Kullanım Senaryosu	Kod derleme, test etme, imaj oluşturma, geleneksel Kubernetes dağıtımları (push).	Güvenli GitOps dağıtımları, özel/güvenli kümeleri yönetme, GitLab tabanlı GitOps.	Kapsamlı GitOps uygulama (uygulama ve altyapı), Helm/Kustomize yönetimi, satıcıdan bağımsız GitOps.
Gözlemlenebilirlik	GitLab CI/CD arayüzü üzerinden job logları ve durum.	GitLab UI üzerinden dağıtım durumu ve etkinlikler.	Küme içindeki kaynaklar, Flux CLI, ve bildirimler aracılığıyla ayrıntılı gözlemlenebilirlik.

Sonuç

Kubernetes ortamlarında sürekli entegrasyon ve dağıtım süreçleri için farklı ihtiyaçlara yönelik çeşitli araçlar bulunmaktadır. **GitLab Runner**, geleneksel push tabanlı CI/CD yaklaşımlarının temelidir ve GitLab işlem hatlarını güçlü bir şekilde yürütür. **GitLab Agent**, GitLab ekosistemi içinde Kubernetes için güvenli ve pull tabanlı bir GitOps deneyimi sunarken, **Flux CD** ise satıcıdan bağımsız, genişletilebilir ve tamamen GitOps prensiplerine odaklanmış kapsamlı bir araç setidir.

Seçiminiz, mevcut CI/CD altyapınızın GitLab merkezli olup olmadığına, güvenlik gereksinimlerinizin katılığına ve GitOps yaklaşımını ne kadar derinlemesine benimsemek istediğinize bağlı olacaktır. Genellikle, GitLab kullanıcıları için entegre bir deneyim için GitLab Agent mantıklı bir seçimken, daha esnek ve satıcıdan bağımsız bir GitOps aracı arayanlar için Flux CD öne çıkmaktadır.