Modern software delivery demands more than a CI/CD tool that runs alongside Kubernetes — it demands one that runs inside it. Tekton is exactly that: an open-source, Kubernetes-native CI/CD framework that treats your cluster as the build platform itself, not just a deployment target.
Originally developed at Google as part of the Knative project and donated to the Continuous Delivery Foundation (CDF) in 2019, Tekton has matured into the engine powering production CI/CD at organizations including Red Hat, Google, IBM, and Broadcom. It is the technology behind OpenShift Pipelines and Red Hat Konflux — two of the most widely adopted enterprise developer platforms today.
Hands-On Field Guide — All YAMLs, Tasks, Pipelines & Installation Steps:
This post is accompanied by a complete, hands-on GitHub repository with every YAML file, Task definition, Pipeline example, Workspace configuration, Trigger setup, and step-by-step installation guide you need to learn and test Tekton on a real Kubernetes cluster — from your very first Task through event-driven pipelines and supply chain security with Tekton Chains:
github.com/ay-garg/tekton-field-guide
The repository is organized to follow this post exactly — you can clone it, spin up a local Kind or Minikube cluster, and run every example yourself. It covers Tasks, TaskRuns, Pipelines, PipelineRuns, Workspaces, Triggers, Tekton Chains, and the Tekton Dashboard.
Official Tekton Project Links:
Core engine & CRD reference: github.com/tektoncd/pipeline
Full ecosystem (Triggers, Chains, Dashboard, CLI): github.com/tektoncd
For a hands-on walkthrough of everything covered in this post, check out the Tekton Field Guide YouTube playlist — a step-by-step video series taking you from installation to a fully automated, event-driven CI/CD pipeline on Kubernetes: Watch the Playlist
The Problem: Why Traditional CI/CD Falls Short in Kubernetes Environments
Before understanding what Tekton offers, it’s worth understanding the friction that prompted its creation.
Traditional CI/CD tools like Jenkins, CircleCI, or Travis CI were designed for a pre-Kubernetes world. They operate as separate services that talk to Kubernetes rather than living inside it. This architectural separation creates a cascade of real-world problems:
- Dual operational burden: Teams must manage their CI system separately from their cluster — different scaling, separate secrets management, distinct RBAC, and independent upgrades.
- Inconsistent security posture: Build secrets, credentials, and network policies that you meticulously configure in Kubernetes don’t automatically extend to an external CI server.
- Resource inefficiency: A dedicated Jenkins controller sitting idle burns compute resources that Kubernetes could be scheduling useful workloads on.
- No supply chain guarantees: Traditional tools offer no native, cryptographic way to prove what code was built, by what process, with what inputs — a critical gap in today’s software security landscape.
- Portability lock-in: Pipelines defined in proprietary DSLs (Groovy in Jenkins, Yaml-with-magic in GitHub Actions) are tightly coupled to their host platform and cannot be portably reused across different clusters or providers.
Tekton was created to solve all of these problems simultaneously by making CI/CD a first-class citizen of the Kubernetes API itself.
What Is Tekton, Exactly?
Tekton extends the Kubernetes API with a set of Custom Resource Definitions (CRDs) that define CI/CD primitives: Tasks, Pipelines, Triggers, and more. From Kubernetes’ perspective, a Tekton pipeline is just another workload — described in YAML, managed by controllers, and executed as Pods.
“Tekton is not a CI/CD tool that runs on Kubernetes. Tekton is Kubernetes — every pipeline run is a set of Pods, every task is a CRD, and your entire CI/CD configuration lives in the cluster like any other resource.”
This distinction is fundamental. Because Tekton builds on Kubernetes primitives rather than working around them, everything you already know about operating Kubernetes applies directly to operating Tekton: RBAC for access control, Namespaces for isolation, PersistentVolumeClaims for storage, Secrets for credentials, and resource requests and limits for compute governance.
Tekton Architecture: Four Components, One Platform
Tekton is modular by design. It ships as four independent, composable components that together cover the complete CI/CD lifecycle.
Tekton’s four-component architecture running inside a Kubernetes cluster. A Git push fires a webhook into Tekton Triggers, which creates a PipelineRun. The PipelineRun orchestrates Tasks (each a real Kubernetes Pod) through clone → build → scan/SBOM stages. Tekton Chains passively observes the results and automatically signs the image with SLSA provenance — all without a single change to your pipeline YAML.
Core Concepts: The Building Blocks of Tekton
Tasks and TaskRuns
A Task is the atomic unit of work in Tekton. Think of it as a job definition: it declares one or more ordered Steps, each running in a container image. A Task can accept parameters, produce results (small string values), and reference workspaces for file I/O. Every Step in a Task runs as a separate container in the same Kubernetes Pod, sharing a common filesystem.
A TaskRun is a single execution instance of a Task — the relationship between Task and TaskRun mirrors the relationship between a class and an object in object-oriented programming. When you run a Task, Tekton creates a Pod, runs your steps in sequence, and updates the TaskRun’s status with results and logs.
Pipelines and PipelineRuns
A Pipeline is a Directed Acyclic Graph (DAG) of Tasks. It declares which Tasks to run, in what order, and how data flows between them — specifically via Task Results. Tasks without explicit ordering dependencies run in parallel automatically, which Tekton uses to maximize throughput. A clone Task and a lint Task with no shared dependency? Tekton runs them simultaneously, shortening total pipeline time.
A PipelineRun instantiates a Pipeline with specific parameter values and workspace bindings. It creates the underlying TaskRuns and monitors their status, surfacing a unified view of the entire pipeline’s execution state.
Workspaces
Because each Task runs in a distinct Pod, they cannot directly share the local filesystem. Workspaces solve this by providing an abstraction over Kubernetes volume types. A Pipeline declares named workspace slots; a PipelineRun binds each slot to a concrete Kubernetes resource — most commonly a PersistentVolumeClaim (PVC) for source code, a Secret for credentials, or a ConfigMap for configuration. The classic pattern is a clone Task writing to a shared PVC workspace that all downstream Tasks then mount and read from.
Tekton Triggers
Tekton Triggers is the event-driven component of the ecosystem. It consists of three CRDs working in concert: an EventListener (a Kubernetes Service that receives HTTP webhook calls), a TriggerBinding (which extracts values from the webhook payload — repository URL, commit SHA, branch name), and a TriggerTemplate (which uses those extracted values to create a PipelineRun). When someone pushes code to GitHub, the webhook fires, the EventListener receives it, the TriggerBinding extracts the relevant fields, and the TriggerTemplate creates a PipelineRun — all automatically, all inside the cluster.
Tekton Chains
Tekton Chains is the supply chain security component. It operates as a passive observer: it watches for completed TaskRuns, reads specific result fields (conventionally named IMAGE_URL and IMAGE_DIGEST), and automatically generates two artifacts — a cryptographic signature of the container image using cosign, and a SLSA provenance attestation that documents exactly what was built, from what source, by what process, and at what time. Both are stored as OCI artifacts in the container registry alongside the image itself. No changes to your pipeline YAML are required — Chains works entirely as a side-effect of your existing TaskRuns.
Tekton Dashboard
The Tekton Dashboard is a browser-based UI that visualizes PipelineRuns and TaskRuns in real time. It shows the DAG of tasks, their execution status, live log streams, and result values. For teams familiar with CI platforms like Jenkins or CircleCI, the Dashboard provides a familiar visual interface while everything underneath remains pure Kubernetes-native.
Why Engineering Teams Choose Tekton
Everything Is Kubernetes
No new operational model to learn. Your existing Kubernetes expertise — RBAC, Namespaces, ResourceQuotas, NetworkPolicies, Secrets — applies directly to your CI/CD system. Platform teams that maintain the Kubernetes cluster also manage the CI/CD infrastructure, eliminating the organizational split between “ops who manages the cluster” and “DevOps who manages the CI tool.”
Infinite Horizontal Scalability
Tekton pipelines scale with your cluster. When a hundred pull requests land simultaneously, Tekton creates a hundred PipelineRuns, and Kubernetes schedules them across available nodes. There is no Jenkins controller bottleneck, no agent pool to pre-provision, no queue to manage manually. The Tekton controller is a lightweight Kubernetes controller — it consumes minimal resources and simply reacts to new CRD objects.
Immutable, Auditable Pipeline Definitions
Tekton pipelines are YAML — storable in Git, reviewable in pull requests, versioned, and auditable. More powerfully, Tasks can be referenced as OCI artifacts pinned by SHA256 digest, making the exact code used in a pipeline run cryptographically verifiable and immutable. This is the pattern used by Red Hat Konflux and enterprise CI platforms to guarantee pipeline integrity.
Native Supply Chain Security (SLSA Compliance)
The software supply chain attacks of recent years — SolarWinds, XZ Utils — demonstrated that the build pipeline itself can be a vector. Tekton Chains addresses this directly by generating SLSA provenance attestations for every build, automatically and without pipeline modifications. Organizations using Tekton can achieve SLSA Level 3 compliance out of the box, a capability that requires significant additional tooling with any other CI system.
Reusable Task Catalog
The Tekton community maintains a catalog of reusable Tasks for the most common CI operations: cloning repositories, building container images with Buildah, running Go tests, scanning with Trivy, generating SBOMs with Syft, pushing Helm charts, and much more. Teams can reference these catalog Tasks directly via HTTP or OCI resolvers without installing anything into the cluster — reducing duplication and standardizing on proven implementations.
Pipeline as Code
Tekton’s Pipeline as Code (PaC) feature allows teams to store their pipeline definitions in the .tekton/ directory of their application repository. This means every pipeline change is reviewed as a normal pull request alongside the code change that required it — bringing CI/CD configuration under the same governance as application code. PaC also handles webhook registration automatically when integrated with GitHub or GitLab.
Who Uses Tekton in Production?
OpenShift Pipelines (Red Hat’s enterprise Kubernetes distribution) ships Tekton as its first-class CI/CD primitive, available to all OpenShift clusters via the OperatorHub in a single click.
Red Hat Konflux is Red Hat’s internal developer platform that builds, signs, scans, and releases thousands of container images per day entirely on Tekton — Tasks, Triggers, Chains, and all.
Conclusion
Tekton represents a genuine architectural shift in how CI/CD is approached at the infrastructure level. By building on Kubernetes primitives rather than alongside them, Tekton eliminates the operational split between cluster management and pipeline management, inherits Kubernetes’ scalability and security model, and adds capabilities — like automatic SLSA provenance attestation — that no traditional CI tool can match without significant additional tooling.
For platform engineering teams, DevOps engineers, and organizations serious about software supply chain security, Tekton is not just an alternative to consider — it is increasingly the foundation that enterprise-grade CI/CD is being built upon. Whether you’re starting fresh or migrating from Jenkins, the investment in understanding Tekton’s primitives pays dividends across the entire lifecycle of every application you build and ship.
Ready to get hands-on? The complete field guide — with all YAMLs, installation steps, and worked examples — is waiting for you at github.com/ay-garg/tekton-field-guide. Clone the repository, spin up a local Kind or Minikube cluster, and run your first Task in under ten minutes.
Leave a Reply