Understanding Tekton: A Comprehensive CI/CD Framework for Kubernetes

Tekton is a cloud-native CI/CD framework built for Kubernetes. Here’s a full breakdown:

What it is

Tekton is a Kubernetes-native open source framework for creating continuous integration and continuous delivery (CI/CD) systems. It installs and runs as an extension on a Kubernetes cluster and comprises a set of Kubernetes Custom Resources that define the building blocks you can create and reuse for your pipelines.

Tekton standardizes CI/CD tooling and processes across vendors, languages, and deployment environments. It lets you create CI/CD systems quickly, giving you scalable, serverless, cloud-native execution out of the box.

Core building blocks

Everything in Tekton is composed of these layers:

Step — the most basic entity, such as running unit tests or compiling a program. Tekton performs each step with a provided container image.
Task — a collection of steps in a specific order. Tekton runs a task in the form of a Kubernetes pod, where each step becomes a running container in the pod.
Pipeline — a collection of tasks in a specific order. Tekton collects all tasks, connects them in a directed acyclic graph (DAG), and executes the graph in sequence.
TaskRun — a specific execution of a task.
PipelineRun — a specific execution of a pipeline.

Example pipeline (clone → build → deploy)

			
# Step 1: Define a Task
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-and-push
spec:
  params:
    - name: IMAGE
      type: string
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:latest
      args:
        - --destination=$(params.IMAGE)
        - --context=/workspace/source
---
# Step 2: Compose Tasks into a Pipeline
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci-pipeline
spec:
  tasks:
    - name: clone
      taskRef:
        name: git-clone        # from Tekton Catalog
    - name: build
      runAfter: [clone]
      taskRef:
        name: build-and-push
    - name: deploy
      runAfter: [build]
      taskRef:
        name: kubectl-apply
---
# Step 3: Trigger a run
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: ci-pipeline-run-001
spec:
  pipelineRef:
    name: ci-pipeline

		

Major components

The Tekton ecosystem includes:

Pipelines — the core CRDs (Task, Pipeline, etc.)
Triggers — allows you to create pipelines based on event payloads, such as triggering a run every time a merge request is opened against a Git repo
CLI (tkn) — command-line interface to interact with Tekton from your terminal
Dashboard — a web-based graphical interface showing pipeline execution history
Catalog — a repository of high-quality, community-contributed reusable Tasks and Pipelines
Chains — manages supply chain security, including artifact signing and SLSA provenance

Key advantages

Truly Kubernetes-native — every pipeline run is a real Kubernetes pod; no external CI server needed
Reusable and composable — Tasks from the Tekton Hub can be dropped into any pipeline
Event-driven — Triggers fire pipelines automatically on Git webhooks, image pushes, etc.
Scalable — each step runs in its own container; pipelines scale with the cluster
Supply chain security — Tekton Chains can sign images and generate SLSA provenance automatically

Tekton on OpenShift

Red Hat ships Tekton as OpenShift Pipelines — the officially supported Tekton operator available directly from OperatorHub. It adds OCP-specific integrations like integration with the OpenShift internal image registry, S2I (Source-to-Image) tasks, and the OpenShift console Pipeline UI. Tekton is the basis for OpenShift Pipelines, making it the natural CI tool to pair with Argo CD or Flux for a full GitOps workflow on OCP (Tekton handles CI/build, Argo CD or Flux handles CD/deploy).

Here’s the full picture of how Tekton (CI) and Argo CD / Flux (CD) work together on OCP — first the architecture flow, then a complete reference guide.Now here’s the full practical reference — everything you need to wire it up on OCP.

How the two halves divide responsibility

When code changes are pushed to a Git repository, OpenShift Pipelines initiates a pipeline run. This pipeline might include tasks such as building container images, running unit tests, and generating artifacts. Once the pipeline successfully completes, Argo CD continuously monitors the Git repository for changes in application manifests. Once the new image version is committed, Argo CD synchronizes the application state to match the declared state in Git.

The key insight is that Tekton owns the source repo (code → image) and Argo CD / Flux owns the config repo (manifests → cluster). Tekton never deploys directly. It commits the new image tag to a separate GitOps manifests repo, then hands off.

Step 1 — Install both operators on OCP

			
# OpenShift Pipelines (Tekton) — via OperatorHub
# Operators → OperatorHub → "Red Hat OpenShift Pipelines" → Install
# OpenShift GitOps (Argo CD) — via OperatorHub
# Operators → OperatorHub → "Red Hat OpenShift GitOps" → Install
# Verify both are running
oc get pods -n openshift-pipelines
oc get pods -n openshift-gitops

		

Step 2 — The Tekton CI pipeline

On every push or pull-request to the source Git repository, the following steps execute within the Tekton pipeline: code is cloned and unit tests are run; the application is analyzed by SonarQube in parallel; a container image is built using S2I and pushed to the OpenShift internal registry; then Kubernetes manifests are updated in the Git repository with the image digest that was built within the pipeline.

			
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci-pipeline
  namespace: cicd
spec:
  workspaces:
    - name: source
    - name: dockerconfig
  params:
    - name: GIT_URL
      type: string
    - name: IMAGE
      type: string
    - name: GIT_MANIFEST_URL   # separate repo for k8s manifests
      type: string
  tasks:
    - name: clone
      taskRef:
        name: git-clone
        kind: ClusterTask
      workspaces:
        - name: output
          workspace: source
      params:
        - name: url
          value: $(params.GIT_URL)
    - name: unit-test
      runAfter: [clone]
      taskRef:
        name: maven
        kind: ClusterTask
      workspaces:
        - name: source
          workspace: source
    - name: build-image
      runAfter: [unit-test]
      taskRef:
        name: buildah
        kind: ClusterTask
      params:
        - name: IMAGE
          value: $(params.IMAGE)
      workspaces:
        - name: source
          workspace: source
        - name: dockerconfig
          workspace: dockerconfig
    - name: scan-image
      runAfter: [build-image]
      taskRef:
        name: trivy-scanner      # from Tekton Hub
      params:
        - name: IMAGE
          value: $(params.IMAGE)
    - name: update-manifest      # THE HANDOFF to GitOps
      runAfter: [scan-image]
      taskRef:
        name: git-cli
        kind: ClusterTask
      params:
        - name: GIT_USER_NAME
          value: tekton-bot
        - name: COMMANDS
          value: |
            git clone $(params.GIT_MANIFEST_URL) /workspace/manifest
            cd /workspace/manifest
            # Update image tag in kustomization
            kustomize edit set image myapp=$(params.IMAGE)
            git add -A
            git commit -m "ci: update image to $(params.IMAGE)"
            git push

		

Step 3 — Tekton Triggers (webhook → pipeline)

			
# EventListener — receives the GitHub/GitLab webhook
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: git-push-listener
  namespace: cicd
spec:
  serviceAccountName: pipeline
  triggers:
    - name: push-trigger
      bindings:
        - ref: github-push-binding
      template:
        ref: pipeline-trigger-template
---
# TriggerTemplate — what to create when the webhook fires
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: pipeline-trigger-template
  namespace: cicd
spec:
  params:
    - name: git-revision
    - name: git-repo-url
  resourcetemplates:
    - apiVersion: tekton.dev/v1
      kind: PipelineRun
      metadata:
        generateName: ci-run-
      spec:
        pipelineRef:
          name: ci-pipeline
        params:
          - name: GIT_URL
            value: $(tt.params.git-repo-url)
          - name: IMAGE
            value: image-registry.openshift-image-registry.svc:5000/myapp/app:$(tt.params.git-revision)

		

Expose the EventListener as an OCP Route so GitHub/GitLab can reach it:

			
oc expose svc el-git-push-listener -n cicd
# Then add the route URL as a webhook in GitHub/GitLab

Step 4 — Argo CD watches and deploys

Once the manifests repo is updated by Tekton, Argo CD detects the change. With automated.prune: true and selfHeal: true, it syncs immediately and deploys the new revision.

			
# Argo CD Application — dev environment
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-dev
  namespace: openshift-gitops
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/manifests.git
    targetRevision: main
    path: environments/dev          # Kustomize overlay for dev
  destination:
    server: https://kubernetes.default.svc
    namespace: myapp-dev
  syncPolicy:
    automated:
      prune: true       # remove resources deleted from Git
      selfHeal: true    # revert manual changes to the cluster
    syncOptions:
      - CreateNamespace=true
---
# Promotion to staging requires a PR merge (no auto-deploy to prod)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-staging
  namespace: openshift-gitops
spec:
  source:
    path: environments/staging
    targetRevision: staging         # separate branch = manual promotion
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

		

The GitOps repo layout Tekton writes to

			
manifests-repo/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── environments/
    ├── dev/
    │   └── kustomization.yaml     ← Tekton updates image tag here
    ├── staging/
    │   └── kustomization.yaml     ← promoted via PR merge
    └── prod/
        └── kustomization.yaml     ← promoted via PR merge + approval

		

Promotion flow (dev → staging → prod)

Once the pipeline finishes successfully, the image reference in the manifests repo is updated and automatically deployed to the dev environment by Argo CD. To promote to staging, a pull request is generated targeting the staging branch. Merging that PR triggers Argo CD to sync the staging environment. Production follows the same pattern with an additional approval gate.

The promotion task in Tekton creates a PR automatically:

			
- name: promote-to-staging
  runAfter: [update-manifest]
  taskRef:
    name: github-open-pr       # from Tekton Hub
  params:
    - name: REPO_FULL_NAME
      value: my-org/manifests
    - name: HEAD
      value: feature/new-image-$(params.git-revision)
    - name: BASE
      value: staging
    - name: TITLE
      value: "Promote $(params.IMAGE) to staging"

		

Putting it all together — the complete flow

Step	Actor	Action
1	Developer	`git push` to source repo
2	GitHub/GitLab	Sends webhook to Tekton EventListener
3	Tekton	Clones, tests, builds image with Buildah/S2I
4	Tekton	Scans image with Trivy / ACS
5	Tekton	Pushes image to OCP internal registry or Quay
6	Tekton	Updates image tag in manifests repo, opens PR to staging
7	Argo CD / Flux	Detects change in manifests repo, deploys to dev automatically
8	Team	Reviews and merges PR → staging auto-deploys
9	Team	Approves prod PR → production deploys

This pattern — Tekton handles CI, Argo CD / Flux handles CD, and Git is the only bridge between them — is the standard GitOps delivery model on OCP.

Infra Cloud Solutions

Leave a comment Cancel reply