What are Tasks and TaskRuns in Tekton?

Think of a Task as a recipe card in a kitchen and a TaskRun as actually cooking that recipe. The recipe card lists the ingredients (inputs), the steps to follow (build, test, push), and the final dish (outputs). You can cook the same recipe multiple times with different ingredients, and each cooking session is a separate TaskRun that runs independently.

A Tekton Task is a Kubernetes Custom Resource that defines a sequence of steps to perform a specific unit of work. Each Task YAML manifest specifies an apiVersion (tekton.dev/v1), a kind (Task), metadata including the name, and a spec containing the list of steps. Each step specifies a container image and a script or command to run. Steps execute sequentially within a single pod, sharing the same network namespace and, optionally, the same volumes. For example, the inventory-sync team might define a Task called build-and-test that has three steps: one to install dependencies using a Node.js image, one to run unit tests, and one to run linting. Since all three steps run in the same pod, they share the workspace filesystem, so the dependencies installed in step one are available in step two without any special configuration.

Under the hood, when you create a TaskRun, the Tekton controller translates the Task definition into a Kubernetes pod specification. Each step becomes an init container or a regular container within that pod, and Tekton uses an internal entrypoint binary to enforce sequential execution. The TaskRun resource tracks the status of each step, recording start times, completion times, exit codes, and logs. If any step fails (returns a non-zero exit code), subsequent steps are skipped and the TaskRun is marked as failed. You can view the status of a TaskRun using kubectl get taskrun or the tkn CLI tool. The payments-api team, for instance, can run tkn taskrun logs build-and-test-run-7xk2m to stream the logs from a specific TaskRun and debug a failing test step.

In production workflows, Tasks are designed to be reusable building blocks. A Task like build-docker-image can accept parameters for the image name, tag, and Dockerfile path, allowing the user-auth-service, checkout-service, and order-processing-service teams to all use the same Task with different parameter values. The Tekton Hub (hub.tekton.dev) provides a catalog of community-maintained Tasks for common operations like building with Kaniko, pushing to registries, deploying with kubectl, and running security scans. Teams install these Tasks into their cluster and reference them in Pipelines, avoiding the need to write everything from scratch.

A common beginner mistake is confusing Tasks with Pipelines. A Task is a single unit of work executed in one pod, while a Pipeline orchestrates multiple Tasks across multiple pods. Another gotcha is that steps within a Task always run sequentially and cannot be parallelized. If you need parallel execution, you must use separate Tasks within a Pipeline and configure them to run concurrently. Also, remember that a TaskRun is immutable once created: you cannot update a running TaskRun, you must cancel it and create a new one. This immutability is a deliberate design choice that ensures reproducibility and auditability of every pipeline execution.