TL;DR

Tekton ist ein Kubernetes-natives CI/CD-Framework - Pipelines laufen als Pods direkt im Cluster
Das Ressourcen-Modell besteht aus Task, Pipeline, PipelineRun und TaskRun als Custom Resources
Tekton Hub bietet wiederverwendbare Tasks für git-clone, kaniko-build, kubectl-deploy und mehr
Pipelines sind deklarativ als YAML definiert und versionierbar in Git
Im Vergleich zu Jenkins oder GitHub Actions ist Tekton portabel und läuft auf jedem Kubernetes-Cluster

Tekton: Kubernetes-native CI/CD-Pipelines

Tekton ist ein Open-Source-Framework der CD Foundation, das CI/CD-Pipelines als Kubernetes-Ressourcen abbildet. Statt externer CI-Server laufen Builds und Deployments als Pods direkt im Cluster. Dieser Guide zeigt die Einrichtung und eine komplette Build-Test-Deploy-Pipeline.

Tekton installieren

# Tekton Pipelines installieren
kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

# Tekton Dashboard (optional, aber empfohlen)
kubectl apply --filename https://storage.googleapis.com/tekton-releases/dashboard/latest/release.yaml

# Warten bis alles läuft
kubectl wait --for=condition=Ready pods --all -n tekton-pipelines --timeout=120s

# Tekton CLI installieren (macOS)
brew install tektoncd-cli

Dashboard per Port-Forward öffnen:

kubectl port-forward svc/tekton-dashboard -n tekton-pipelines 9097:9097
# Browser: http://localhost:9097

Das Tekton-Ressourcenmodell

┌─────────────────────────────────────────────┐
│              PipelineRun                    │
│  (konkrete Ausführung einer Pipeline)       │
│                                             │
│  ┌─────────────────────────────────────┐    │
│  │           Pipeline                  │    │
│  │                                     │    │
│  │  ┌─────────┐  ┌─────────┐  ┌─────┐│    │
│  │  │  Task 1 │─▶│  Task 2 │─▶│ T 3 ││    │
│  │  │ (clone) │  │ (build) │  │(dep)││    │
│  │  └─────────┘  └─────────┘  └─────┘│    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

Ressource	Funktion
Task	Einzelner Arbeitsschritt mit Steps (läuft als Pod)
Pipeline	Verknüpft mehrere Tasks zu einem Workflow
TaskRun	Konkrete Ausführung eines Tasks
PipelineRun	Konkrete Ausführung einer Pipeline

Jede Ressource ist eine Kubernetes Custom Resource und wird als YAML definiert.

Tasks erstellen

Ein Task definiert einen oder mehrere Steps, die sequentiell in einem Pod ausgeführt werden.

Eigener Build-Task

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-and-push
spec:
  params:
  - name: image
    type: string
    description: Name des Container-Images
  - name: dockerfile
    type: string
    default: ./Dockerfile
  workspaces:
  - name: source
    description: Workspace mit dem Quellcode
  steps:
  - name: build
    image: gcr.io/kaniko-project/executor:latest
    args:
    ---dockerfile=$(params.dockerfile)
    ---destination=$(params.image)
    ---context=$(workspaces.source.path)
    ---cache=true

Test-Task

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: run-tests
spec:
  workspaces:
  - name: source
  steps:
  - name: unit-tests
    image: golang:1.22
    workingDir: $(workspaces.source.path)
    script: |
      #!/bin/sh
      go test ./... -v -cover
  - name: lint
    image: golangci/golangci-lint:latest
    workingDir: $(workspaces.source.path)
    script: |
      #!/bin/sh
      golangci-lint run ./...

Tekton Hub: Wiederverwendbare Tasks

Statt jeden Task selbst zu schreiben, bietet der Tekton Hub fertige Tasks für Standard-Aufgaben.

# git-clone Task installieren
tkn hub install task git-clone

# kubectl-deploy Task installieren
tkn hub install task kubernetes-actions

# Verfügbare Tasks durchsuchen
tkn hub search build

Beliebte Tasks aus dem Hub:

git-clone - Repository klonen
kaniko - Container-Images bauen ohne Docker-Daemon
helm-upgrade-from-source - Helm Charts deployen
kubernetes-actions - kubectl-Befehle ausführen

Komplette Pipeline: Build-Test-Deploy

Jetzt verbinden wir alles zu einer vollständigen Pipeline.

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-test-deploy
spec:
  params:
  - name: repo-url
    type: string
  - name: revision
    type: string
    default: main
  - name: image
    type: string
  - name: namespace
    type: string
    default: production
  workspaces:
  - name: shared-workspace
  - name: kubeconfig
  tasks:
  # Schritt 1: Source Code klonen
  - name: clone
    taskRef:
      name: git-clone
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.repo-url)
    - name: revision
      value: $(params.revision)

  # Schritt 2: Tests ausführen (nach Clone)
  - name: test
    taskRef:
      name: run-tests
    runAfter:
    - clone
    workspaces:
    - name: source
      workspace: shared-workspace

  # Schritt 3: Image bauen und pushen (nach Tests)
  - name: build
    taskRef:
      name: build-and-push
    runAfter:
    - test
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: image
      value: $(params.image)

  # Schritt 4: Deployment aktualisieren (nach Build)
  - name: deploy
    taskRef:
      name: kubernetes-actions
    runAfter:
    - build
    params:
    - name: script
      value: |
        kubectl set image deployment/myapp \
          myapp=$(params.image) \
          -n $(params.namespace)
        kubectl rollout status deployment/myapp \
          -n $(params.namespace) --timeout=300s

Pipeline ausführen

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  generateName: build-test-deploy-run-
spec:
  pipelineRef:
    name: build-test-deploy
  params:
  - name: repo-url
    value: https://github.com/myorg/myapp.git
  - name: revision
    value: main
  - name: image
    value: registry.example.de/myapp:v1.2.3
  - name: namespace
    value: production
  workspaces:
  - name: shared-workspace
    volumeClaimTemplate:
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
  - name: kubeconfig
    secret:
      secretName: kubeconfig-secret

Pipeline starten und beobachten:

# Pipeline via CLI starten
tkn pipeline start build-test-deploy \
  --param repo-url=https://github.com/myorg/myapp.git \
  --param image=registry.example.de/myapp:v1.2.3 \
  --workspace name=shared-workspace,volumeClaimTemplateFile=pvc.yaml \
  --showlog

# Oder via kubectl
kubectl create -f pipelinerun.yaml

# Logs anzeigen
tkn pipelinerun logs build-test-deploy-run-abc123 -f

# Status aller PipelineRuns
tkn pipelinerun list

Tekton Triggers: Automatische Ausführung

Tekton Triggers starten Pipelines automatisch bei Git-Events wie Push oder Pull Request.

# Triggers installieren
kubectl apply --filename https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-listener
spec:
  triggers:
  - name: github-push
    bindings:
    - ref: github-push-binding
    template:
      ref: pipeline-template
---
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: github-push-binding
spec:
  params:
  - name: repo-url
    value: $(body.repository.clone_url)
  - name: revision
    value: $(body.head_commit.id)
---
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: pipeline-template
spec:
  params:
  - name: repo-url
  - name: revision
  resourcetemplates:
  - apiVersion: tekton.dev/v1
    kind: PipelineRun
    metadata:
      generateName: triggered-run-
    spec:
      pipelineRef:
        name: build-test-deploy
      params:
      - name: repo-url
        value: $(tt.params.repo-url)
      - name: revision
        value: $(tt.params.revision)
      - name: image
        value: registry.example.de/myapp:$(tt.params.revision)
      workspaces:
      - name: shared-workspace
        volumeClaimTemplate:
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 1Gi

Vergleich: Tekton vs. Jenkins vs. GitHub Actions

Kriterium	Tekton	Jenkins	GitHub Actions
Laufzeit-Umgebung	Kubernetes-Pods	Eigener Server/Container	GitHub Cloud
Konfiguration	YAML (CRDs)	Jenkinsfile (Groovy)	YAML
Portabilität	Jeder K8s-Cluster	Eigene Instanz nötig	Nur GitHub
Skalierung	Kubernetes-nativ	Plugin-basiert	Hosted Runners
Wiederverwendung	Tekton Hub	Jenkins Plugins	Actions Marketplace
Vendor Lock-in	Keins	Keins	GitHub

Tekton eignet sich besonders, wenn Sie bereits Kubernetes nutzen und volle Kontrolle über Ihre CI/CD-Infrastruktur behalten möchten. Jenkins ist flexibler bei Legacy-Projekten, GitHub Actions einfacher für reine GitHub-Workflows.

FAQ

Brauche ich Docker für Tekton?

Nein. Tekton läuft komplett auf Kubernetes. Für Container-Builds nutzen Sie Kaniko oder Buildah, die keinen Docker-Daemon benötigen. Die Tasks laufen als reguläre Pods im Cluster.

Kann Tekton mehrere Tasks parallel ausführen?

Ja. Tasks ohne runAfter-Abhängigkeit laufen automatisch parallel. In der Pipeline-Definition steuern Sie über runAfter, welche Tasks sequentiell ablaufen müssen.

Wie unterscheidet sich Tekton von ArgoCD?

Tekton ist für CI/CD-Pipelines (Build, Test, Deploy). ArgoCD ist ein GitOps-Controller für kontinuierliche Synchronisation. Sie ergänzen sich: Tekton baut und testet, ArgoCD synchronisiert den Cluster-State mit Git.

Was kostet Tekton?

Tekton ist Open Source und kostenlos. Sie zahlen nur für die Kubernetes-Ressourcen, die Ihre Pipelines verbrauchen. Managed Varianten bieten Google Cloud (Cloud Build) und Red Hat (OpenShift Pipelines).

Wie debugge ich fehlgeschlagene Pipelines?

Nutzen Sie tkn pipelinerun logs <name> für die Logs aller Tasks. Mit kubectl describe taskrun <name> sehen Sie Events und Fehlermeldungen. Im Tekton Dashboard können Sie den Status visuell nachverfolgen.

Kubernetes-Expertise gesucht?

Managed Services, Beratung, Training oder Security – wir unterstützen deutsche Unternehmen bei allen Kubernetes-Themen.

Kontakt aufnehmen Kontakt aufnehmen

Tekton Pipelines: Cloud-native CI/CD auf Kubernetes