Possible structure:

• what is kpt?
• why is it unique / how does it compare to / relate to other similar tools?
• high level description of example use cases - simple, complex, telco, non-telco
• Current status and plans
• Call to action - join and help

Initial draft ...

(re)Introducing kpt - your toolchain for infrastructure automation

Spring is coming in the Northern hemisphere (some say it is already here) and with it comes a sense of renewal and hope. As such, it seems like a perfect time to discuss the kpt project, which is now emerging from a winter of under-engagement into a bright future of development and new features.

What is kpt?

The opening tagline of the kpt documentation describes it as

... a package-centric toolchain that enables a WYSIWYG configuration authoring, automation, and delivery experience, which simplifies managing Kubernetes platforms and KRM-driven infrastructure at scale by manipulating declarative Configuration as Data."

Sometimes it feels like this was written by a lawyer, or a consultant on a per-industry-buzzword contract. Let's break it down.

package-centric

Kpt works on packages - specifically bundles of Kubernetes Resource Model (KRM) files, declarative YAML manifests that define the desired state of cluster resources for Kubernetes (or Kubernetes Operator extensions) to continuously reconcile. These are pretty lightweight - they can be a directory on your computer, a zip file, or (most typically, given the GitOps nature of kpt) the contents of a git repository or git repository subfolder.

toolchain

Kpt is a CLI, but also provides a number of tools - validators and mutators - that can be executed in a kpt pipeline to verify and / or modify the contents of a kpt package

WYSIWYG

What You See Is What You Get is more typically associated with graphical editing tools or print-friendly editors. In this context, it refers to the fact that the kpt file contents you have at any point in time are exactly the resources that will end up in your cluster - they are not modified out-of-band (TBD - is this an accurate description)

configuration authoring, automation, and delivery

kpt supports the full lifecycle of a package of kubernetes resource descriptors. Initial authoring can provide basic configuration templates while kpt pipelines automate the process of specializing those templates into site-specific parameterized packages, potentially across hundreds of different sites. Kpt also supports the package review and validation processes required to ensure configuration correctness before applying to live networks.

managing Kubernetes platforms and KRM-driven infrastructure

Kpt's primary raison d'etre is the management of Kubernetes-native constructs - manipulating KRM files which enable Kubernetes tooling to robustly and autonomously deploy clusters, provision workloads into clusters and even manage the day-to-day configurations of those workloads.

manipulating declarative Configuration as Data

Configuration as Data is an approach where system and application configuration is stored, managed, and versioned as plain data, rather than embedded in code or imperative scripts, enabling reproducibility, automation, and declarative infrastructure management. Kpt supports manipulating these via kpt pipelines, which automate the specialization and validation of these configurations.

Why do we need it?

Given the proliferation of infrastructure orchestration and configuration management tools out there, it's a fair question to ask - why kpt? There are a few reasons why we feel the kpt project has a unique value in the Kubernetes automation ecosystem.

Firstly, kpt's "in-place" update paradigm differs from other tools, such as Kustomize, which generate final manifests on the fly by overlaying patches on a base configuration. It's our view that being able to examine, and optionally approve, the final configurations before applying simplifies troubleshooting and fault resolution. This is what we describe as "WYSIWYG".

Secondly, the paradigm of "configuration as data" is fundamentally different to the "configuration as code" approach many other tools adopt. By clearly separating configurations in packages (pure KRM models) from the business logic which transforms them (KRM functions), there is a clean separation of concerns. Data files describe precisely the desired state, and native tooling can process and validate them. This reduces side effects, drift, and complexity. Connecting with the "in-place" paradigm means the pure configuration data that precisely describes the desired state is available for auditing and verification, reducing operational risk and making deployments more deterministic.

lastly, kpt doesn't try to solve all problems. It is a simple tool with a core set of capabilities, leveraging an extensible library of functions to support common needs and allowing users to bring their own business logic. It integrates well with other gitops tools - ArgoCD, Flux, Helm and Porch to name a few - allowing it to coexist well in the broader Kubernetes ecosystem.

Use cases for kpt

TBD - 5GC, OAI, Enterprise ...

Current status and plans

TBD

Join us!

TBD