Tekton

CI/CD as Kubernetes Custom Resources. Task, Pipeline, PipelineRun, TaskRun. Tekton Catalog for reusable Tasks. Powers OpenShift Pipelines, Jenkins X, Google Cloud Build (post-2023 rebuild). The K8s-native answer to "should pipelines be CRDs?"

Overview

Tekton: CI/CD as Kubernetes resources

Tekton is Kubernetes-native CI/CD: pipelines defined as CRDs (Custom Resource Definitions) and executed by a Kubernetes controller. It originated at Google as part of the Knative project and was donated to the CD Foundation (CDF) in 2019. It now powers Google Cloud Build (rebuilt on Tekton in 2023), OpenShift Pipelines (Red Hat's CI/CD) and Jenkins X.

The pitch: if you already run Kubernetes, treating pipelines as Kubernetes resources is operationally cohesive. kubectl apply / get / describe work on Pipelines and PipelineRuns; RBAC, NetworkPolicy and ResourceQuota apply uniformly; Argo CD or Flux manage Tekton resources via GitOps.

Where Tekton wins

Kubernetes-native operations — Logs and resources in kubectl, audit in the K8s API audit log; no separate CI control plane
Reusable Task composition — Mature, documented Tekton Catalog Tasks (git-clone, kaniko, buildah, cosign, helm-upgrade) from Tekton Hub
Strong with GitOps — Pipelines are YAML manifests: commit, Argo CD/Flux applies, the controller runs them
Multi-tenancy via namespaces — Each team's namespace holds its Tasks, Pipelines and PipelineRuns, isolated by K8s RBAC; cleaner than Jenkins's project-scoped auth
Cloud-portable — The same Pipeline YAML runs on EKS, GKE, AKS, on-prem K8s, OpenShift

Where Tekton loses

YAML-heavy and lower-level — More verbose than GHA; params, workspaces and results need explicit declaration; overwhelming for newcomers
Smaller ecosystem — ~200 curated Tasks vs GHA's 25,000 actions
Operational complexity — Kubernetes plus the Tekton controllers (Pipelines, Triggers, Dashboard, Operator); a real entry cost without K8s expertise
UX — Tekton Dashboard is adequate but notably less refined than GHA, GitLab or even Jenkins Blue Ocean

When to pick it

A platform team building internal, multi-tenant CI as a K8s platform service — Small teams without K8s expertise: install, RBAC, Triggers, Dashboard and monitoring cost more than they return
Cloud-portable / multi-cloud CI without lock-in — Teams wanting polished daily-use CI UX
Already K8s-deep: Operators, CRDs, Argo CD/Flux — OSS projects on GitHub: GHA is free and easier
Building a CI/CD product for customers (as Cloud Build and OpenShift Pipelines do)

Three load-bearing concepts

Pipelines are CRDs — Every Pipeline, Task and PipelineRun is a Kubernetes resource managed via kubectl + RBAC: the whole value proposition
Tekton Catalog — Don't write your own git-clone or kaniko Task; install from hub.tekton.dev. Smaller than the GHA marketplace, well curated
Tekton Triggers — EventListener + TriggerBinding + TriggerTemplate turn a webhook into a PipelineRun: more moving parts than GHA's on:, more flexible

Key concepts

Task — reusable unit: A Task is a CRD describing steps that run in a Pod. Each step is a container with its own image and command. params are typed inputs. workspaces are volumes mounted into all steps. results are values written to /tekton/results/ that downstream Tasks can consume. Steps run sequentially in the same Pod. Workspace data persists across steps within a Task; the next Task's TaskRun uses a different Pod (workspaces are how data flows across Task boundaries). ClusterTask is the same shape but at cluster scope (visible from any namespace). StepAction (Tekton Pipelines v0.55+, 2024) is a newer single-step reusable unit; Tasks compose StepActions. Many Catalog tasks are migrating to StepActions for finer-grained reuse.
Pipeline — DAG of Tasks: A Pipeline composes Tasks. Like a workflow in GHA but as a CRD. runAfter declares dependencies. when block is conditional execution (Tekton's equivalent of GHA's if:). $(tasks.build.results.image-digest) propagates results from one Task to another. finally tasks run after all main tasks regardless of outcome (cleanup, notifications):
PipelineRun — runtime instance: A PipelineRun is a runtime instance of a Pipeline. Created on every trigger. Tekton controller watches PipelineRuns and creates child TaskRuns / Pods. Key fields: - generateName auto-suffixes a unique ID; one PipelineRun per trigger. - volumeClaimTemplate creates a PVC for the workspace; auto-deleted after PipelineRun completion (configurable). - taskRunTemplate sets defaults for all child TaskRuns: ServiceAccount, security context, node selector, tolerations. Lifecycle: created → controller resolves Pipeline → spawns TaskRuns → TaskRuns spawn Pods → Pods run steps → PipelineRun status updates → completion (Succeeded / Failed). History: PipelineRuns persist as K8s resources. kubectl get pipelinerun -n ci shows recent runs. Default retention is forever; tekton-pipelines-resolvers handles auto-cleanup via PrunerConfig CRD.
Workspaces — volumes across Tasks: Workspaces are the data-flow primitive. Tasks declare workspace requirements; PipelineRun resolves them to actual volumes. Volume sources for workspaces: - volumeClaimTemplate — PVC created per PipelineRun; data persists across Tasks; auto-deleted on cleanup. - persistentVolumeClaim — refer to existing PVC; useful for cross-PipelineRun caches. - emptyDir — ephemeral; only useful within a single Task (multiple steps). - configMap — read-only config files mounted as workspace. - secret — read-only secrets mounted as workspace. - projected — multiple sources combined. Common pattern — repo workspace + cache workspace: Tasks reference workspaces by name: The maven-build Task mounts /workspace/source and /workspace/cache. Source is per-run; cache is shared. Subpath access: workspaces.source.path is the mount root; you can use workspaces.source.subPath in volume mounts to scope a Task to a subdirectory of the workspace. Workspace declarations are how Tekton avoids the artifact upload/download dance that GHA requires for cross-job state. The cost: you need PVCs, which means a CSI driver and storage class on your cluster.
Tekton Triggers — event-driven: Tekton Triggers makes pipelines run on webhooks/events. Five components: EventListener — K8s Service + Deployment that exposes HTTP endpoint: TriggerBinding extracts data from event payload: TriggerTemplate produces a PipelineRun: Setup: configure GitHub webhook to POST to the EventListener Service (typically exposed via Ingress). Webhook signing secret matches what the GitHub interceptor validates. Push events match the CEL filter. Binding extracts; template fires. Compared to GHA's on: triggers — Triggers is more verbose but more flexible. Custom interceptors can do anything (filter by file path, by author, by JIRA ticket reference).
Recipe: PipelineRun pruning + history: Without pruning, PipelineRuns accumulate forever — a busy CI namespace can have 10,000+ resources after months. Etcd storage and API performance degrade. Three options: 1. Tekton Pruner (built-in, Tekton Pipelines v0.50+): 2. CronJob with kubectl: 3. Tekton Operator's TektonConfig has built-in pruner: For long-term history, export PipelineRun YAML to S3 / object storage before pruning. Or use Tekton Results (separate component) for queryable durable history with API access.
Recipe: GitOps-managed Tekton with ArgoCD: Pipelines as YAML in git, applied by ArgoCD. The full GitOps story: Repo layout: argocd/tekton-app.yaml: What this gives you: - Pipelines as code, reviewed via PR. - ArgoCD continuously reconciles — drift between cluster state and git fires alerts. - Pipeline changes deployed by merge to main; rollback by reverting the commit. - Audit trail in git log + ArgoCD UI. Note: PipelineRuns are NOT managed by ArgoCD (they're ephemeral; ArgoCD would constantly reconcile). Only the static definitions (Task, Pipeline, EventListener, etc.). PipelineRuns are created by Triggers or manual kubectl. This is the killer Tekton + GitOps pattern. Operationally cohesive: same kubectl, same GitOps, same RBAC for app deploys and CI definitions.

When to use it

Platform team building internal CI as a multi-tenant K8s platform service
Cloud-portable / multi-cloud CI without vendor lock-in
Already deep in Kubernetes operations (Operators, CRDs, GitOps)
Building a custom CI/CD product (Google Cloud Build pattern)
Heterogeneous workloads where K8s scheduling primitives matter (GPU, taints, node selectors)

Interview questions

When is Tekton the right choice over GitHub Actions?
Walk through a production Tekton setup — install, Tasks, Triggers, monitoring.
Compare Tekton vs Argo Workflows — when do you pick each?
Quick-fire interview answers — Tekton essentials.
How do you handle a Tekton PipelineRun that's stuck or running too long?