Skip to main content

Tekton Kubernetes-Native CI/CD Project Reaches CNCF Incubation 

The CNCF Technical Oversight Committee (TOC) has voted to accept Tekton as a CNCF incubating project. But what is Tekton?

Tekton is a flexible open source framework for creating continuous integration and delivery (CI/CD) systems. It is used to enable developers to build, test, and deploy across multiple cloud providers and on-premises systems by abstracting away the underlying implementation details.

No doubt attracted by Tekton’s Kubernetes-native DNA, Tekton is distinguished by its ability to operate entirely inside a Kubernetes cluster. It is capable of treating pipelines (which, in this case, we can define as workflow-based collections of tasks arranged in a graph either in sequential or parallel order) as standard Kubernetes resources.

In short, we can say that Tekton serves as a general-purpose, security-minded, Kubernetes-native workflow engine. Where CI/CD tools (such as Jenkins, the widely popularized automation tool) may require a dedicated server, Tekton’s K8S pedigree means that it doesn’t. 

Composable Primitives 

Its composable primitives (steps, tasks and pipelines) allow developers to orchestrate any type of sequential or parallel workload on Kubernetes. Tekton provides a standard, Kubernetes-native interface for defining these workflows, making them portable and reusable.

Tekton wasn’t initially its own standalone project or technology codebase; instead, it started life back in 2018 as a component of Knative (a Kubernetes-based platform for serverless workloads) and was called knative/build before being renamed in the same year.

As the project itself has matured into a fully-blown framework for Kubernetes-native CI/CD, reaching its stable v1.0 release for the core “Pipelines” component, i.e., the core components and building blocks required to build a CI/CD system – and Tekton Pipelines works by adding custom resources to a Kubernetes cluster.

By joining the CNCF as an Incubating Project, Tekton aligns itself more closely with the ecosystem it powers. It integrates deeply with other CNCF projects like Argo CD (for GitOps) and SPIFFE/SPIRE (for identity), and also Sigstore via OpenSSF (for signing and verification), creating a robust supply chain security story.

“One of the accomplishments I’m most proud of is the broad adoption of Tekton across open source projects, commercial products, and in-house platforms. Seeing teams rely on it in production and build on it within their own ecosystems has been especially rewarding. As a Kubernetes-native project that integrates naturally with other CNCF technologies, Tekton has benefited from close collaboration within the Cloud Native Computing Foundation community,” said Andrea Frittoli, Tekton governing board member.

Core Componentry

Tekton’s core components are as follows:

  • Pipelines: The core building blocks (Tasks, Pipelines, Workspaces) for defining CI/CD workflows.
  • Triggers: Allows pipelines to be instantiated based on events (like Git pushes or pull requests).
  • CLI: A command-line interface for interacting with Tekton resources.
  • Dashboard: A web-based UI for visualizing and managing pipelines.
  • Chains: A supply chain security tool that automatically signs and attests artifacts built by Tekton.

“What I’m most proud of is how Tekton has shown that CI/CD can be a true Kubernetes-native primitive, not just another layer on top. Seeing projects like Shipwright – itself a CNCF project – and Konflux build on Tekton as their foundation validates that vision. Building all of this alongside a diverse, multi-vendor community with Red Hat, Google, IBM, and many individual contributors has been one of the most rewarding open source experiences of my career,” said Vincent Demeester, Tekton governing board member

Demeester follows up and says that the future of Tekton is all about the presence of trusted artifacts as a means to change how tasks share data. He also points to a simpler developer experience through Pipelines as Code, and deeper collaboration with CNCF projects like Sigstore and Argo CD. 

Oversight Committee Rationale

The CNCF Technical Oversight Committee (TOC) provides technical leadership to the cloud native community. It defines and maintains the foundation’s technical vision, approves new projects, and stewards them across maturity levels. The TOC also aligns projects within the overall ecosystem, sets cross-cutting standards and best practices and works with end users to ensure long-term sustainability. As part of its charter, the TOC evaluates and supports projects as they meet the requirements for incubation and continue progressing toward graduation.

Tekton’s progression to CNCF incubation is thought to be a reflection of the project’s strong multi-vendor governance and deep alignment with CNCF projects focused on GitOps, identity and software supply chain security.



from DevOps.com https://ift.tt/YfKoxrb

Comments

Popular posts from this blog

How to End This Pandemic, and Prepare for the Next One

How to End This Pandemic, and Prepare for the Next One By Corinne Purtill from NYT Business Day https://ift.tt/37QYsl3 Coronavirus (2019-nCoV), Vaccination and Immunization, United States

Attaching Evidence to Alerts: an Enrichment Sidecar for Alertmanager

Every on-call engineer knows the ritual. A page lands in Slack: the 5xx rate on a service is above the threshold. The message tells you that something is wrong and nothing about what. So you open Kibana or Loki in another tab, set the time window to the last few minutes, filter by the service, and start reading. In my team this took two or three minutes on every alert, and these are the worst minutes of the incident, because nothing is being diagnosed yet. The obvious request is to put the last few error lines into the alert message itself. I tried to do this inside Alertmanager, and it cannot be done there. It helps to understand why before building anything around it. Why Alertmanager Cannot Do It Alertmanager renders notifications through Go templates, and a template can only use what is already attached to the alert: the labels and the annotations which Prometheus put there when the rule fired. There is no mechanism which would call Elasticsearch, Loki or any other HTTP API at t...