Kubernetes-native CI/CD

A Kubernetes object that adds a new resource type, such as Task or PipelineRun, to the API server.

Because Tekton's types are CRDs, kubectl, RBAC, namespaces, labels, watches and GitOps tools all work on pipelines exactly as they do on Deployments. There is no separate Tekton API or database.

An instance of a CRD: one Task, one PipelineRun, stored in etcd like any other object.

Definitions (Task, Pipeline) and executions (TaskRun, PipelineRun) are separate objects. You keep the first in Git and create the second each time something should run.

A Task is a reusable list of steps; a TaskRun is one execution of it, with concrete params and workspaces.

Splitting what from when means a Task can be shared, versioned and reviewed, while each TaskRun records exactly what ran and how it ended.

A Pipeline arranges Tasks into a graph; a PipelineRun executes it by creating one TaskRun per pipeline task.

The PipelineRun owns its TaskRuns, which own their Pods, so one object represents the whole run and deleting it cleans up everything beneath.

metadata.ownerReferences on a child object pointing at the object that created it: Pod → TaskRun → PipelineRun.

Kubernetes' garbage collector follows these links. A taskRef by name is not ownership: deleting a Task leaves its past runs alone.

When an owner is deleted the garbage collector deletes its dependents, in background (default), foreground, or not at all (orphan).

Pruning old PipelineRuns is enough to reclaim their TaskRuns and Pods. Run history therefore lives in etcd only until you prune it, which is why Tekton Results exists.

A long-running process that watches resources through informers and works to make the actual state match the declared one.

Tekton's tekton-pipelines-controller is the only Tekton process on the run path. It does not execute builds; it creates Pods and lets the kubelet run them.

The function reconcile(key) called for each queued object: read the spec and the current world, act, update status.

Changes are coalesced into a workqueue of keys, so ten Pod updates in a burst can mean a single reconcile. The reconciler never assumes it saw every event.

Acting on the current state (the level) rather than on the sequence of changes (the edges).

If the controller crashes or misses events, a fresh LIST and one reconcile per object are enough to catch up. Edge-triggered logic that counts events stays wrong forever after a miss.

status.conditions on every run; Tekton's key condition is type Succeeded with status Unknown, True or False and a reason.

Unknown means still going (reason Pending, Running…); True and False are final (Succeeded, Failed, TaskRunTimeout, Cancelled…). Every tool, from tkn to Dashboard, reads this one field.

An HTTPS hook the API server calls before storing an object: mutating (defaulting) first, then validating.

Tekton's webhook rejects bad YAML (missing image, unknown variable, gated field) when you apply it, not minutes later when a Pod fails. It also fills defaults such as timeout and serviceAccountName.

A ConfigMap in tekton-pipelines holding cluster-wide defaults applied by the defaulting webhook.

default-timeout-minutes (60) and default-service-account (default) are why a TaskRun you never gave a timeout still has one.

The ConfigMap that switches Tekton behaviours and API fields on or off for the whole installation.

It controls stability gates and runtime choices such as await-sidecar-readiness, results-from and coschedule. Two clusters with different flags can accept different YAML.

The flag that sets which API fields the webhook accepts: stable, beta (the shipped default) or alpha.

Alpha fields may change or disappear; beta fields follow a gentler policy; stable fields are covered by the v1 compatibility promise. Gating them per cluster keeps production on a known surface.

The stable API version for Task, TaskRun, Pipeline and PipelineRun; v1beta1 is still served and converted by the webhook.

v1 dropped PipelineResources and renamed some fields (a step's resources became computeResources). Writing v1 YAML is what makes it portable across conformant clusters.

Where the Pipelines controller, webhook, resolvers and their ConfigMaps run.

Tekton is installed with one kubectl apply of release.yaml (or by the Operator); nothing runs outside the cluster.

Every TaskRun executes as one ordinary Pod that the Kubernetes scheduler places on a node.

There are no long-lived build agents to size, patch or keep warm: capacity is the cluster's, it bin-packs by resource request, and it scales with the node pool.

Pipelines (core), Triggers, Chains, Results, Dashboard, CLI (tkn), Operator, the catalog/Hub, and Pipelines-as-Code.

Each one is more CRDs and controllers on the same API server. You can adopt Pipelines alone and add the others as you need them.

The Linux Foundation project that hosts Tekton, alongside Jenkins, Spinnaker and others.

Vendor-neutral governance is why Tekton serves as the engine under several products (OpenShift Pipelines and Jenkins X among them) and why its API is meant as a common standard.