In the previous articles, we established why GitOps is the right delivery model for cloud-native environments. Now it's time to look at the tools that make it work. We'll start with Tekton — the Kubernetes-native CI engine that powers the build side of a GitOps pipeline.
1. What is Tekton?
Tekton is an open-source framework for building CI/CD pipelines directly on Kubernetes. Unlike traditional CI tools that run alongside your cluster, Tekton runs inside it — using Kubernetes CRDs (Custom Resource Definitions) as its native building blocks.
This means your pipelines are:
- Defined as Kubernetes resources (YAML)
- Executed as Kubernetes Pods
- Managed with standard Kubernetes tooling
Tekton is made up of 7 components. Let's walk through each one.
2. The 7 Tekton Components
2.1 Tekton Pipeline (Core)
The foundational component. It defines a set of Kubernetes CRDs that serve as the building blocks for assembling CI/CD pipelines. Everything else in Tekton is built on top of this.
2.2 Tekton Triggers
Enables event-driven pipeline instantiation. For example:
- Trigger a pipeline when a PR is merged in GitHub
- Build a custom UI that fires specific Tekton triggers on demand
Triggers are what connect your Git events to your pipeline execution.
2.3 Tekton CLI (tkn)
A command-line interface for interacting with Tekton. Use tkn to start pipeline runs, inspect logs, list tasks, and manage resources — all from your terminal.
# Example: list all pipeline runs
tkn pipelinerun list
# Example: stream logs from a pipeline run
tkn pipelinerun logs my-pipeline-run -f
2.4 Tekton Dashboard
A web-based UI for visualizing pipeline execution status. Useful for teams that prefer a graphical view of their CI/CD runs without diving into kubectl or tkn.
2.5 Tekton Catalog
A community-maintained repository of high-quality, reusable Tasks and Pipelines. Instead of writing everything from scratch, you can pull pre-built building blocks directly into your pipeline:
-
git-clone— clone a repository -
docker-build— build and push a Docker image -
create-gitlab-release— create a GitLab release
Think of it as npm for Tekton Tasks. Need docker-build? Don't write it yourself — grab it from the Catalog and customize as needed.
2.6 Tekton Hub
The web UI for browsing Tekton Catalog. Search, preview, and copy Tasks and Pipelines from the community at hub.tekton.dev.
2.7 Tekton Operator
A Kubernetes Operator for managing the Tekton installation itself. Use it to:
- Install Tekton on a new cluster
- Upgrade Tekton components
- Remove Tekton cleanly
No manual YAML management required for cluster-level Tekton lifecycle.
3. The 5 Core Tekton Resource Objects
Tekton introduces five key resource objects. Understanding how they relate to each other is essential before writing your first pipeline.
3.1 Task
A Task is an ordered collection of Steps. Each Step invokes a specific build tool with defined inputs and produces defined outputs.
Task
├── Step 1: git-clone
├── Step 2: run-tests
└── Step 3: build-image
Each Task runs in its own Kubernetes Pod, with its own isolated storage. Tasks are the atomic unit of work in Tekton.
3.2 Pipeline
A Pipeline is an ordered collection of Tasks. It defines the full CI/CD workflow — from code checkout to deployment.
Pipeline
├── Task 1: lint & static analysis
├── Task 2: unit tests
├── Task 3: build & push image
└── Task 4: deploy to cluster
Pipelines can be triggered by events (via Tekton Triggers) or invoked directly via a PipelineRun.
3.3 TaskRun
A TaskRun instantiates a Task with specific inputs, outputs, and execution parameters.
If a Task defines what to do, a TaskRun defines with what parameters to do it.
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
name: build-image-run
spec:
taskRef:
name: docker-build
params:
- name: IMAGE
value: myrepo/myapp:v1.0
3.4 PipelineRun
A PipelineRun instantiates a Pipeline with a specific set of inputs and executes it end-to-end, producing outputs to defined targets.
Same relationship as TaskRun → Task, but at the Pipeline level.
3.5 PipelineResource (Legacy)
Defines the input and output locations for Steps within a Task — for example, a Git repository as input, or a container image registry as output.
⚠️ Note: PipelineResource is considered legacy in newer Tekton versions. The community recommends using Workspaces and Results instead for data passing between Tasks.
4. How Tasks and Pipelines Work Together
Since each Task runs in its own isolated Pod, Tasks do not share data by default. To pass data between Tasks, you must explicitly configure:
- The output of Task A to be stored somewhere accessible
- The input of Task B to read from that location
This is typically done via Workspaces (shared PersistentVolumeClaims).
Task A (Pod 1) Task B (Pod 2)
├── Step: build → ├── Step: test
└── output: /workspace └── input: /workspace
↕ shared PVC ↕
5. Task vs Pipeline — When to Use Which
| Scenario | Use | Reason |
|---|---|---|
| Run unit tests | Task | Single, isolated operation |
| Run a linter | Task | Simple, self-contained |
| Build a Kaniko cache | Task | Independent build step |
| Full CI pipeline (lint → test → build → deploy) | Pipeline | Multi-step, sequential workflow |
| Static analysis + integration tests + release | Pipeline | Complex, multi-Task orchestration |
Rule of thumb: If it's one thing, use a Task. If it's a workflow, use a Pipeline.
6. Summary
| Component / Resource | Role |
|---|---|
| Tekton Pipeline | Core CRD framework |
| Tekton Triggers | Event-driven pipeline execution |
| Tekton CLI (tkn) | Terminal interface |
| Tekton Dashboard | Web UI for pipeline visibility |
| Tekton Catalog | Reusable community Tasks & Pipelines |
| Tekton Hub | Web UI for browsing the Catalog |
| Tekton Operator | Cluster-level Tekton lifecycle management |
| Task | Atomic unit of work (runs in a Pod) |
| Pipeline | Ordered collection of Tasks |
| TaskRun | Task instance with specific parameters |
| PipelineRun | Pipeline instance with specific parameters |
| PipelineResource | I/O location definitions (legacy) |
Tekton gives you a fully Kubernetes-native CI foundation. In the next article, we'll go deeper into the Tekton concept model — how Steps, Tasks, and Pipelines compose into a coherent execution model.
Next in this series: Tekton Concept Model: Steps, Tasks, and Pipelines Explained (Part 5)
Follow the series — we'll be covering Tekton CI/CD configuration in practice and Argo CD in upcoming articles.
Top comments (0)