In this article I want to give an overview of Tekton with the goal of explaining the basics and getting you started quickly.
According to its own homepage, Tekton wants to become the standard for CI/CD. On the one hand, it offers a framework for building cloud-native CI/CD systems in Kubernetes and, on top of that, standardized tooling for these systems. Thus, it has already found its way into Jenkins X and is the basis for RedHat OpenShift Pipelines .
Developers who want to use a CI system benefit from the broad support, as existing pipelines and pipeline steps can be exchanged between Tekton CI implementations without effort.
The Tekton project uses Kubernetes as a platform and, at its core, represents the building blocks of a CI pipeline in the form of CRDs. A Custom Resource Definition (CRD) is a self-created Kubernetes object that can be used to make your own objects visible and usable within the Kubernetes API.
In Tekton, for example, objects such as a pipeline can be found that represent the same and can be configured by tasks that execute the individual process steps.
The entire configuration then takes place via manifests, as is usual with Kubernetes. The existing Kubernetes know-how comes into its own here, because in addition to configuration, introspection of the processes can also take place via this path.
The Tekton Hub is offered as a central point of contact for tasks and pipelines maintained by the community. Many building blocks can already be found there to cover the most common steps. In addition to the public hub, it is very easy to implement specific solutions once within your own organization and distribute them reliably.
In addition to the manifests, Tekton of course also provides the Kubernetes operators in the Tekton Pipelines Repository . They execute the configured steps. As is common with modern CI systems, the build steps are executed within containers.
Installation is done either by applying the Kubernetes manifests from the release page or by using the Tekton Operator .
The Tekton operator is currently still in an early development phase and currently offers installation only. Instructions on how to configure the installation can be found on the help pages .
Installation via the Kubernetes manifests is very well described in the Getting Started Guide .
To quickly have a usable installation available, I recommend installing the pipeline component and the dashboard component to get a visual view of the running Tekton installation. The dashboard can be accessed from the outside via a browser.
In the GitHub project Tekton-Demo you can find a complete installation which runs with K3d directly on the local system. The installation can be found in the README and is always up to date in the GitHub Action .
After the installation has run successfully, the cluster is a running Tekton installation with tasks and pipelines installed in the namespace
Since it is very easy to look in the wrong namespace I would like to recommend
kubens only briefly, because
kubens tekton-pipelines sets the default namespace correctly.
The dashboard is accessible via a port forward and an event listener is usable via an ingress and can also already react to events, but we will get to that in another blog article.
An example CI pipeline
After the installation, we can already get to know the main components and use them to build a "Hello, World!" – example.
task consists of a series of
steps which are executed in order. A
step is a self-contained command, which in the following example is named
hello, the call to
echo "Hello World!". This is started and executed in a bash container, which of course can be changed to your liking.
In real use you can find commands at this point, which do a checkout, build images and much more.
apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: hello spec: steps: - name: hello image: bash:latest command: - echo args: - "Hello, world!"
goodbye task is created, which says goodbye with a
echo command on the system console.
In this small example we will create a pipeline that calls the two tasks one after the other, so that when you look at the pipeline logs you will see both the hello and the goodbye.
Very intuitively – in my opinion anyway – we create a CRD of type
Pipeline and define a list of tasks there, which can be provided with dependencies among each other. In this simple example we specify via
runAfter that the farewell should take place after the greeting.
kind: Pipeline metadata: name: hello-goodbye-pipeline spec: tasks: - name: hello taskRef: name: hello - name: goodbye runAfter: - hello taskRef: name: goodbye
task defined above is linked via a
taskRef so that the defined tasks are linked via it and the pipeline runs through the two steps.
Interaction with Tekton
As shown at the beginning, Tekton works by configuring and installing CRDs. These API objects can be retrieved and manipulated directly via
kubectl, through which a traceable API is mapped. Installed pipelines can be retrieved easily:
# kubectl get pipelines.tekton.dev --all-namespaces -o wide NAMESPACE NAME AGE 8 tekton-pipelines hello-goodbye-pipeline 1s 9
Furthermore it is of course possible to start a pipeline. In the repository you can find a
PipelineRun which I show in the following:
apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: hello-goodbye-pipeline- spec: pipelineRef: name: hello-goodbye-pipeline
The configuration provides a prefix for the generated runs via the
generateName attribute. It also provides a reference to the pipeline to be used, which we created during the installation and looked at in the course of this article.
How to start a pipeline? Now we need another API object, the
PipelineRun. This object brings the necessary parameters – in our case none yet – in connection with the pipeline to be executed. As a user, we can get the status and also the log output by reference to the generated run.
Here we go:
kubectl create -n tekton-pipelines -f ./hello-goodbye-pipeline-run.yaml
And as already indicated, we retrieve all the runs:
kubectl get pipelineruns.tekton.dev --all-namespaces -o wide NAMESPACE NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME 8 tekton-pipelines hello-goodbye-pipeline-v5h5l True Succeeded 13s 1s
Here you can see the existing status fields of this object. For black-box testing, we can therefore wait for the PipelineRun status to change to
Succeeded to detect the passing of a pipeline.
In addition to the direct interaction with
kubectl, Tekton offers a specialized command line interface (CLI) that interacts directly with the cluster via the currently used Kubernetes context. Many Kubernetes-based tools come with a suitable CLI to work efficiently with the platform.
tkn is the corresponding Go binary which can be run on different platforms without any problems. Installation instructions can be found in the GitHub repository .
With this CLI, it is then easier to retrieve e.g. the tasks and pipelines. Here is a short example:
tkn task list --all-namespaces tkn pipeline list --all-namespaces
These two calls show all existing tasks and pipelines in all namespaces.
The inspection of the logs is done by this command:
tkn pr logs $PIPELINE_RUN_NAME
The output of all tasks is collected and traceable here and looks like this:
[hello : hello] Hello World! [goodbye : goodbye] Goodbye World!
We have now done the installation with little effort and also already created the first pipeline. By doing so, we have already achieved a lot and could now take the first look behind the scenes.
In the following articles we will create a buildpack pipeline and extend the build pipeline with a WebHook trigger from outside. This will allow Tekton to automatically build a container image when a push is made to a Git repository.
Your job at Codecentric?
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.