Tekton – Concepts

Docs: Overview

Mon, 01 Jan 0001 00:00:00 +0000

What is Tekton?

Tekton is a cloud-native solution for building CI/CD pipelines. It consists of Tekton Pipelines, which provides the building blocks, and of supporting components, such as Tekton CLI and Tekton Catalog, that make Tekton a complete ecosystem. Tekton is an incubating project at the Cloud Native Computing Foundation (CNCF).

Tekton installs and runs as an extension on a Kubernetes cluster and comprises a set of Kubernetes Custom Resources that define the building blocks you can create and reuse for your pipelines. Once installed, Tekton Pipelines becomes available via the Kubernetes CLI (kubectl) and via API calls, just like pods and other resources.

Who uses Tekton?

Tekton users typically fall into the following categories:

Platform engineers who build CI/CD systems for the developers in their organization.
Developers who use those CI/CD systems to do their work.

What are the benefits of Tekton?

Tekton provides the following benefits to builders and users of CI/CD systems:

Customizable. Tekton entities are fully customizable, allowing for a high degree of flexibility. Platform engineers can define a highly detailed catalog of building blocks for developers to use in a wide variety of scenarios.
Reusable. Tekton entities are fully portable, so once defined, anyone within the organization can use a given pipeline and reuse its building blocks. This allows developers to quickly build complex pipelines without “reinventing the wheel.”
Expandable. Tekton Catalog is a community-driven repository of Tekton building blocks. You can quickly create new and expand existing pipelines using pre-made components from the Tekton Catalog.
Standardized. Tekton installs and runs as an extension on your Kubernetes cluster and uses the well-established Kubernetes resource model. Tekton workloads execute inside Kubernetes containers.
Scalable. To increase your workload capacity, you can simply add nodes to your cluster. Tekton scales with your cluster without the need to redefine your resource allocations or any other modifications to your pipelines.

What are the components of Tekton?

Tekton consists of the following components:

Tekton Pipelines is the foundation of Tekton. It defines a set of Kubernetes Custom Resources that act as building blocks from which you can assemble CI/CD pipelines.
Tekton Triggers allows you to instantiate pipelines based on events. For example, you can trigger the instantiation and execution of a pipeline every time a PR is merged against a GitHub repository. You can also build a user interface that launches specific Tekton triggers.
Tekton CLI provides a command-line interface called tkn, built on top of the Kubernetes CLI, that allows you to interact with Tekton.
Tekton Dashboard is a Web-based graphical interface for Tekton Pipelines that displays information about the execution of your pipelines. It is currently a work-in-progress.
Tekton Catalog is a repository of high-quality, community-contributed Tekton building blocks - Tasks, Pipelines, and so on - that are ready for use in your own pipelines.
Tekton Hub is a Web-based graphical interface for accessing the Tekton Catalog.
Tekton Operator is a Kubernetes Operator pattern that allows you to install, update, and remove Tekton projects on your Kubernetes cluster.
Tekton Chains provides tools to generate, store, and sign provenance for artifacts built with Tekton Pipelines.
Pipelines-as-Code brings a Git-native CI/CD workflow to Tekton, allowing you to define your pipelines in a .tekton/ directory alongside your source code. It integrates with GitHub, GitLab, Bitbucket, and Forgejo.

How do I work with Tekton?

To install Tekton, you need a Kubernetes cluster running a version of Kubernetes specified for the current Tekton release. Once installed, you can interact with Tekton using one of the following:

The tkn CLI, also known as the Tekton CLI, is the preferred command-line method for interacting with Tekton. tkn provides a quick and streamlined experience, including high-level commands and color coding. To use it, you only need to be familiar with Tekton.
The kubectl CLI, also known as the Kubernetes CLI, provides substantially more granularity for controlling Tekton at the expense of higher complexity. Interacting with Tekton via kubectl is typically reserved for debugging your pipelines and troubleshooting your builds.
The Tekton APIs, currently available for Pipelines and Triggers, allow you to programmatically interact with Tekton components. This is typically reserved for highly customized CI/CD systems. In most scenarios, tkn and kubectl are the preferred methods of controlling Tekton.

We also recommend having the following items configured on your Kubernetes cluster:

Persistent volume claims for specifying inputs and outputs.
Permissions appropriate to your environment and business needs.
Storage for building and pushing images (if applicable).

What can I do with Tekton?

Tekton introduces the concept of Tasks, which specify the workloads you want to run:

Task - defines a series of ordered Steps, and each Step invokes a specific build tool on a specific set of inputs and produces a specific set of outputs, which can be used as inputs in the next Step.
Pipeline - defines a series of ordered Tasks, and just like Steps in a Task, a Task in a Pipeline can use the output of a previously executed Task as its input.
TaskRun - instantiates a specific Task to execute on a particular set of inputs and produce a particular set of outputs. In other words, the Task tells Tekton what to do, and a TaskRun tells Tekton what to do it on, as well as any additional details on how to exactly do it, such as build flags.
PipelineRun - instantiates a specific Pipeline to execute on a particular set of inputs and produce a particular set of outputs to particular destinations.

Each Task executes in its own Kubernetes Pod. Thus, by default, Tasks within a Pipeline do not share data. To share data among Tasks, you must explicitly configure each Task to make its outputs available to the next Task and to ingest the outputs of a previously executed Task as its inputs, whichever is applicable.

When to use which?

Task - useful for simpler workloads such as running a test, a lint, or building a Kaniko cache. A single Task executes in a single Kubernetes Pod, uses a single disk, and generally keeps things simple.
Pipeline - useful for complex workloads, such as static analysis, as well as testing, building, and deploying complex projects.

I want to learn more!

See the Tekton concept model to learn more about the basics of how Tekton tasks and pipelines interact.
Run your first pipeline following the Getting Started guide.

Docs: Concept model

Mon, 01 Jan 0001 00:00:00 +0000

Steps, Tasks, and Pipelines

A step is an operation in a CI/CD workflow, such as running some unit tests for a Python web app, or the compilation of a Java program. Tekton performs each step with a container image you provide. For example, you may use the official Go image to compile a Go program in the same manner as you would on your local workstation (go build).

A task is a collection of steps in order. Tekton runs a task in the form of a Kubernetes pod, where each step becomes a running container in the pod. This design allows you to set up a shared environment for a number of related steps; for example, you may mount a Kubernetes volume in a task, which will be accessible inside each step of the task.

A pipeline is a collection of tasks in order. Tekton collects all the tasks, connects them in a directed acyclic graph (DAG), and executes the graph in sequence. In other words, it creates a number of Kubernetes pods and ensures that each pod completes running successfully as desired. Tekton grants developers full control of the process: one may set up a fan-in/fan-out scenario of task completion, ask Tekton to retry automatically should a flaky test exists, or specify a condition that a task must meet before proceeding.

Tasks and pipelines are specified as custom resources in a Kubernetes cluster.

TaskRuns and PipelineRuns

A pipelineRun, as its name implies, is a specific execution of a pipeline. For example, you may ask Tekton to run your CI/CD workflow twice a day, and each execution will become a pipelineRun resource trackable in your Kubernetes cluster. You can view the status of your CI/CD workflow, including the specifics of each task execution with pipelineRuns.

Similarly, a taskRun is a specific execution of a task. TaskRuns are also available when you choose to run a task outside a pipeline, with which you may view the specifics of each step execution in a task.

TaskRuns and pipelineRuns connect resources with tasks and pipelines. A run must include the actual addresses of resources, such as the URLs of repositories, its task or pipeline needs. This design allows developers to reuse tasks and pipelines for different inputs and outputs.

You may create taskRuns or pipelineRuns manually, which triggers Tekton to run a task or a pipeline immediately. Alternately, one may ask a Tekton component, such as Tekton Triggers, to create a run automatically on demand; for example, you may want to run a pipeline every time a new pull request is checked into your git repository.

TaskRuns and pipelineRuns are specified as custom resources in a Kubernetes cluster.

How Tekton works

Loosely speaking, at its core, Tekton Pipelines functions by wrapping each of your steps. More specifically, Tekton Pipelines injects an entrypoint binary in step containers, which executes the command you specify when the system is ready.

Tekton Pipelines tracks the state of your pipeline using Kubernetes Annotations. These annotations are projected inside each step container in the form of files with the Kubernetes Downward API. The entrypoint binary watches the projected files closely, and will only start the provided command if a specific annotation appears as files. For example, when you ask Tekton to run two steps consecutively in a task, the entrypoint binary injected into the second step container will wait idly until the annotations report that the first step container has successfully completed.

In addition, Tekton Pipelines schedules some containers to run automatically before and after your step containers, so as to support specific built-in features, such as the retrieval of input resources and the uploading of outputs to blob storage solutions. You can track their running statuses as well via taskRuns and pipelineRuns. The system also performs a number of other operations to set up the environment before running the step containers; for more information, see Tasks and Pipelines.

What’s next

Learn more about Tekton Pipelines in Tasks and Pipelines.

Docs: Supply Chain Security

Mon, 01 Jan 0001 00:00:00 +0000

Given the increasing complexity of the CI/CD space, with projects that often have dozens or even hundreds of dependencies, the supply chain has become a common vector of attacks. Tekton Chains is a security-oriented part of the Tekton portfolio to help you mitigate security risks.

Tekton Chains is a tool to generate, store, and sign provenance for artifacts built with Tekton Pipelines. Provenance is metadata containing verifiable information about software artifacts, describing where, when and how something is built.

How to secure your Supply Chain

Supply chain Levels for Software Artifacts (SLSA) provides a set of guidelines you can follow to make your software more secure. SLSA is organized into a series of levels, where level 4 represents the ideal state. Go to slsa.dev for more information.

Tekton Chains implements the SLSA guidelines to help you accomplish SLSA level 2, by documenting the build process in a tamper resistant format.

How does Tekton Chains work?

Tekton Chains works by deploying a controller that runs in the background and monitors TaskRuns. While Tekton Pipelines executes your Tasks, Tekton Chains watches the operation, once the operation is successfully completed, the Chains controller generates the provenance for the artifacts produced.

The provenance records the inputs of your Tasks: source repositories, branches, other artifacts; and the outputs: container images, packages, etc. This information is recorded as in-toto metadata and signed. You can store the keys to sign the provenance in a Kubernetes secret or by using a supported key management system: GCP, AWS, Azure, or Vault. You can then upload the provenance to a specified location. Getting To SLSA Level 2 with Tekton and Tekton Chains on the Google Open Source Blog provides more details.

graph LR subgraph TOP[Kubernetes] direction TB subgraph C[Tekton Chains controller] direction TB c1(Observe Runs) c2(Generate Provenance) c3(Sign Metadata) end subgraph B[Pipelines] direction LR subgraph B1[Pipeline] direction TB i1[Task] --> f1[Task] end subgraph B2[Pipeline] direction TB i2[Task] --> f2[Task] end B1 --> B2 end end A[Sources] -.-> B -.-> D[Artifacts]

Where can I try it?

For a hands-on experience, follow the Getting started with Tekton Chains tutorial.
Check the examples available on the Chain repository.