Tekton is the Kubernetes-native continuous integration (CI) and continuous delivery (CD) engine. This article explains how Tekton works and how you can integrate it into an end-to-end DevOps process.
Tekton’s basic building blocks are called
Step is an individual command to execute and a
Task comprises one or more
Task represents a discrete, self-contained part of a process. An ordered set of
Tasks is called a
Pipeline. Figure 1 shows a
Pipeline example that illustrates how a given
Task may require several others to complete before it can proceed. Examples of many standard
Tasks can be found in the Tekton Catalog.
Figure 1. A Tekton
Pipeline is an ordered set of
Tasks. This is an example of how a
Pipeline could be constructed.
Tekton is a set of Kubernetes custom resources
Tekton is a cloud-native CI/CD system designed to run on Kubernetes and fit in naturally with existing Kubernetes mechanics. Tekton is implemented as a set of Kubernetes
CustomResourceDefinitions (CRDs), which are the standard Kubernetes extension mechanisms.
Tekton introduces several new CRDs including
PipelineRun represents a single running instance of a
Pipeline. As shown in Figure 2, a
PipelineRun is responsible for creating a
Pod for each of its
Tasks and as many containers within each
Pod as it has
Steps. (Under the covers, a
PipelineRun creates one or more
TaskRuns, each of which manages its associated
Figure 2. Tekton runs scripts and other commands in containers.
Steps map to containers.
Tasks map to
Pipeline instances, such as a single Travis build or Jenkins job.
PipelineRuns manage their associated
Pods (by creating
Pods often share a temporary filesystem backed by a
I’m often asked to compare and contrast Tekton with other CI/CD systems such as Jenkins and Travis. One short answer is that Tekton is currently optimized for building and deploying cloud-native, microservice-based applications compared to the more general-purpose nature of the others. Jenkins requires a file, generally called
/Jenkinsfile, in the root directory of a project that contains its build script. Similarly, Travis looks for a
/.travis.yml file. In this way, each project tends towards having its own build logic, often with significant overlap with that in parallel projects.
Tekton’s use of custom resources means that a
Pipeline must exist in a namespace before it can be used. It is possible to include a
/tekton directory in each project and to fetch and install that before each build. However Tekton nudges its users to centralize and standardize build logic, consolidated into a separate repository and managed under its own lifecycle. This standardization can be beneficial when scaling up to larger numbers of microservices, many of which should share build logic that is identical but for a few substitutable parameters.
Integration with the outside world
Tasks need to interact with external systems. A very simple Tekton
Pipeline is of the following form:
git clone docker build docker tag docker push
Pipeline clones a Git repository, builds an image from it, and pushes that image to an external registry.
PipelineResource is used to model and interact with external entities such as Git repositories, image registries, pull requests, and cloud storage.
PipelineResources are used as inputs to and outputs from
Tasks. They also support authentication with the systems that they represent.
Credentials are stored as Kubernetes secrets and then referenced from the Kubernetes service account used to execute a given
PipelineResources collect their credentials from this service account. During the initialization phase of a
PipelineRun, credentials are converted from their native form into one suitable for the target system. For example, Git secrets are converted and merged into a
.gitconfig file and Docker secrets into
Building a DevOps pipeline
Tekton gives us the pieces that we need to build a useful DevOps pipeline. Figure 3 shows the high level flows involved in a very simple
Pipeline without all the linting, testing, and image scanning involved in a real world implementation.
Figure 3. High level overview of a simple DevOps pipeline
In this example,
Pipelines are initiated as a result of Git activity by a developer. See Weaveworks’ excellent What Is GitOps Really? article for more on why this model is increasingly popular.
Figure 3 shows a webhook initiating a Tekton
Pipeline. Webhooks are outbound HTTP POST messages with a payload specific to the particular event provider. These payloads contain most of the information necessary to kick off a Tekton
PipelineRun. I’ll explain webhooks in a bit more detail below.
The flow in Figure 3 shows the now-familiar process of building and publishing an image. The flow then goes on to show the new image being deployed to a target Kubernetes environment. This could be a dedicated namespace on the cluster where Tekton is running, or on one or more completely separate clusters. Deployment can occur immediately after build. For example, to a shared development or test environment, or it may occur separately as a result of Git commits to a second repository governing the target deployment environment.
This article provides a high level overview of Tekton architecture and design, and demonstrates how it can be adopted into a modern DevOps pipeline. Learn more by watching the lightboard video What is Tekton? with Matt Perrins. Then get started by downloading Tekton and trying a tutorial such as Build and deploy a Hello World application on Kubernetes using a Tekton pipeline.