Tekton ile CI/CD: Kubernetes'te Kurulumdan Webhook'a

Tekton Nedir: Kubernetes-Doğal CI/CD Framework'ü

Pandemi yıllarında Cloud Native Computing Foundation (CDF) çatısı altında olgunlaşan Tekton, Jenkins tabanlı CI/CD mimarilerini modernleştirmek isteyen ekiplerin karşısına çıkan en güçlü açık kaynak çözümden biri oldu. Google'ın Knative ekosisteminin ilk çocuklarından biri olarak doğan Tekton, 2019'da CDF'e devredildi ve bugün Red Hat, IBM, Google ve Broadcom gibi oyuncuların üretim ortamlarında aktif olarak kullandığı bir mimariye kavuştu. Piyasada Jenkins'e yeni bir alternatif arayan birçok mühendisin aklında şu soru oluşuyor: «Aynı işi yapan bir Jenkinsfile yazıp aynısını Kubernetes üzerinde koştuğuma ne kadar değiyor?» Cevap, mimarinin temel felsefesinde yatıyor.

Tekton'un en dikkat çeken özelliği, bir CI/CD aracına dönüşmekten çok, bir CI/CD iskeletine dönüşmesidir. Tekton, cluster'ınızı bir deploy hedefinden çıkarıp build platformu haline getirir. Yani bir pipeline'ı ayağa kaldırdığınızda arka planda gizli bir build sunucusu başlamaz — cluster'ın kendi scheduler'ı, RBAC sistemi ve pod izolasyonu devreye girer. Pipeline'ı tanımlayan YAML dosyası, normal bir Deployment gibi bir Kubernetes kaynağıdır ve controller'lar tarafından Reconcile edilerek çalışan Pod'lara dönüştürülür. Jenkins master'ı için patchlemek, GitLab Actions'ın control-plane bağımlılığını yönetmek ya da self-hosted runner'ları canlı tutmakla uğraşmazsınız; Tekton'da build bir nesnedir, bir PipelineRun nesnedir ve cluster'ın geri kalanıyla aynı düzlemde yönetilir.

Bu makalede Tekton'u sadece teori olarak değil, install etmekten, bir Task yazmaktan, Pipeline kurmaktan, webhook ile GitHub tetiklemekten ve ArgoCD ile birleştirmeye kadar tam bir üretim akışına dönüştüreceğiz. İçerik tamamen uygulamaya dönük; YAML örneklerini kopyalayıp kendi cluster'ınıza uygulayabileceksiniz. Özellikle GitHub Actions'ın sunucu tarafında sağladığı esnekliği, ama kendi altyapınızda ve kendi RBAC'inizle sürdürmek isteyen ekipler için ideal bir başlangıç rehberidir.

Tekton'un Mimari Felsefesi: Neden Cluster Kendi Build Sistemi Olmalı?

Geleneksel CI/CD sunucuları (Jenkins, Bamboo, GitLab Runner'ın controller'ı) genellikle cluster'ın dışında veya yanına eklenen ayrı bir kontrol düzlemi olarak çalışır. Jenkins master bir JVM süreci olarak ayakta durur, agent'ları bir proxy üzerinden yönetir ve her job için pod'ları o sunucu üzerinden fışkırtır. Bu model yıllarca iş yaptı; ancak Kubernetes döneminde birkaç kritik dezavantaj getirir: ayrı bir patchlenecek servis, ayrı bir ölçeklendirme mantığı ve Jenkins'in kendine has plugin bağımlılığı.

Tekton bu modeli tersine çevirir. Tekton'un dört temel kavramı (Task, Pipeline, TaskRun, PipelineRun) doğrudan Kubernetes Custom Resource Definitions'ına (CRD) denk gelir. Siz bir Task tanımlarsınız, controller o Task'ı bir DAG (Directed Acyclic Graph) olarak parse eder, her Task'ı bir Pod'a, her Step'i de o Pod'un içinde bir container'a dönüştürür. Pod öldüğünde Kubernetes'in kendi recovery mekanizması devreye girer; bir node çöktüğünde cluster API node'u değiştirir ve build aynen diğer bir workload gibi yeniden schedule edilir. Yani build süreci için fleet'inize ikinci bir control plane eklemiş olursunuz, Jenkins'in baş ağrısı olan master bağımlılığı ortadan kalkar.

Bu yaklaşımın sağladığı en büyük avantaj, Tekton'un cluster'ın sunduğu tüm yetenekleri miras almasıdır: ResourceQuota ile build'lerin bellek/CPU tavanları, LimitRange ile otomatik kaynak ayarlaması, ServiceAccount ile her pipeline'a özel RBAC, ve namespace bazlı yalıtım. Jenkins agent'ları için manuel provisioning yapmak yerine, Kubernetes'in kendi autoscaler'ı ile build yükünü ölçeklendirirsiniz. Aşağıdaki tabloda Tekton'un geleneksel araçlardan farkı özetlenmiştir.

Özetle: Tekton bir «arac» değil, bir «platform bileşenidir». Onu bir deployment gibi görüp yönetirseniz, Kubernetes'in tüm gücünü pipeline'larınıza miras olarak miras alırsınız.

Temel Kavramlar: Task, Steps ve Pipelines

Tekton'a hakim olmak için dört ana nesneyi iyi anlamak gerekir. Bunlar birbirinin üzerine inşa edilir: Task atomik çalışmadır, Pipeline bunları birleştirir, TaskRun ve PipelineRun ise bu tanımların canlandırılmış halidir.

Task ve Step Tasarımı: Bir Adım Bir Container'a Denk Gelir

Task, Tekton'daki en küçük çalıştırılabilir birimdir. Bir Task, sıralanmış bir Steps listesinden oluşur ve her Step bir container image üzerinde tek bir komutu çalıştırır. Tekton'un container contract'ına göre her image ya tamamlanır ya da ilk hatada düşer. Adım adımda ilerleyen bir build süreci (git clone → build → test → push) doğal olarak bir Task'a uyar.

Aşağıda bir Docker image build eden örnek Task'ı görüyorsunuz. Parametrelerle esnek kılınmış ve her step'e timeout verilmiştir:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-image
spec:
  params:
    - name: image
      type: string
      description: Build edilecek container image'in tam adresi
    - name: dockerfile
      type: string
      default: Dockerfile
  workspaces:
    - name: source
      description: Kaynak kodun bulunduğu paylaşımlı alan
  steps:
    - name: build
      image: docker.io/docker/dockerfile:24
      args:
        - build
        - -f
        - $(params.dockerfile)
        - -t
        - $(params.image)
        - .
      securityContext:
        capabilities:
          add: ["SYS_ADMIN"]
      timeout: 30m
    - name: push
      image: docker.io/docker/dockerfile:24
      script: |
        docker buildx create --use
        docker buildx build -t $(params.image) . --push
      timeout: 30m

Bu örnekte dikkat çeken noktalar var: workspaces ile kaynak kodu paylaşımlı bir alana bağlarız, her step'in kendi securityContext'ı olur (Docker build için SYS_ADMIN yetkisi gerekir), ve timeout ile bir step'in maksimum ömrünü belirleriz. $(params.image) sentaksıyla parametreleri Step içerisinden okuruz.

Workspaces: Adımlar Arasında Veri Paylaşımı

Jenkins'te bir job içinde workspace'i manuel kopyalamak ya da artifact'ları bir step'ten diğerine upload etmek sıkça yapılır. Tekton'da böyle bir şey gerekir: aynı Task içindeki Step'lerin aynı dosyayı görmesi gerekir. Tekton bunu Workspace kavramıyla çözer. Workspace, pod'un belirli bir yoluna mount edilen bir Volume (genellikle PVC ya da emptyDir) olduğundan, Step'lerin çoğu zaman aynı pod içinde çalışır ve ortak dosya sistemine erişir.

workspaces:
  - name: source
    description: Kaynak kod için paylaşımlı alan

Bu workspace'i Task içinde workspace: source ile Step'lere bağlarsınız. Pipeline seviyesindeyse PVC ya da ConfigMap ile kalıcı hale getirip birden fazla TaskRun'ın aynı veriye erişmesini sağlayabilirsiniz. Veriyi pod içine gizli tutmak, artifact'ları registry'ye kaydetmek gibi pratik avantajlar da sunar.

Results: Pipeline İçi Sonuç Paylaşımı

Bazen bir Step'in çıktısını (örn. image digest, test sonucu) bir sonraki Task'a iletmeniz gerekir. Tekton bu için Results mekanizmasını sunar. Bir Task, sonuçlarını results: altında bildirir ve Step'ler bu sonuçları dosya olarak yazar. Sonuçlar küçük string değerlerdir; daha büyük veriler için PVC kullanılır.

spec:
  results:
    - name: image-digest
      description: Build edilen image'in sha256 digest'i
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:latest
      script: |
        /kaniko/executor --context . --destination $(params.image)
      results:
        outputPath: /kaniko/results/digest.txt

Bu yaklaşım, örnekteki digest'i bir sonrakı Step'in $(results.image-digest.path) olarak okuyarak, tag ile digest'i birleştirmenizi sağlar.

Pipeline: Task'ları Birbirine Bağlayan DAG

Pipeline, Task'ları belirli bir sırada ve veri bağımlılıklarıyla bir araya getirir. Tekton'da her Task, Pipeline içinde runAfter alanıyla bir sonraki Task'a bağlanır. runAfter belirtilmeyen Task'lar bağımsızsa parallel olarak çalışır; bu da build sürelerini önemli ölçüde kısaltır.

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-deploy-pipeline
spec:
  workspaces:
    - name: shared
    - name: registry-auth
  params:
    - name: image
      type: string
  tasks:
    - name: build
      taskRef:
        name: build-image
      workspaces:
        - name: source
          workspace: shared
    - name: test
      taskRef:
        name: run-tests
      runAfter:
        - build
      workspaces:
        - name: source
          workspace: shared
    - name: deploy
      taskRef:
        name: deploy-app
      runAfter:
        - test
      workspaces:
        - name: source
          workspace: shared
        - name: registry-auth
          workspace: registry-auth
      params:
        - name: image
          value: $(params.image)

Bu yapıda build → test → deploy zinciri oluşur. test, build tamamlandıktan sonra (runAfter: build) başlar. deploy ise hem build hem test'in geçmesini bekler. Pipeline'ı çalıştırmak için bir PipelineRun nesnesi oluşturursunuz; bu da controller'a «bu şablonu, şu parametreyle canlandır» demektir. Bir Pipeline'ı defalarça aynı parametreyle çalıştırabilir, her seferinde farklı bir tag ile üretim alıp deploy edebilirsiniz.

Tekton Triggers: Webhook ile Otomatik Pipeline Tetikleme

Makaleyi gerçekten pratik kılan kısım burası: Git'e push yapıldığında otomatik olarak build + deploy başlatmak. Tekton'un Triggers component'i, bir GitHub/GitLab webhook'u geldiğinde bir PipelineRun'ı canlandırır. Bu bileşen, Pipelines'ın üzerine inşa edilen bir uzantıdır ve üç ana nesneden oluşur.

EventListener: HTTP endpoint'ini dinler ve bir webhook geldiğinde hangi Trigger'ın çalışacağını belirler. Bir LoadBalancer veya Ingress ile dışarıdan erişilebilir hale getirilir.

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: git-push-listener
spec:
  serviceAccountName: tekton-triggers-sa
  triggers:
    - name: github-push-trigger
      interceptors:
        - ref:
            name: github
        - ref:
            name: filter-github-push
      bindings:
        ref: github-push-binding
      template:
        ref: github-push-template

TriggerBinding: Gelen webhook payload'ından ilgili veriyi (branch name, commit SHA, author) çıkarır.

apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: github-push-binding
spec:
  params:
    - name: git-revision
      value: $(body.head_commit.id)
    - name: git-branch
      value: $(body.ref)
    - name: git-username
      value: $(body.pusher.name)

TriggerTemplate: Event algılandığında oluşturulacak olan PipelineRun'ın şablonudur. Binding'den gelen parametreleri alıp PipelineRun'ı canlandırır.

apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: github-push-template
spec:
  params:
    - name: git-branch
    - name: git-revision
    - name: image
  resources:
    templates:
      - ref:
          name: tekton-pipeline-run
      params:
        - name: git-branch
          value: $(tt.git-branch)
        - name: git-revision
          value: $(tt.git-revision)
        - name: image
          value: myregistry.layer.web.tr/myapp:$(tt.git-revision)

ClusterInterceptor: İsteğe bağlıdır; webhook payload'ını doğrulamak (örn. GitHub secret'ı ile signature check) ya da transform etmek için kullanılır. kn CLI'sı ya da tkn triggers bootstrap komutu, tüm bu nesneleri tek komutla otomatik kurmanızı sağlar.

Kurulum: kubectl ile Tekton ve Triggers

Tekton'u kendi cluster'ınıza kurmak oldukça basittir; her component ayrı bir release.yaml ile dağıtılır. Aşağıdaki komutlarla önce temel Pipelines'ı, sonra Triggers'ı kurabilirsiniz.

# Tekton Pipelines (motor)
kubectl apply --filename \
  https://storage.googleapis.com/tekton-releases/pipelines/latest/release.yaml

# Tekton Triggers (webhook entegrasyonu)
kubectl apply --filename \
  https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
kubectl apply --filename \
  https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.yaml

Kurulumdan sonra pod'ların hazır olduğunu tekton-pipelines namespace'inde izleyebilirsiniz. Aşağıdakiler READY 1/1 gösterdiğinde, tetiklemeye hazırsınız:

kubectl get pods -n tekton-pipelines --watch
# beklenen pod'lar:
#  tekton-pipelines-controller-786b59d5cd-jt7d9    1/1 Running
#  tekton-pipelines-webhook-74b5cdfcc4-g4qj2        1/1 Running
#  tekton-triggers-controller-784d896c7f-s5c7s     1/1 Running
#  tekton-triggers-core-interceptors-54d9f764b     1/1 Running
#  tekton-triggers-webhook-666c844478-4cqcv         1/1 Running

Aynı zamanda tkn CLI'sını makinenize kurmanızı öneririm; tkn pipeline list, tkn ptrl history ve tkn dashboard open gibi komutlarla state'i görüntüleyebilir ve yerel bir dashboard açabilirsiniz.

Kaniko ile Safe Container Build: Build'in İçinde Docker Olmadan

Geleneksel Docker build'leri docker build komutu için privileged mod (root) gerektirir. Tekton pod'larında privileged olarak çalışmak güvenlik açığı yaratabilir. Çözüm: Kaniko. Kaniko, bir Pod içinde Docker daemon'u kullanmadan container image build eden bir araçtır; her layer'ı filesystem üzerinde «fake build» ile üretip registry'ye push eder. Build süreci container'ın içinde, pod'un içinde gerçekleştiği için tam izolasyon sağlanır.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-image-kaniko
spec:
  workspaces:
    - name: source
    - name: dockerconfig
  params:
    - name: image
      type: string
  steps:
    - name: kaniko-build
      image: gcr.io/kaniko-project/executor:latest
      workingDir: /workspace/source
      args:
        - --context=/workspace/source/.
        - --destination=$(params.image)
        - --digest-file=/kaniko/results/digest.txt
      env:
        - name: DOCKER_CONFIG
          value: /workspace/dockerconfig/.docker/

Bu Task'ı kullanırken dockerconfig workspace'ine bir docker-secret bağlamanız gerekir; kaniko bu secret ile registry'ye auth olarak bağlanır. Privileged mod gerekmemesi, production ortamlarında en büyük güvenlik avantajıdır.

ArgoCD ile Entegrasyon: CI ve CD'yi Birleştirmek

Cepler çoğu zaman şu soruyla karşılaşır: «Tekton build'i yaptı, image'ı registry'ye koydu, şimdi deployment?'» Bu sorunun cevabı genellikle ArgoCD'dır. Tekton bir build motoruyken, ArgoCD bir GitOps deployment aracıdır. İkisini birlikte kullanmak, «CI/CD'nin en iyisi» formülünü sunar: Tekton build + test'i yönetir, ArgoCD ise image'ın cluster'a senkronizasyonunu sağlar.

Pratik akış şöyledir: Tekton Pipeline'ı image'ı build eder, digest'i bir ConfigMap'e yazar, ardından ArgoCD'nin Auto-Sync özelliği o ConfigMap/Deployment'i takip eder ve otomatik olarak güncel image ile deploy'u uygular. Bu sayede deployment adımı da Git'e düşer, manuel bir deploy operatörü kalmaz. Tekton tek başına da deploy edebilir (örneğin bir Step içinde kubectl apply), ama büyük/multi-cluster ortamlarda ArgoCD'nin rollback, health-check ve vizuel dashboard özellikleri çok daha avantajlıdır.

En İyi Uygulamalar ve Araç Karşılaştırması

Tekton vs Jenkins: Hangisi?

Jenkins yılların tecrübesidir ve devasa bir plugin ekosistemi sunar; ancak Groovy/Jenkinsfile syntax'ı vendor-specific olur, persistent JVM süreci yönetimi ek işdir ve ölçeklendirme için agent provisioning gerekir. Tekton ise tam tersine: standard YAML, her K8s üzerinde taşınabilir, pod bazlı ölçeklendirme ve Jenkins'in master/agent ikilemini ortadan kaldırır. Öğrenme eğrisi Tekton'da daha diktir (Tasks, Workspaces, Results, Triggers kavramlarını sıfırdan öğrenmek gerekir) ama Kubernetes'i iyi bilen ekipler için doğal bir geçiştir.

Tekton vs Argo Workflows: Farkı Nedir?

İkisi de CNCF'dir, ikisi de CRD kullanır ve ikisi de Jenkins'i değiştirmek ister; ama farklı işlere sahiptir. Tekton özünde bir CI/CD framework'üdür — build, test, deploy için özel olarak tasarlanmıştır ve Triggers ile webhook entegrasyonu yerleşiktir. Argo Workflows ise genel amaclı bir workflow enginedür; veri bantları, ML eğitim job'ları ve DAG tabanlı her türlü otomasyonda kullanılabilir. Build odaklıysanız Tekton, genel otomasyon arıyorsanız Argo Workflows daha uygundur.

Tekton vs ArgoCD: Tam Ayrım

Bu en sık karıştırılan ikilidir. ArgoCD bir GitOps deployment aracıdır ve pipeline çalıştırma; sadece Git ile cluster state'ini senkronize eder. Tekton bir pipeline motorudur. «Hangisini kullanmalıyım» sorusunun cevabı: her ikisini de. Platform ekipleri için en popüler kombinasyon «ArgoCD + Tekton»dur: Tekton build'i, ArgoCD deployment'i yönetir. Tek başına Tekton kullanacaksanız, multi-cluster desteği yerleşik değildir; her cluster'a ayrı Tekton kurmanız ya da ArgoCD ile birleştirmeniz gerekir.

Karşılaştırma özeti: 90% ekip için «CI için Tekton + CD için ArgoCD» idealdir. Sadece build test istiyorsunuzsa Tekton; sadece deployment istiyorsunuzsa ArgoCD yeterlidir.

Sonuç: Tekton'a Neden Geçmelisiniz?

Tekton, CI/CD'yi Kubernetes'in kendi diline çeviren bir mimaridir. Jenkins'in master/agent ikilemini, ayrı bir build sunucusu yönetim zahmetini ve vendor-specific syntax bağımlılığını ortadan kaldırır. Task'ları Git'e koyup apply etmek, pipeline'ı pod olarak yönetmek, webhook ile tetiklemek ve ArgoCD ile birleştirmek — tümü native Kubernetes kavramları üzerine kurulu. Öğrenme eğrisi diktir ama ödül de ona göre: kendi altyapınızda, kendi RBAC'inizle, Kubernetes'in tam gücünü kullanan bir CI/CD platformu. Özellikle GKE üzerinde Cloud Build kullananlar, ya da «pipelines'ı bir hizmet olarak ekiplere sunmak» isteyen platform ekipleri için Tekton, 2026'nın en mantıklı yatırım noktalarından biridir.