Tekton CI/CD review

Reviewing Tekton as one of the latest CI/CD tools

Introduction

In today’s dynamic landscape of Continuous Integration and Continuous Deployment (CI/CD) tools, Tekton stands out as a versatile choice with both advantages and drawbacks. On the positive side, Tekton offers Cloud-Native compatibility, allowing seamless integration with tools like Kubernetes. Its pipeline configuration format aligns closely with Kubernetes, making it easy to adopt for those familiar with Kubernetes standards. However, Tekton does come with its set of challenges, including limitations in cross-cluster management, an evolving API, and the need for Kubernetes Custom Resource Definitions (CRDs), which may pose constraints in specific environments. This article explores Tekton’s strengths and weaknesses, offering a comprehensive overview of CI/CD tool choices.

Tekton Pros & Cons

Pros:

• Cloud-Native Compatibility: It’s highly compatible with Cloud-Native tools like Kubernetes. Its pipeline .yaml format is similar to Kubernetes, so you won’t need much time to learn its templating style if you’re already familiar with Kubernetes standard .yaml formats.
• Kubernetes Resources for CI/CD jobs: When you define a task inside Tekton, it creates a pod and runs your jobs using Kubernetes resources, eliminating the need for an external build machine.
• Modular pipeline: Tekton is one of the best tools for defining pipelines and reusing its steps in other pipelines. It features a modular system that allows you to create a powerful hierarchical model for your tasks.
• Community hub: there’s a hub where others can share their pipeline codes, and you can download them and apply them to your Tekton instance (https://hub.tekton.dev).

Cons:

• Lack of Cross Cluster: You need to install Tekton per Kubernetes cluster, and you can’t manage multiple Kubernetes clusters with a single administration dashboard. This could be important if you need to separate your dev and prod clusters but are managing them with a single dashboard.
• Unstable API: As of September 2023, it’s at version 0.x, and its API undergoes frequent changes. For instance, if you’ve written a pipeline using version 0.22.x, it can’t be used in version 0.55.x because they changed CRDs.
• CRDs: To use Tekton, you need to install its CRDs (Kubernetes Custom Resource Definitions), which require cluster administration access. If you’re using a multi-tenant Kubernetes cluster, you can’t use Tekton unless the cluster administrator installs it. Additionally, upgrading Tekton affects the entire cluster because it uses cluster-wide CRDs.
• Incompatibility with some Kubernetes versions: Some older versions of Tekton may have compatibility issues with newer Kubernetes versions. For example, version 0.22.x couldn’t be installed on Kubernetes 1.24 due to the use of some deprecated Kubernetes APIs, and you’d have to downgrade your Kubernetes cluster to version 1.20.x or use a newer Tekton version. Sometimes, upgrading to a newer Tekton version isn’t possible because your pipeline code depends on older Tekton CRDs, requiring you to change all of them.
• Cluster dependency: When you encounter issues in the Kubernetes cluster, you can’t access the Tekton app because Tekton is deployed inside the Kubernetes cluster.

Alternatives

Each CI/CD pipeline has its pros and cons, and the best choice depends on your environment. There are some other alternatives to Tekton, such as Jenkins and GitLab CI. In the following table, I have compared some of the most popular CI/CD pipeline tools:

CI/CD     |   Paac   |    Build    | template    | mature    | multi cluster
Tool name |   lang   |    Agent    | inheritance | dashboard | management
----------------------------------------------------------------------------
Tekton    |  Groovy  | linux & mac |  Yes        | No        | No
          |          | & windows   |             |           |
----------------------------------------------------------------------------
Jenkins   |  Yaml    | linux & mac |  No         | Yes       | Yes
          |          | & windows   |             |           |
----------------------------------------------------------------------------
Gitlab-ci |  Yaml    | depends on  |  Yes        | Yes       | Yes
          |          | k8s nodes   |             |           |
---------------------------------------------------------------------------
          |  Java    | linux & mac |  No         | Yes       | Yes
Bamboo    | (limited | & windows   |             |           |
          |  scope)  |             |             |           |

Paac Lang (Pipeline as a Code Language): You can define your pipeline as code. Some modern CI/CD tools support this ability, allowing you to store your pipeline in a Git repository and track its changes.

Build Agent: Some applications require a specific OS for building. For example, an iOS application can only be built on macOS so you need to add a macOS build machine to your pipeline executor.

Template Inheritance: This is an ability in a CI/CD pipeline that helps you avoid repeating yourself. You can define a general pipeline and inherit it based on your requirements in every environment.

Mature Dashboard: One of the requirements of every CI/CD pipeline is the ability to see the pipeline steps and the overall status at a glance, making it easier to investigate problems quickly.

Multi-Cluster Management: For CD pipelines, it’s beneficial to be able to manage multiple environments in a single place. As the number of environments increases, managing them becomes exponentially more challenging.

If you were to ask me about my favorite CI/CD pipeline, I would say GitLab. In the following article, I have reviewed GitLab as a CD tool

Managing multiple Kubernetes clusters using Git

Tekton Installation

The installation process is very straightforward, and you can easily install it in your Kubernetes environment. Please keep in mind that Tekton should be installed in your target Kubernetes cluster, and you cannot install it in one Kubernetes cluster and then deploy your applications in another Kubernetes cluster.

$ minikube start --kubernetes-version=1.20
$ kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.22.0/release.yaml
$ kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/previous/v0.12.1/release.yaml
$ kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/previous/v0.13.0/interceptors.yaml
$ kubectl apply -f https://storage.googleapis.com/tekton-releases/dashboard/previous/v0.30.0/release.yaml
$ kubectl --namespace tekton-pipelines port-forward svc/tekton-dashboard 9097:9097

Tekton Hierarchy Model

Tekton follows the following hierarchy model:

In the following section, I’ll describe the hierarchy model as code and how these elements can refer to each other as loosely coupled items. You can reuse a task in another pipeline, thanks to the power of Tekton’s reusability templates.

Task: A task is the smallest unit in the Tekton specification. It can contain one or more steps. Each step represents a small task, such as cloning a Git repository, running a test case on your project, or executing any job that can be scripted.

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: image-build-task

spec:
  
  params:
  - name: ALPINE_IMAGE
    description: an image clone & build project
  - name: SOURCE_URL
    description: source git repository URL
  
  workspaces:
    - name: git-source
  
  steps:
  
  - name: git-clone
    image: "$(params.ALPINE_IMAGE)"
    script: |
      #!/bin/sh
      git clone $(params.SOURCE_URL)

  - name: build
    image: "$(params.ALPINE_IMAGE)"
    script: |
      #!/bin/sh
      pack build testjavadocker --builder=buildpacks/builder-jammy-base:0.1.0

TaskRun (optional): A TaskRun is simply responsible for running a Task. Most of the time, it’s not used, and you can choose not to use it.

Pipeline: Each pipeline should contain one or more Tasks. You can write your tasks separately and include them in a pipeline.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: image-build-pipeline
spec:
  params:
  - name: ALPINE_IMAGE
    description: an image clone & build project
  - name: SOURCE_URL
    description: source git repository URL

  workspaces:
    - name: git-source
  
  tasks:
    - name: image-build
      taskRef:
        name: image-build-task
      params:
        - name: ALPINE_IMAGE
          value: "$(params.ALPINE_IMAGE)"
        - name: SOURCE_URL
          value: "$(params.SOURCE_URL)"
      workspaces:
        - name: git-source
          workspace: git-source

PipelineRun: To run a Pipeline, you need to create a PipelineRun. You can write your pipelines separately and include them in a PipelineRun. (The tt in the following script refers to the TriggerBinding that calls this PipelineRun.)

apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
  generateName: image-build-
spec:
  pipelineRef:
    name: image-build-pipeline
  workspaces:
    - name: git-source
      emptyDir: {}
  params:
    - name: WORKSPACE_DIR
      value: "$(tt.params.WORKSPACE_DIR)"

TriggerTemplate (tt): To trigger a PipelineRun, you need to create a TriggerTemplate. You can write PipelineRuns separately and include them in the TriggerTemplate. It’s a common practice to combine a TriggerTemplate with a PipelineRun, as shown in the following example:

apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: image-build-template
spec:
  params:
    - name: WORKSPACE_DIR
      description: Tekton workspace directory
    - name: ALPINE_IMAGE
      description: an image clone & build project
    - name: SOURCE_URL
      description: source git repository URL
  resourcetemplates:
    - apiVersion: tekton.dev/v1alpha1
      kind: PipelineRun
      metadata:
        generateName: image-build-
      spec:
        pipelineRef:
          name: image-build-pipeline
        workspaces:
          - name: git-source
            emptyDir: {}
        params:
          - name: WORKSPACE_DIR
            value: "$(tt.params.WORKSPACE_DIR)"

TriggerBinding (tb): It’s better to place your custom environment variables into a TriggerBinding. It is created to be combined with TriggerTemplate to enable the running of different aspects of the pipeline. For example, you may create an abstract pipeline that clones a Git repository and runs a build command. You can use TriggerBinding to define the Git repository address and build command for each of your projects.

apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerBinding
metadata:
  name: myapp-tb
spec:
  params:
    - name: SOURCE_URL
      value: ssh://git@github.com/mlkmhd/test.git
    - name: ALPINE_IMAGE
      value: "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.21.0"
    - name: SOURCE_URL
      value: "https://github.com/mlkmhd/test"

Webhook: A webhook should contain one or more triggers. You can combine a TriggerTemplate and TriggerBinding together to create a new trigger.

apiVersion: triggers.tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: webhook
spec:
  replicas: 1
  triggers:
  - name: test-dev-build
    bindings:
    - kind: TriggerBinding
      ref: myapp-tb
    template:
      ref: image-build-template
    interceptors:
    - bitbucket:
        eventTypes:
        - repo:*

Conclusion

The choice of a CI/CD tool is not a one-size-fits-all decision; it depends on the specific requirements and constraints of your environment. Tekton’s Cloud-Native compatibility, efficient use of Kubernetes resources, and modularity make it an attractive option for many users. Nevertheless, its limitations, such as challenges in cross-cluster management, API stability, and CRD dependencies, need to be carefully considered. It’s worth noting that Tekton is just one of the many options available in the CI/CD landscape. Alternatives like Jenkins and GitLab CI offer their own unique features and trade-offs. Ultimately, the choice of the right CI/CD tool should be driven by a thorough assessment of your organization’s specific needs and constraints. In this article, we have provided an overview of Tekton and a comparison with other popular CI/CD tools, helping you make an informed decision for your CI/CD pipeline needs.

GitHub

You can find all the diagrams and code used in this article in the following GitHub repository:

devops-diagrams/tekton at main · mlkmhd/devops-diagrams

Support My Blog ☕️

If you have any feedback or suggestions for improving my code, please leave a comment on this post or send me a message on my LinkedIn. If you enjoy my technical blog posts and find them valuable, please consider buying me a coffee at here. Your support goes a long way in helping me produce more quality articles and content.