What is Tekton?
Let’s talk about one of the hottest open source technologies in the CI/CD space: Tekton.
Tekton is a “Kubernetes Native” CI/CD system — We have seen many systems where it has its own scheduler and primitives but with Tekton it leverages Kubernetes as much as it can and it requires a Kubernetes cluster to be deployed . In simple words There is no Tekton without Kubernetes.
How its defined ?
Tekton pipelines are defined in yaml files which are typically stored in a Git. Tekton provides a set of Custom Resource extensions to Kubernetes that define pipelines and related concepts.
The following are the basic Tekton Pipeline building blocks:
The primitives that Tekton adds on top of the simple job execution are implemented as a Kubernetes CustomResourceDefinitions. The job is implemented as a task custom resource and to run the task you need to create a TaskRun. To chain multiple tasks together you will have to create a pipeline which is another custom resource and to run this pipeline there should be PipelineRun. Both Tasks and Pipelines can be fed with different inputs that can be in form of params, ConfigMaps, Secrets,Volumes and so on.
The usage of CRDs(Custom Resource Defenitions) allows Tekton tasks and pipelines to be easily re-usable. You can define organisation-global set of tasks to perform common operations and construct pipelines out of this tasks and you can even have a set of common pipelines applicable to every application of the same type.
Inside Tasks there is nothing but pods. Every task runs as a pod from a container image with some steps performed inside the container. You can provide the specification for this pods and do anything that you would normally do with Kubernetes pods.
So how do you create new TaskRuns and PipelineRuns? One way to do this is to use the Tekton CLI or kubectl. But that of course is not ideal as its a manual work everytime.
Another way is to use one more object from Tekton EventListener. EventListener is a special Deployment with a Service that listens all HTTP requests and processes them by using Triggers which in turn depends on 2 objects –
· TriggerBinding object- which maps the received payload to Tekton params
· TriggerTemplate- which gets those params and generates a new PipelineRun.
All these objects are a lot of YAMLs to automate. Just like with tasks and pipelines you can create a set of common trigger templates and trigger bindings.
Let’s draw the full picture of a simple pipeline — imagine we simply want to lint some YAML files on a new Pull Request in a GitHub repository. Don’t worry too much about the details of each of these components if you start looking inside those boxes, you will get crazy!
First we need 3 Task definitions — to clone the repo, to lint the files in the repo and to report the result of the build back to GitHub. We also need a Secret with Git credentials, a persistence volume so that Lint YAML task can access the repository cloned in the Git Clone task and a ServiceAccount so that Tekton can access the Secret internally.
To trigger the Pipeline we need an EventListener . For each EventListener, Tekton will create a new Service and Deployment and you will have to expose this Deployment with an Ingress or an OpenShift Route. As mentioned earlier, Listener needs to map request to TriggerBinding and TriggerTemplate. Keep in mind that you will probably need multiple TriggerBindings and TriggerTemplates as well as something called an Interceptor at least one per event type that you want to process.
Finally the PipelineRun will be created and your build will start running. To build such a pipeline we need to create objects of 6 different types including multiple tasks. In addition to this it would also require creating Secrets to connect to GitHub and PersisentVolumes to share the state between the Tasks inside the Pipeline. Once we go beyond the single pipeline we end up having a huge amount of such objects.
We would need to properly plan how we want to organise and deploy Tasks and Pipelines , the images what we use inside Tasks, how we maintain EventBindings and so on. We also have to combine the knowledge of Kubernetes with the knowledge of Tekton specific objects to build our CI/CD system. And this is the most important thing to know about Tekton it’s not a fully-featured ready to use CI/CD system like Gitlab CI or Drone CI or many other systems. Instead Tekton is already very powerful set of CI/CD primitives that you can use to build your own CI/CD system or even general purpose task automation system.
It’s the same difference between Kubernetes itself and a Platform as a Service solution
- Kubernetes gives you all the building blocks to create your own platform as a service but Kubernetes itself is nowhere close to being this kind of platform out of the box.
Having such a flexible set of building blocks that Tekton provides will let you build truly a flexible, powerful and tailored system that you can easily move between different Kubernetes clusters by simply re-applying the resource definitions.
That being said, I personally love Tekton for this approach of giving you the building blocks and it can bring amazing benefits for mid to large organizations.
