LearnwithVishnu
Basics → Production → Architect
← Home
⚙️Tekton
BeginnerEngineerArchitectKubernetes-native CI/CD — Tasks, Pipelines, Workspaces, Triggers, OpenShift Pipelines
What is TektonTasks & PipelinesTriggersOpenShift PipelinesQ&A

⚙️ What is Tekton?

What is Tekton?

Tekton is a Kubernetes-native CI/CD framework. Every pipeline, task, and run is a Kubernetes Custom Resource — you create them with kubectl apply, inspect them with kubectl get, and they run as Kubernetes Pods inside your cluster.

Tekton is the foundation of OpenShift Pipelines — Red Hat's enterprise CI/CD product is Tekton with additional OpenShift integration and a pre-installed set of ClusterTasks.

Why Tekton over Jenkins or GitHub Actions?

TektonJenkinsGitHub Actions
RunsInside your K8s clusterExternal serverGitHub SaaS (or self-hosted)
CredentialsK8s Secrets — same as appsSeparate Jenkins storeGitHub Secrets / Vars
ScalingK8s schedules task pods automaticallyConfigure agents manuallyGitHub manages runners
OpenShift nativeYes — OpenShift Pipelines IS TektonPlugin onlySelf-hosted runners needed
RBACK8s RBAC — same model as workloadsSeparate Jenkins RBACGitHub org permissions

Core concepts

ObjectWhat it isRuns as
StepA single container command — the smallest unitContainer inside a Pod
TaskOrdered sequence of Steps with shared workspaceKubernetes Pod
PipelineOrdered sequence of Tasks with params and workspacesOrchestrates multiple Pods
TaskRunOne execution instance of a TaskPod (created per run)
PipelineRunOne execution instance of a PipelineMultiple Pods sequentially
WorkspaceShared storage between Tasks in a PipelineVolume mounted per Pod

🧱 Tasks and Pipelines

Complete Task and Pipeline example

# Task — build and push a Docker image using Kaniko
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: docker-build-push
spec:
  params:
  - name: IMAGE
  - name: TAG
    default: "latest"
  workspaces:
  - name: source
  steps:
  - name: build-and-push
    image: gcr.io/kaniko-project/executor:latest
    args:
    - "--context=$(workspaces.source.path)"
    - "--destination=$(params.IMAGE):$(params.TAG)"
    - "--dockerfile=$(workspaces.source.path)/Dockerfile"
---
# Pipeline — git clone → test → build → deploy
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci-pipeline
spec:
  params:
  - name: REPO_URL
  - name: IMAGE
  - name: IMAGE_TAG
  workspaces:
  - name: shared-workspace
  tasks:
  - name: clone
    taskRef:
      name: git-clone            # from Tekton Hub
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.REPO_URL)

  - name: unit-test
    runAfter: [clone]            # dependency — runs after clone
    taskRef:
      name: maven
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: GOALS
      value: ["test"]

  - name: build-push
    runAfter: [unit-test]
    taskRef:
      name: docker-build-push
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: IMAGE
      value: $(params.IMAGE)
    - name: TAG
      value: $(params.IMAGE_TAG)

Workspaces — how Tasks share files

Each Task runs as a separate Pod. Without workspaces, the git-clone Task clones code but the build Task cannot access it. Workspaces solve this: the Pipeline declares a workspace, each Task mounts it, and a PersistentVolumeClaim binds them together in the PipelineRun.

🔔 Triggers — Webhook-Driven Pipelines

Trigger the pipeline automatically from Git webhooks

Three resources work together: EventListener (HTTP endpoint that receives webhooks), TriggerBinding (extracts data from the webhook payload), TriggerTemplate (creates a PipelineRun when triggered).

# EventListener — receives GitHub webhook
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-listener
spec:
  triggers:
  - name: github-push
    interceptors:
    - ref:
        name: github
      params:
      - name: secretRef
        value:
          secretName: github-webhook-secret
          secretKey: secretToken
      - name: eventTypes
        value: ["push"]
    bindings:
    - ref: github-push-binding
    template:
      ref: ci-pipeline-template
---
# TriggerBinding — extract data from webhook payload
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: github-push-binding
spec:
  params:
  - name: git-repo-url
    value: $(body.repository.clone_url)
  - name: git-revision
    value: $(body.head_commit.id)
---
# TriggerTemplate — create PipelineRun on trigger
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: ci-pipeline-template
spec:
  params:
  - name: git-repo-url
  - name: git-revision
  resourcetemplates:
  - apiVersion: tekton.dev/v1
    kind: PipelineRun
    metadata:
      generateName: ci-run-
    spec:
      pipelineRef:
        name: ci-pipeline
      params:
      - name: REPO_URL
        value: $(tt.params.git-repo-url)
      - name: IMAGE_TAG
        value: $(tt.params.git-revision)
      workspaces:
      - name: shared-workspace
        volumeClaimTemplate:
          spec:
            accessModes: [ReadWriteOnce]
            resources:
              requests:
                storage: 1Gi

🔴 OpenShift Pipelines

OpenShift Pipelines = Tekton + enterprise integration

Install via OperatorHub: the OpenShift Pipelines Operator installs Tekton controllers, the dashboard, and the tkn CLI automatically. OpenShift-specific additions:

  • ClusterTasks pre-installed — git-clone, buildah (OCI builds), s2i (source-to-image), openshift-client (oc commands), deploy-on-openshift
  • OpenShift Console integration — visual pipeline progress view directly in the OpenShift web console without installing Tekton Dashboard separately
  • Routes for EventListener — webhook endpoint auto-exposed via OpenShift Route with TLS
  • SCC awareness — pipeline service accounts automatically get the correct Security Context Constraints
# tkn CLI — manage pipelines from terminal
tkn pipeline list
tkn pipelinerun list --limit 10
tkn pipelinerun logs my-run-xyz --follow    # stream live logs
tkn taskrun describe my-run-xyz-clone       # inspect a specific task

# Start a pipeline manually with tkn
tkn pipeline start ci-pipeline \
  -p REPO_URL=https://github.com/company/myapp \
  -p IMAGE=myregistry.com/myapp \
  -p IMAGE_TAG=v1.0 \
  -w name=shared-workspace,volumeClaimTemplateFile=workspace-pvc.yaml

# Check which pod each TaskRun created
tkn taskrun describe my-run-clone | grep "Pod Name"

🎯 Interview Questions

TEKTON · ENGINEER
What is Tekton and why is it used in OpenShift environments?
Tekton is a Kubernetes-native CI/CD framework where every pipeline component is a Kubernetes Custom Resource. Tasks (reusable work units), Pipelines (ordered task sequences), TaskRuns, and PipelineRuns are all CRDs — created with kubectl apply, inspected with kubectl get, running as Pods. In OpenShift: Red Hat ships OpenShift Pipelines which IS Tekton with extra integration — pre-built ClusterTasks for common operations (git-clone, buildah for container builds, s2i, deploy to OpenShift), the tkn CLI, and pipeline progress visible directly in the OpenShift web console. Why Tekton over Jenkins in OpenShift: runs entirely inside the cluster as pods — no external CI server to maintain, patch, or scale. Each Task is an isolated Pod — complete environment isolation between steps. Security: runs under K8s RBAC and OpenShift SCCs — same model as applications. No separate credential store. Scalability: Kubernetes schedules TaskRun pods automatically.
TEKTON · ENGINEER
What are Workspaces in Tekton and why are they needed?
Workspaces are shared storage locations that pass data between Tasks in a Pipeline. The problem: each Task runs as a separate Pod — Pods do not share filesystems. A git-clone Task clones source code into a workspace. The next Task (build) needs that source code. Without workspaces, the build Task has no code. How workspaces work: the Pipeline declares a workspace name (e.g. shared-workspace). Each Task that needs it declares it uses that workspace. When a PipelineRun is created, you bind the workspace to an actual volume — a PVC, ConfigMap, Secret, or emptyDir. The framework mounts that volume into each TaskRun Pod at the workspace path. Types: PVC (survives between Tasks, standard for source code), emptyDir (ephemeral, reset between Tasks), ConfigMap/Secret (read-only data injection). Best practice: use volumeClaimTemplate in PipelineRun — auto-create and auto-delete a fresh PVC per pipeline run. Clean storage per build, automatic cleanup.
TEKTON · PRODUCTION
A PipelineRun failed. How do you investigate?
Step 1: tkn pipelinerun describe my-run shows which Task failed with the error message. Or: kubectl describe pipelinerun my-run — Conditions section shows the failure reason. Step 2: find the failing TaskRun. tkn taskrun list --pipeline-run my-run. Step 3: get logs from the failed TaskRun. tkn taskrun logs my-run-build-xyz --all shows all Steps. The Step that failed shows its error output. Step 4: check pod events. kubectl describe pod my-run-build-xyz-pod shows K8s events — image pull failures, resource quota exceeded, volume mount errors. Common causes: workspace not bound (PVC not created), image not found in registry, Step container lacks permission (SCC issue in OpenShift), resource limits too low, git clone failed (wrong credentials or branch name). Step 5: re-run a single Task for testing. tkn task start docker-build-push --use-param-defaults to test in isolation without running the full Pipeline.
Continue Learning
🔴 OpenShift🐙 ArgoCD🏠 Home
🤖
AI Assistant
Ask anything about this topic
👋 Hi! I have read this page and can answer your questions.

Try asking: "Explain this topic in simple terms" or "Give me an example" or ask any specific question.