kpt Enters CNCF Sandbox to Treat Kubernetes Manifests as Pure Data

The Cloud Native Computing Foundation (CNCF) has accepted kpt into its sandbox stage as part of a push to reframe how teams manage cloud infrastructure. Rather than relying on template engines or overlay patches that assemble configurations on the fly, kpt packages declarative Kubernetes Resource Model (KRM) files as static datasets.

According to an introductory post highlighted by habr, the core philosophy is Configuration as Data (CaD). In this model, configuration files are treated as direct representations of what should exist in a cluster. Built-in mutators and validators can inspect, validate, and alter the YAML files in place within Git repositories, directories, or archives before any deployment begins.

The obvious point of comparison is Kustomize. While Kustomize builds final manifests dynamically via overlays during rendering, kpt insists on in-place updates. The intention is WYSIWYG predictability: whatever file sits in the reviewed branch is exactly what gets sent to the API, allowing linting, diff reviews, and policy checks without running execution scripts or guessing what a template will spit out.

The project is already in practical use in complex deployments like Nephio, which orchestrates telecommunications workloads on Kubernetes, as well as smaller integrations like Headlamp, Nginx, and WordPress samples. It is also designed to plug into existing continuous delivery tools such as ArgoCD, Flux, and Helm.

However, kpt remains an early-stage tool. The team has not yet shipped a stable 1.0 release. The stated roadmap focuses on stabilizing APIs, overhauling sparse documentation, improving pipeline performance, and adding native secrets management alongside multi-cluster support.

Source: habr

Primary source: CNCF