Tekton is a CI/CD framework that runs entirely on Kubernetes, where every pipeline step is a container in a pod and every pipeline object is a custom resource you apply with kubectl. There is no separate build server: the cluster is the build system. A step's container is the build environment, the cluster scheduler places the work, and pod isolation gives each run a clean sandbox. For teams already running workloads on Kubernetes, Tekton removes the second control plane a traditional CI server would add and lets pipelines inherit the cluster's RBAC, autoscaling, and node pools.

Tasks, Steps, and Pipelines

Tekton's building blocks are Kubernetes custom resources. A Step is one container running one command. A Task is an ordered list of Steps that share a pod and a workspace. A Pipeline wires Tasks together with ordering and data dependencies. Because they are CRDs, they live in Git and are applied like any other manifest.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: dbt-build
spec:
  workspaces:
    - name: source
  params:
    - name: target
      default: "ci"
  steps:
    - name: deps
      image: ghcr.io/dbt-labs/dbt-bigquery:1.7
      workingDir: $(workspaces.source.path)
      script: |
        dbt deps
    - name: build
      image: ghcr.io/dbt-labs/dbt-bigquery:1.7
      workingDir: $(workspaces.source.path)
      script: |
        dbt build --target $(params.target) --fail-fast

Both Steps run in the same pod and share the source workspace, so dbt deps populates the package directory that dbt build then reads - no artifact upload between them.

Pipelines, workspaces, and triggers

A Pipeline declares Tasks and the order they run via runAfter, passing data through shared workspaces backed by a persistent volume claim. Triggers (an EventListener plus TriggerBindings) turn an inbound webhook - a Git push, a merge - into a PipelineRun, the runtime object that instantiates a pipeline with concrete parameters.

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: data-pipeline
spec:
  workspaces:
    - name: shared
  tasks:
    - name: fetch
      taskRef: { name: git-clone }
      workspaces:
        - { name: output, workspace: shared }
    - name: transform
      runAfter: ["fetch"]
      taskRef: { name: dbt-build }
      workspaces:
        - { name: source, workspace: shared }

The runAfter: ["fetch"] edge forces ordering; without it Tekton runs independent Tasks in parallel. The shared workspace is the only thing carrying state between the clone and the transform.

Where Tekton fits

Tekton suits teams whose deploy target is already Kubernetes and who want the pipeline to run with the same RBAC, secrets, and scaling as the apps. The cost is that you assemble the system yourself - Tekton is a set of primitives, not a finished product, so dashboards, notifications, and approvals come from add-ons or a layer like a vendor CD product on top. It pairs naturally with a GitOps deployer such as Argo CD for the deploy half, while Tekton owns build and test. For hosted alternatives that need no cluster, see CircleCI and the broader infrastructure-as-code and deployment hub.

Frequently asked questions

Do Steps in a Task share state? Yes. All Steps in one Task run in a single pod and can share an attached workspace and the pod's emptyDir, so files written by one Step are visible to the next. Steps in different Tasks share data only through a workspace backed by a persistent volume.

Task vs Pipeline vs PipelineRun? A Task is a reusable unit of Steps. A Pipeline composes Tasks with ordering and shared workspaces. A PipelineRun is the actual execution - it binds a Pipeline to real parameter values, workspaces, and a service account, and it's the object whose status you watch.

How does Tekton get triggered by a commit? Through Tekton Triggers: an EventListener exposes a webhook endpoint, a TriggerBinding extracts fields from the payload (branch, commit SHA), and a TriggerTemplate creates a PipelineRun from them. Point your Git provider's webhook at the EventListener's service.

Does Tekton replace Jenkins? For Kubernetes-native teams it can. It gives no build server to patch and inherits cluster scaling, but you build the surrounding experience (UI, approvals, notifications) from add-ons rather than getting it out of the box the way a mature Jenkins install provides.