Cloud Native 14 min read

Building a Simple Tekton Pipeline on Kubernetes: Concepts, Resources, Tasks, and Execution

This article explains how to construct a basic Tekton CI/CD pipeline on Kubernetes, covering core concepts, required resources, task definitions, pipeline templates, secret and ServiceAccount setup, execution monitoring, and includes full YAML and shell code examples for building, testing, and deploying a container image.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
Building a Simple Tekton Pipeline on Kubernetes: Concepts, Resources, Tasks, and Execution

Tektoncd/pipeline is an open‑source CI/CD framework designed for Kubernetes that leverages native Kubernetes features to control pipeline execution, with most control logic residing in its base images.

The main CRDs include PipelineResource (Git, Image), Task (the smallest unit of work) and TaskRun (execution instance), as well as Pipeline (a template orchestrating multiple tasks) and PipelineRun (pipeline execution instance). Proper operation also requires Secrets (Docker and Git credentials) and a ServiceAccount mounted into Tekton’s init containers.

To build a simple pipeline you need tools such as GoogleContainerTools/kaniko for in‑container image building and lacie83/k8s‑kubectl for cluster access, plus Docker and Git accounts. Example commands to create the required secrets are:

[root@acp-master1 ~]# kubectl create secret docker-registry auth-docker --docker-server=index.docker.io --docker-username=xxx --docker-password=xxxx
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
  ...
type: kubernetes.io/dockerconfigjson
# git 账户,支持rsa_id
apiVersion: v1
kind: Secret
metadata:
  name: auth-gitlab
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/basic-auth
stringData:
  username: aiyijing
  password: "*****"
# ServiceAccount linking the secrets
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bot-account
secrets:
- name: auth-docker
- name: auth-gitlab
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bot-account-cluster-admin
subjects:
- kind: ServiceAccount
  name: bot-account
  namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Three tasks are defined:

unit-tests : uses the golang image to run make test.

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: unit-tests
spec:
  inputs:
    resources:
    - name: workspace
      type: git
      targetPath: ./
  steps:
  - name: run-tests
    image: golang
    workingDir: /workspace
    command: ["make"]
    args: ["test"]

build-push : a custom kaniko image that builds and pushes the Docker image, tagging it with the Git commit ID.

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: build-push
spec:
  inputs:
    resources:
    - name: workspace
      type: git
    params:
    - name: pathToDockerFile
      default: /workspace/dockerfile
    - name: pathToContext
      default: /workspace/
  outputs:
    resources:
    - name: builtImage
      type: image
  steps:
  - name: build-and-push
    image: aiyijing/kaniko-init:latest
    env:
    - name: "DOCKER_CONFIG"
      value: "/builder/home/.docker/"
    command: ["/mykaniko/myexcutor"]
    args: ["$(inputs.params.pathToDockerFile)", "$(inputs.params.pathToContext)", "$(outputs.resources.builtImage.url)"]

deploy : uses a custom kubectl image to update the deployment image in the cluster.

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: deploy
spec:
  inputs:
    resources:
    - name: workspace
      type: git
    - name: builtImage
      type: image
    params:
    - name: repoPath
      default: /workspace/
    - name: resource
      default: ""
    - name: container
      default: ""
  steps:
  - name: deploy
    image: aiyijing/kubectl:latest
    env:
    - name: "DOCKER_CONFIG"
      value: "/builder/home/.docker/"
    command: ["alaudactl"]
    args: ["$(inputs.params.resource)", "$(inputs.params.container)", "$(inputs.resources.builtImage.url)", "$(inputs.params.repoPath)"]

The pipeline template ties the tasks together, specifying execution order with runAfter and passing required resources and parameters:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-nginx--pipeline
spec:
  resources:
  - name: source-repo
    type: git
  - name: web-image
    type: image
  tasks:
  - name: unit-tests
    taskRef:
      name: unit-tests
    resources:
      inputs:
      - name: workspace
        resource: source-repo
  - name: build-push
    runAfter: [unit-tests]
    taskRef:
      name: build-push
    params:
    - name: pathToDockerFile
      value: /workspace/workspace/Dockerfile
    - name: pathToContext
      value: /workspace/workspace
    resources:
      inputs:
      - name: workspace
        resource: source-repo
      outputs:
      - name: builtImage
        resource: web-image
  - name: deploy
    runAfter: [build-push]
    taskRef:
      name: deploy
    params:
    - name: repoPath
      value: /workspace/workspace
    - name: resource
      value: nginx
    - name: container
      value: nginx
    resources:
      inputs:
      - name: workspace
        resource: source-repo
      - name: builtImage
        resource: web-image

A PipelineRun launches the pipeline, binds the ServiceAccount, and references the previously created resources:

apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
  name: build-nginx--pipelinerun
spec:
  pipelineRef:
    name: build-nginx--pipeline
  serviceAccount: bot-account
  resources:
  - name: source-repo
    resourceRef:
      name: nginx-source-code
  - name: web-image
    resourceRef:
      name: nginx

After creation, the tasks execute sequentially (unit‑tests → build‑push → deploy), and you can monitor progress via pod logs, kubectl get pods, or the status field of the PipelineRun. Example log extraction commands and status queries are provided in the source.

The article concludes that Tekton’s native Kubernetes integration offers a powerful, extensible pipeline mechanism, and highlights best‑practice considerations such as naming conventions, secret management, and log standardization.

Appendix sections supply a custom Kaniko Dockerfile and executor.sh script that tags images with the Git commit ID, as well as a custom lacie83/k8s‑kubectl Dockerfile and update.sh script for updating deployments.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Dockerci/cdKubernetesGitYAMLPipelinetekton
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.