Tekton Pipelines: Cloud-Native CI/CD on Kubernetes

Tekton is the cloud-native CI/CD framework that comes up in conversations about Kubernetes-native pipelines, then immediately makes everyone read documentation for an hour to understand what they just heard. The vocabulary is heavy: Tasks, Pipelines, TaskRuns, PipelineRuns, Workspaces, Triggers. The underlying ideas are not complicated; the exposure to ten CRDs at once is.

This post is what Tekton actually does, when it is the right choice, and the minimum set of concepts to get a working pipeline running.

The Pitch

Tekton runs CI/CD pipelines as Kubernetes resources. Each step is a container. Each pipeline is a sequence (or DAG) of steps. The Kubernetes API is the source of truth — you kubectl get pipelineruns to see pipeline history, kubectl logs to see step output.

The advantages over GitHub Actions or GitLab CI:

• Runs entirely in your cluster — no third-party CI service, no shared runners, no service tokens to a vendor
• Native to Kubernetes — scaling, resource limits, networking are all Kubernetes concerns
• Highly composable — Tasks are reusable across Pipelines
• Open source and CNCF-graduated — no vendor lock-in

The disadvantages:

• Significant operational cost (you run it)
• Steeper learning curve than hosted CI
• Smaller ecosystem of pre-built tasks
• Less polished UI

Tekton is worth considering when you have specific reasons it fits better than hosted CI. Otherwise, GitHub Actions or GitLab CI is the easier default.

The Core Vocabulary

Tekton has a vocabulary problem. The five concepts you need:

Task. A reusable unit of work. Wraps one container with parameters and outputs.

Pipeline. A sequence (or DAG) of Tasks with parameters and shared workspaces.

TaskRun. An instance of a Task being executed. The actual running pod.

PipelineRun. An instance of a Pipeline being executed.

Workspace. A persistent volume shared across Tasks in a Pipeline.

That is most of what you need. The other concepts (Triggers, EventListeners, ClusterTasks, Conditions, Custom Tasks) layer on top.

A Minimal Pipeline

A simplified build-and-push pipeline:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: git-clone
spec:
  params:
    - name: url
  workspaces:
    - name: source
  steps:
    - name: clone
      image: alpine/git:latest
      script: |
        git clone $(params.url) $(workspaces.source.path)

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-image
spec:
  params:
    - name: image-name
  workspaces:
    - name: source
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:latest
      command: [/kaniko/executor]
      args:
        - --dockerfile=$(workspaces.source.path)/Dockerfile
        - --context=$(workspaces.source.path)
        - --destination=$(params.image-name)

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-push
spec:
  params:
    - name: repo-url
    - name: image-name
  workspaces:
    - name: shared-data
  tasks:
    - name: clone
      taskRef:
        name: git-clone
      params:
        - name: url
          value: $(params.repo-url)
      workspaces:
        - name: source
          workspace: shared-data
    - name: build
      runAfter: [clone]
      taskRef:
        name: build-image
      params:
        - name: image-name
          value: $(params.image-name)
      workspaces:
        - name: source
          workspace: shared-data

Three resources to do what GitHub Actions does in 10 lines of YAML. The verbosity is real.

The trade: this pipeline is now declarative, version-controlled, runs in your cluster, and reuses the Tasks across multiple Pipelines.

Triggering Pipelines

Tekton does not handle webhooks itself. Tekton Triggers adds:

• EventListener — receives webhooks
• TriggerBinding — extracts data from the webhook
• TriggerTemplate — creates a PipelineRun from the data

The full path from GitHub webhook to running pipeline involves four CRDs. For most teams, the better answer is to delegate the webhook handling to GitHub Actions or a simple HTTP service that creates the PipelineRun.

When Tekton Fits

Tekton makes the most sense when:

• You are already running Kubernetes at scale
• You want CI infrastructure to be Kubernetes-native (same operations as everything else)
• You have specific networking or security requirements that hosted CI cannot satisfy
• You build a lot of reusable pipeline components (the Task abstraction pays off)
• You have a platform team that can operate it

Companies running their own Kubernetes platforms (where the platform team operates everything) often pick Tekton. Companies on hosted Kubernetes (GKE, EKS) without a strong platform team usually do not.

When Hosted CI Is Still Better

For most teams:

• The setup cost is significant compared to "connect GitHub to GitHub Actions"
• Pipeline maintenance is real operational work
• The vocabulary is steep for new engineers
• Pre-built integrations are far smaller than GitHub Actions' marketplace

The pragmatic test: if you do not have a reason that GitHub Actions or similar is failing, you do not need Tekton.

Reusable Tasks

Tekton's strength is the Task abstraction. A Task is reusable across many Pipelines.

# A shared "test-php" Task
apiVersion: tekton.dev/v1
kind: ClusterTask  # cluster-wide, not namespaced
metadata:
  name: test-php
spec:
  params:
    - name: php-version
      default: "8.3"
  workspaces:
    - name: source
  steps:
    - image: php:$(params.php-version)
      script: |
        cd $(workspaces.source.path)
        composer install --no-interaction
        vendor/bin/phpunit

Every Laravel service in the cluster can use this Task in their Pipeline. Updating the test infrastructure once (different PHP version, new test framework) propagates to every consumer.

The Tekton Catalog (tekton.dev/catalog) has many community Tasks. The quality varies; vet before using.

UI and Observability

Tekton ships a dashboard (tektoncd-dashboard) that shows pipelines, runs, and logs. It is functional but less polished than dedicated CI UIs.

For day-to-day use, most teams supplement with:

• Slack notifications on pipeline completion
• Custom dashboards in Grafana with metrics from Tekton
• Logs forwarded to the cluster's central logging

The "everything in one terminal" benefit of kubectl is real, but so is the cost of needing to use kubectl for everything.

Performance and Resource Usage

Each TaskRun is a Kubernetes pod. This is great (full Kubernetes isolation) and expensive (pod startup time, scheduling overhead).

A pipeline with five tasks runs five pods sequentially. Pod startup is typically 5–15 seconds per pod. A short pipeline can have minutes of pure orchestration overhead.

Mitigations:

• Combine related steps into one Task (fewer pods)
• Use sidecars to keep services alive across steps within a Task
• Tune autoscaler responsiveness

For larger pipelines, the orchestration overhead is dominated by the actual work. For small pipelines, the overhead is significant.

Migration From Existing CI

If you have an existing CI investment, migrating to Tekton is real work. The Pipeline structure does not map 1:1 from GitHub Actions YAML or Jenkinsfiles. Each pipeline is a rewrite.

Most teams that migrate do it gradually: new pipelines in Tekton, old pipelines stay in the existing CI until they are touched. A full migration takes quarters, not weeks.

A Practical Verdict

Tekton is solid technology with a real ecosystem. For most teams in 2026, it is not the right answer because:

• The operational cost is high relative to hosted CI
• The vocabulary is steep
• The ecosystem (especially pre-built actions) is smaller

When it is the right answer:

• Large organizations running their own Kubernetes platforms
• Specific requirements that hosted CI cannot satisfy (compliance, networking, scale)
• Teams that have built or are building broader Kubernetes-native tooling

For everyone else, GitHub Actions, GitLab CI, or CircleCI is easier and usually adequate.

What to Try First

If you want to evaluate Tekton without committing:

1. Install Tekton on a cluster (kubectl apply -f https://...)
2. Run a single Pipeline that builds and pushes one image
3. Add triggers from GitHub
4. Run it for a month

The evaluation will tell you whether the operational burden is worth the benefits. Most teams discover it is not. Some discover it is exactly what they need.

Evaluating Tekton against hosted CI for a Kubernetes-heavy platform? We help teams scope the decision honestly, accounting for the operational cost of running it yourself. scopeforged.com