CI/CD where every build is a Pod and every pipeline is an API object.
Tekton is an open-source framework for building CI/CD systems on Kubernetes. Each of the twelve parts here is a page of small working models. Watch the entrypoint run steps in order inside one Pod, schedule a DAG, overflow a result, pin a ReadWriteOnce volume to one node, send a forged webhook, or tamper with a signed image and see verification fail.
One commit going through the whole Tekton stack. Triggers turn the webhook into a PipelineRun, Pipelines runs the DAG of Tasks as Pods, and Chains signs what came out.
The Tekton controller notices the new PipelineRun. It resolves the Pipeline (from the cluster, git or an OCI bundle), validates it, builds the DAG and creates one TaskRun for each task that is ready.
Try: press ▶ git push, then switch to “tests fail” and replay. build-push and deploy are skipped, notify still runs because it is in finally, and Chains still attests the TaskRuns but has no image to sign. Click any box to see what it does.
There is no CI server. A Pipeline is a YAML object in etcd, a run is another object, and each task runs as a Pod that the cluster schedules, scales and isolates.
Steps make Tasks, Tasks make Pipelines, and each layer is parameterized and reusable. You can load them from git, OCI bundles or a catalog instead of copy-pasting.
Every run leaves structured records: results, status and logs. Chains turns those records into signed SLSA provenance, so a deploy can check where its image came from.
I · Building blocks
Tekton is a set of Kubernetes custom resources and the controllers that reconcile them. The smallest unit is a Step: a container. A Task is Steps in one Pod.
Tekton is not a CI server you run beside Kubernetes: it is a set of custom resources and controllers inside it, so builds are API objects, every run is a Pod, and the cluster's own machinery (etcd, admission, scheduling, garbage collection) does the work.
A Task is a list of steps that become containers in one Pod; they start together, but Tekton's injected entrypoint makes them run strictly one after another, sharing volumes and nothing else.
A TaskRun is one execution of a Task: the controller turns it into a single Pod, reports progress in one Succeeded condition, and enforces timeouts, retries, cancellation and debugging around that Pod.
II · Composing pipelines
Pipelines wire Tasks into a DAG. Params and results carry small data between them, workspaces carry files, and when, finally and matrix shape the flow.
A Pipeline is a graph of Tasks, and the PipelineRun controller is a scheduler: it creates each task's TaskRun the moment its parents finish, so the longest chain decides how long the run takes.
Params flow down as plain text substituted into specs before anything runs, and results flow back up through a tiny file-to-status channel; knowing both mechanisms tells you what fits, what breaks and what is unsafe.
Every TaskRun is its own Pod, so files only cross from one task to the next through a volume the PipelineRun binds: Tasks declare the slot, Pipelines wire it, runs pick the storage, and the storage choice decides what persists, what collides and which node things must run on.
A Pipeline is more than a DAG: when expressions, finally tasks, matrix fan-out, timeouts, retries and cancellation modes decide which tasks run, which are skipped and why, and the PipelineRun status records every one of those decisions.
III · Running safely
Which identity a run uses, where its definitions come from, and how you later prove what it built.
Every TaskRun is a Pod running as some ServiceAccount: its secrets decide what the steps can reach outside the cluster, its RBAC decides what they can do inside it, and the pod template decides where and how safely that Pod runs.
A taskRef or pipelineRef can name a resolver instead of an object in the cluster: the controller hands the fetch to a resolver through a ResolutionRequest, so Tasks can live in git, OCI bundles, a hub or another namespace. The cost is that what runs is only as fixed as the reference: pin to a commit SHA or digest, and verify signatures, if you want the same Task every time.
Tekton Chains watches finished runs and turns each one into a signed statement: these artifacts, with these digests, were built by this Task at this commit, with these inputs. A consumer can then verify that statement before deploying. It is only as strong as the type hints that name the artifacts, the key that signs, and the isolation of the cluster it runs in.
IV · Ecosystem
Turning webhooks into runs, and the tools for living with Tekton in production: tkn, the Dashboard, Results, the Operator and Pipelines-as-Code.
Tekton Triggers turns an HTTP event into Kubernetes objects. An EventListener receives the webhook, a chain of interceptors decides whether it counts, a TriggerBinding pulls fields out of it, and a TriggerTemplate stamps out a PipelineRun.
Running Tekton day to day means treating runs as data with a lifecycle: start and inspect them with tkn and the Dashboard, archive them to Tekton Results, prune them out of etcd, let the Operator and Pipelines-as-Code manage installs and triggers, and watch the controller's metrics and knobs as load grows.
Every Tekton term and field from every part, in plain language, linked to its visualization.
An independent learning aid, not affiliated with the Tekton project, the Continuous Delivery Foundation or the Linux Foundation. Explanations are paraphrased and simplified, and the simulations are models, not Tekton itself. The authoritative reference is the official documentation at tekton.dev/docs. Source code on GitHub.