k0rdent Turns One: A Super Control Plane Comes of Age

One year can be a long time in cloud native, and an even longer time in platform engineering, where expectations evolve quickly and “good enough” rarely stays that way for long. 

We recently celebrated the one-year anniversary of the k0rdent open source project, and hosted a community meeting to let us reflect on what the project set out to do, what it shipped in its first year, and where it’s headed next.

The message is consistent: k0rdent provides a “super control plane”, a single source of truth for orchestrating modern platforms across distributed infrastructure, including multi-cloud and bare-metal environments.  

In its first year, k0rdent moved quickly from v0.1 (February 6, 2025) to v1.7, with active community growth and a clear line of sight toward a k0rdent v2.0 roadmap.

The Vision: Solving Platform Engineering Complexity through a Single Control Plane 

At its core, k0rdent is designed as a solution for modern platform teams that need to manage infrastructure and platform layers consistently, even when the underlying environments vary wildly.

The project’s guiding concept is a super control plane: a central system that can define, deploy, and manage distributed infrastructure and services using a templated YAML-driven approach. This design aims to provide flexibility (fine-tuning clusters and nodes through templates) while keeping standardization and repeatability front and center.

In the webinar, the team broke the platform engineering problem down into three parts:

1) Cluster management

How clusters are provisioned, upgraded, secured, and recovered at scale.

2) State management

How platform “beachhead services” (core components like CNIs, CSIs, and runtime dependencies) are installed, upgraded, governed, and kept consistent across fleets.

3) Observability and FinOps

How metrics, logs, traces, alerts, and costs are collected, aggregated, and presented to support both operational excellence and financial accountability.

Architecture in Practice: Three Components, One Story

The k0rdent architecture maps each platform problem to a dedicated component:

• KCM (Kubernetes Cluster Manager): Cluster lifecycle management. Built on Cluster API, k0s, and supporting providers.

• KSM (Kubernetes State Manager): Add-ons and runtime state across clusters. Built around a provider-based model; integrates Flux and SveltOS as the default state management provider.

• KOF (k0rdent Observability and FinOps): Full-stack observability and cost visibility. Built with OpenTelemetry, OpenCost, and components like Prometheus/Grafana, with storage options including the Victoria Metrics family (metrics/logs/traces).

This three-pillar structure keeps the system comprehensible: each component has a dedicated scope, yet the whole product is designed to feel unified for platform operators.

KCM: From Prototype to Production Readiness

During the community meeting, k0rdent contributor Ekaterina Kazakova walked through how KCM evolved from an early prototype with limited provider support into a production-ready cluster management layer.

Full backup and recovery

A major milestone was integrating Velero for complete backup and recovery, turning cluster lifecycle management into something that covers resilience and restorability, not just provisioning.

Identity, access, and standardized authorization patterns

The team improved how cluster identity is distributed and managed, and introduced mechanisms to standardize authorization across managed clusters. This included integration with an RBAC manager and a custom resource for Cluster Authentication, which reduces fragmentation in how access is handled across environments.

Anonymized telemetry

KCM introduced anonymized telemetry to understand real-world usage patterns and inform product decisions. It is an indicator that the project is maturing into operational reality, not just architectural aspiration.

Regional clusters

One of the most significant architectural additions introduced in the KCM roadmap is the concept of regional clusters:

• A management cluster focuses on the control plane and API objects.

• Regional clusters host infrastructure and hosted control plane pods.

This separation improves isolation, scalability, and fault boundaries, avoiding the operational risk of having everything depend on one cluster.

Provider support and release cadence

Over the year, KCM expanded support across providers including AWS, Azure, GCP, OpenStack, and VMware, and shipped releases on a frequent cadence with a stated goal of moving toward monthly or bi-weekly releases. Near-term priorities include stability improvements, broader integrations, and improved operator experience.

KSM: Making “Beachhead Services” Governable and Repeatable

If KCM answers the question, “How do we create and manage clusters?”, KSM answers “What do we put on them, and how do we control it over time?”

k0rdent contributor Wahab Ali described KSM as the layer responsible for managing the foundational platform components, which are the beachhead services every cluster needs before application workloads can run. The system is template-driven, using service template custom resources to define what gets installed and how.

Provider-based architecture, with Service Set objects

KSM uses intermediate Service Set objects to manage state, analogous to how Kubernetes uses ReplicaSets to manage pods. Different providers can plug into the system via adapters, which means the architecture can evolve without locking operators into a single operational model.

SveltOS as the default provider

By default, KSM uses SveltOS as its state management provider. Key advantages include multi-tenancy support, reduced dependence on GitOps-specific expertise, and a pluggable model that still allows alternative state managers. KSM also supports templates sourced via Helm or Kustomize, backed by Flux tooling.

Capabilities built for platform operations

KSM shipped capabilities designed for the day-to-day realities of running platforms at scale:

• Service template chainsEnforcing upgrade paths and enabling sequential or automated upgrades rather than uncontrolled version jumps.

• Inter-service dependency enforcementPreventing a service from deploying until required dependencies are installed, reducing fragile rollouts.

• Access control and template distributionGoverning how templates are shared across namespaces and teams.

The team also discussed future design considerations: making it possible for individual teams to manage their own service scopes, rather than requiring cluster-wide permissions. It's a small architectural shift with real governance implications for organizations running shared platforms.

KOF: Observability and FinOps at Full-Stack Depth

The KOF component, covered by contributors Denis Ryzhkov and Aleksei Larkov, is a full-stack observability and FinOps solution that integrates deeply into the k0rdent model. Since February 2025, KOF has shipped 14 releases with hundreds of commits spanning new features and fixes.

What KOF provides

KOF is designed to cover the full spectrum:

• Telemetry collection backed by OpenTelemetry

• Cost visibility via OpenCost

• Storage via VictoriaMetrics family (metrics, logs, traces), with third-party storage options supported

• Aggregation through a Prometheus proxy layer

• Visualization via optional Grafana dashboards and the k0rdent UI

• Alerting support via Alertmanager

Auto-configuration via cluster role labels

One of KOF’s most operationally useful features is its auto-configuration model. Through multi-cluster services and the KOF operator, the observability stack can be automatically applied to child and regional clusters by attaching a specific cluster role label (e.g., a KOF.cluster.role label).

This enables a scalable pattern where:

• Child clusters send telemetry and cost data to regional clusters

• The management cluster queries that regional data for centralized visibility

In platform terms, this is a shift from “every cluster is a one-off” to “every cluster inherits an operating model.”

Multi-tenancy enforcement

KOF’s new multi-tenancy feature enforces credential isolation through a unique tenant ID label (e.g., KOF.tenant.id). Each tenant is tied to its own credentials and access scope, rather than relying on shared or loosely separated authentication. That kind of boundary tends to get built when teams with real security and governance requirements show up, and its inclusion here is a signal of production readiness.

Documentation depth

The KOF documentation was called out as extensive, covering architecture, installation and upgrades, storage approaches, and scaling guidelines. That emphasis on documentation is especially important for a system spanning multiple operational domains (clusters, state, observability, cost).

What This First Year Suggests About k0rdent’s Trajectory

Across KCM, KSM, and KOF, the anniversary update carried recurring themes:

• The project is shipping quickly (0.1 → 1.7 in one year, with frequent releases across components).

• The architecture is opinionated but modular, using provider patterns and established OSS building blocks.

• Security and tenancy boundaries are moving from “nice-to-have” to “built-in” defaults.

• Operational scalability is being designed explicitly, through regional clusters and automated observability rollout.

In closing remarks, contributors described seeing k0rdent transform into a robust technology that unifies service management and observability. Community manager Prithvi Raj echoed feedback from community members who value seeing Cluster API, SveltOS, and OpenTelemetry brought together coherently within k0rdent.

Closing Thoughts: From “Tool” to “Operating Model”

A one-year anniversary webinar can easily become a victory lap. This one felt more like an operational checkpoint: what shipped, what improved, what hardened, and what needs to scale next.

k0rdent’s first year story is not just about features; it’s about converging three historically separate platform concerns (clusters, state, observability/cost) into a single, repeatable operating model. If the team continues to balance velocity with stability and usability, the “super control plane” framing may become less of a slogan and more of a practical category.

How to Get Involved

If you’re interested in helping shape the future of k0rdent, here are ways to get involved:

• Start with the contributing guide in the main repository

• Look for “good first issues” across the component repositories (KCM, KOF, and others)

• Contribute to the service catalog, tooling templates, providers, and documentation

• Participate in roadmap discussions through GitHub Discussions and issues

• Join the project community on CNCF Slack and participate in community calls

As k0rdent prepares for a larger contributor base, the maintainers also plan to nominate additional maintainers and reviewers as community participation grows.