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.
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.ioThree 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-imageA 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: nginxAfter 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.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
