mrvitej.in

DevOps · CNCF daily

Tekton: Kubernetes-Native Building Blocks for CI/CD

CNCF Incubating. A framework of Kubernetes custom resources for defining and running CI/CD pipelines as containers, with triggers, a dashboard and signed supply chain attestations.

6 min read

CNCF Incubating

  • Tekton
  • Kubernetes
  • Argo CD
  • Sigstore
  • SPIFFE and SPIRE
CNCF project page

Tekton is an open source framework for building CI/CD systems on Kubernetes. Pipelines are described as Kubernetes custom resources, and each step of a build runs as a container in a pod, so the cluster itself becomes the build infrastructure. It addresses the cost of maintaining a separate CI server: scheduling, isolation, secrets and scaling are delegated to Kubernetes, and pipelines become versioned, reusable YAML. Tekton began at Google as a build and pipeline effort around Knative and was donated to the Continuous Delivery Foundation (CDF) in March 2019. The CNCF announced on March 24, 2026 that its Technical Oversight Committee had accepted Tekton as an incubating project, and the project has since moved its governance and infrastructure towards CNCF processes.

CNCF daily · Sprint 2, day 1 · Continuous Integration & Delivery

At a glance
Category Continuous Integration & Delivery
CNCF status Incubating. Accepted March 13, 2026 (as recorded in the CNCF Landscape; announced March 24, 2026)
Written in Go
License Apache 2.0
Core resources Task, TaskRun, Pipeline, PipelineRun, Workspace
Companion projects Triggers, Chains, Dashboard, CLI, Pipelines as Code
Prior home Continuous Delivery Foundation, from March 2019

Architecture

flowchart TB
  GIT[Git push or pull request] --> EL[Triggers<br/>EventListener]
  EL --> TT[TriggerTemplate<br/>creates a PipelineRun]
  TT --> PR[PipelineRun]
  PIPE[Pipeline<br/>ordered Tasks] --> PR
  PR --> CTRL[Pipelines controller]
  CTRL --> TR[TaskRun<br/>one pod per Task]
  TR --> STEPS[Steps<br/>one container each]
  STEPS --> WS[Workspaces<br/>PVC, Secret, ConfigMap]
  STEPS --> REG[Image registry]
  TR --> CH[Chains<br/>sign and attest]
  CH --> REG
  DASH[Dashboard and CLI] --> PR
Component Responsibility
Task and Pipeline A Task is an ordered list of steps; a Pipeline arranges Tasks into a graph with parameters, results and conditions.
TaskRun and PipelineRun A single execution. Each TaskRun becomes one pod, and its steps run as containers in sequence.
Workspaces Shared storage between Tasks, backed by a PVC, Secret, ConfigMap or emptyDir.
Triggers An EventListener receives webhooks, and bindings and templates turn them into PipelineRuns.
Chains Observes completed runs, then signs artifacts and records provenance attestations.
Dashboard and CLI A web UI and the tkn command for inspecting, starting and following runs.
Resolvers Fetch Tasks and Pipelines from Git, OCI bundles or Tekton Hub, so definitions need not live in the cluster.

Design principle. Tekton provides primitives rather than a finished CI product. Tasks are small, versioned and shareable, so a platform team can compose them into an organisation-specific pipeline while teams reuse the same vetted building blocks.

Production reference design

A common pattern on EKS, GKE, AKS or on-premises: Tekton runs in a dedicated namespace, builds are triggered from Git, and deployment is handed to a GitOps controller.

  1. Install the Pipelines, Triggers and Dashboard components from the official release manifests: 
    kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
kubectl apply -f https://storage.googleapis.com/tekton-releases/dashboard/latest/release.yaml
    In production, pin an explicit release version instead of latest.
  2. Define a Task that builds an image without a privileged Docker daemon, for example by resolving a maintained buildpacks or kaniko Task from a resolver.
  3. Compose a Pipeline that clones, tests, builds and pushes, then updates the image tag in a GitOps repository: 
    apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-push
spec:
  params:
    - name: repo-url
    - name: image
  workspaces:
    - name: source
  tasks:
    - name: clone
      taskRef:
        resolver: hub
        params:
          - { name: name, value: git-clone }
          - { name: version, value: "0.9" }
      params:
        - { name: url, value: $(params.repo-url) }
      workspaces:
        - { name: output, workspace: source }
  4. Trigger on events with an EventListener behind an authenticated ingress, validating webhook secrets.
  5. Sign and attest artifacts with Chains, and let Argo CD or Flux deploy the verified image.

Typical uses are internal CI/CD platforms, vendor products built on Tekton (Red Hat OpenShift Pipelines is one), and supply chain pipelines that must produce signed provenance.

Operational considerations

  • Resource model: Every TaskRun is a pod, so cluster capacity, pod limits and image pulls dominate performance. Set requests and limits on steps and use node pools for build workloads.
  • Storage: Workspaces backed by PVCs add provisioning time and zone constraints. Prefer OCI-based caching or emptyDir where tasks permit.
  • Security: Run pipelines under dedicated service accounts with least privilege, avoid privileged steps, and use Chains with Sigstore for signing.
  • Housekeeping: Completed runs remain as resources and pods. Configure pruning so the API server and etcd are not filled with history.
  • Usability: Raw Tekton YAML is verbose. Many teams add Pipelines as Code or a platform layer so developers do not write it directly.

Adoption

The CNCF announcement names Puppet and Ford Motor Company as adopters, and Red Hat OpenShift Pipelines and IBM Cloud Continuous Delivery as commercial offerings built on Tekton. It reports more than 600 contributors and over 11,000 GitHub stars, and describes a multi-vendor community including Red Hat, Google and IBM. Few other end users are listed in official sources.

Alternatives

Solution Model Best suited to
Argo Workflows Kubernetes-native workflow engine Generic and data workflows, plus CI
Jenkins Server with agents and plugins Large existing estates, plugin needs
GitHub Actions and GitLab CI Hosted or self-hosted runners Teams already on those platforms
Dagger Pipelines as code in containers Portable pipelines run locally and in CI
Flux and Argo CD GitOps delivery only The deploy stage rather than the build

Strengths and limitations

Strengths Limitations
Fully Kubernetes-native, scales with the cluster Verbose YAML and a steeper learning curve
Reusable, versioned Tasks and Pipelines Primitives, not a complete CI product
Chains provides signing and provenance Pod-per-task overhead and workspace storage cost
Vendor-neutral, multi-company governance Fewer named public adopters than older CI tools
Integrates with Argo CD, SPIRE and Sigstore Run history needs pruning and monitoring

Recommendation

Trial for platform teams that already run Kubernetes and want a composable, supply-chain-aware CI/CD layer. Start with Pipelines, Triggers and Chains, pin versions, and consider Pipelines as Code to simplify developer experience. Teams that want a ready-made CI product, or whose pipelines are simple, are usually better served by their hosted CI.

References: CNCF project page · Tekton documentation · CNCF announcement · Tekton blog · Tekton on GitHub · CD Foundation announcement

Spotted something wrong or out of date?Suggest a correction. I review every suggestion before changing the page.