In the previous article, we introduced Tekton's 7 components and 5 resource objects. Now let's go deeper: how does Tekton's execution model actually work? Understanding this is essential before you write your first real pipeline.
1. Step, Task, and Pipeline — The Three Layers
Tekton's execution model is built around three nested layers. Each layer has a clear responsibility.
Step — The Atomic Unit
A Step is the smallest unit of work in a Tekton pipeline. Each Step runs inside a container defined by a specific image. Steps are where the actual work happens:
- Compile source code
- Run unit tests
- Build a container image
- Push to an image registry
- Deploy to a Kubernetes cluster
Every implementation detail lives at the Step level.
Task — A Pod of Steps
A Task is an ordered collection of Steps. Tekton runs each Task as a Kubernetes Pod, where every Step in that Task becomes a container inside that Pod.
This design has an important implication: Steps within the same Task share Pod-level resources — including mounted volumes, environment variables, and network namespace. This makes intra-Task data sharing straightforward.
Task (runs as 1 Pod)
├── Step 1: git-clone → Container 1
├── Step 2: run-tests → Container 2
└── Step 3: build-image → Container 3
↕ shared volume (Pod-level)
Pipeline — An Orchestration of Tasks
A Pipeline is an ordered collection of Tasks. Each Task in a Pipeline runs as its own independent Pod on the cluster.
By default, Tasks in a Pipeline run concurrently. When you need sequential execution — because Task B depends on Task A's output — you use ordering controls to define dependencies explicitly.
Example execution flow:
Pipeline
│
├── Task A ──────────────────────────────► runs first
│ ↓ (on completion)
├── Task B ──┐
│ ├─► run concurrently
├── Task C ──┘
│ ↓ (both complete)
└── Task D ──────────────────────────────► runs last
Within each Task, Steps always execute in the order they are defined. If you need to reorder Steps, you must edit the Task definition itself.
Pipeline also provides higher-level orchestration features:
- Task retry — automatically retry a failed Task
-
Ordering control — define
runAfterdependencies between Tasks - Conditional execution — run Tasks only when certain conditions are met
2. Input and Output Resources
Every Task and Pipeline may have its own inputs and outputs — referred to in Tekton as Input and Output Resources.
Example: A Task that compiles code and builds a container image might define:
- Input: a Git repository (source code)
- Output: a container image (pushed to a registry)
Git Repo (Input)
↓
┌─────────────────────────────┐
│ Task │
│ ├── Step: clone repo │
│ ├── Step: run tests │
│ └── Step: build & push │
└─────────────────────────────┘
↓
Container Image (Output)
Supported Resource Types
| Resource Type | Description |
|---|---|
| Git | A Git repository |
| Pull Request | A specific PR in a Git repository |
| Image | A container image |
| Cluster | Access to a Kubernetes cluster outside the current one |
| Storage | An object or directory in blob storage (e.g. GCS) |
| CloudEvent | An event payload conforming to the CloudEvents spec |
⚠️ Note: PipelineResource (including these resource types) is considered legacy in Tekton v0.44+. The recommended modern approach is to use Workspaces for shared storage and Results for passing data between Tasks.
3. TaskRun and PipelineRun — Instantiating Execution
Defining a Task or Pipeline is like writing a class definition — nothing runs until you instantiate it. That's what TaskRun and PipelineRun are for.
TaskRun
Instantiates and executes a Task on the cluster with specific inputs, outputs, and parameters. You can run a TaskRun independently (outside of any Pipeline) and inspect the execution details of each Step individually.
PipelineRun
Instantiates and executes a Pipeline on the cluster. Through a PipelineRun, you can track the status of every Task in the Pipeline, including per-Task logs and execution details.
The relationship:
Task ──────────── instantiated by ──────────► TaskRun
Pipeline ──────── instantiated by ──────────► PipelineRun
TaskRun and PipelineRun are what connect resources to Tasks and Pipelines, completing a full CI/CD workflow execution.
Ways to Create a TaskRun or PipelineRun
| Method | Description |
|---|---|
| Manual (kubectl/tkn) | Apply a YAML manifest or use tkn pipeline start
|
| Tekton Dashboard | Create and trigger runs via the web UI |
| Tekton Triggers | Automatically triggered by Git events (e.g. PR merge) |
4. How Tekton Actually Executes — Under the Hood
This is where Tekton gets interesting. Here's what actually happens when a Task runs.
The Entrypoint Injection Mechanism
Tekton Pipeline's core job is to wrap each Step's execution to enforce ordering. Here's how:
- Tekton injects a binary called the entrypoint into each Step container
- This entrypoint acts as a wrapper — it waits for a signal before executing the Step's actual command
- Signals are communicated via Kubernetes annotations, projected into each container as files using the Kubernetes Downward API
Sequential Step execution example:
Step 1 container starts
↓ executes command
↓ writes "completed" annotation
Step 2 container starts (entrypoint is waiting)
↓ detects Step 1 annotation → starts executing
↓ writes "completed" annotation
Step 3 container starts (entrypoint is waiting)
↓ detects Step 2 annotation → starts executing
This mechanism ensures strict sequential execution within a Task, even though all Step containers are technically started simultaneously as part of the same Pod.
Pre/Post Step Containers
Tekton also automatically schedules sidecar containers that run before and after your Step containers to support built-in functionality:
- Before Steps: retrieve input resources, set up environment, mount workspaces
- After Steps: upload output resources, write results to storage
These are transparent to the user — you don't define them, Tekton manages them automatically. You can observe them in the TaskRun status if needed.
5. The Full Execution Model — Visualized
PipelineRun
│
├── TaskRun A → Pod A
│ ├── init containers (setup)
│ ├── Step 1 container (entrypoint waits → executes → signals)
│ ├── Step 2 container (entrypoint waits → executes → signals)
│ └── Step 3 container (entrypoint waits → executes)
│
├── TaskRun B → Pod B (starts after Pod A completes)
│ └── Steps...
│
└── TaskRun C → Pod C (starts after Pod A completes, concurrent with B)
└── Steps...
Every layer is a Kubernetes primitive — Pods, containers, annotations, volumes. Tekton doesn't abstract away Kubernetes; it builds directly on top of it.
6. Summary
| Concept | Kubernetes Equivalent | Role |
|---|---|---|
| Step | Container | Atomic unit of work |
| Task | Pod | Ordered collection of Steps |
| Pipeline | Multi-Pod workflow | Ordered collection of Tasks |
| TaskRun | Pod instance | Executes a Task with specific params |
| PipelineRun | Workflow instance | Executes a Pipeline end-to-end |
| Entrypoint binary | Init mechanism | Enforces Step ordering within a Pod |
Tekton's genius is that it maps cleanly onto Kubernetes primitives. Once you understand that Steps = containers, Tasks = Pods, and ordering = annotation-based signaling, the entire execution model clicks into place.
Next in this series: Tekton in Practice: CI/CD Configuration for a Real Application (Part 6)
Follow the series — next up we build a real Tekton CI pipeline from scratch, covering Task definitions, Pipeline assembly, and Trigger configuration.
Top comments (0)