k0rdent Turns One: What a Year of Shipping a Cluster API Fleet Orchestrator Proves About Not Building Your Platform From Scratch

In February 2025, Mirantis launched k0rdent as an open-source bet that platform engineering's hardest problems — provisioning clusters, keeping every cluster's foundational services consistent, and seeing what all of it costs — could be solved once, declaratively, instead of re-solved by every team with scripts. Thirteen months later, the project's first-anniversary review reported the distance covered: from v0.1 to v1.7, three maturing components, and a line of sight to v2.0. Two months after that, a director at RBC Capital Markets described on the CNCF blog how his team runs more than 50 clusters across VMware and multiple clouds on k0rdent — inside a bank, under SOX, PCI-DSS, and Basel III.

That combination — a shipped year-one inventory plus a regulated production deployment at fleet scale — is rare enough to take seriously. The question this post answers is the one a small platform team should ask before adopting anything: which layers of fleet operations does k0rdent's first year prove you can now adopt off the shelf, and which should you still skip or build yourself? Here is the verdict up front; the evidence follows.

What year one actually shipped​

k0rdent frames itself as a "super control plane": one system that defines, deploys, and manages distributed infrastructure through templated YAML, split into three components with deliberately separate scopes. The anniversary post is unusually concrete about what each one gained in year one, so take it as an inventory, not a pitch.

KCM (Kubernetes Cluster Manager) is the cluster-lifecycle layer, built on Cluster API with k0s as the default distribution. In year one it went from prototype with narrow provider support to covering AWS, Azure, GCP, OpenStack, and VMware, and added the three things that separate a provisioning demo from an operations tool: full backup and recovery via Velero, standardized identity and authorization (an RBAC manager plus a Cluster Authentication custom resource, so access stops being configured five different ways across five environments), and anonymized usage telemetry — the unglamorous signal that a project has real operators whose behavior is worth measuring. The most significant architectural addition is the regional cluster concept: the management cluster keeps only control-plane API objects while regional clusters host infrastructure and hosted control-plane pods, so a failure or upgrade in one layer stops cascading into the other.

KSM (Kubernetes State Manager) answers "what do we put on the clusters, and how do we keep it consistent?" — the beachhead services (CNIs, CSIs, runtime dependencies) every cluster needs before workloads can run. It is template-driven through service-template custom resources, with intermediate Service Set objects that play the ReplicaSet-to-pods role for platform services, and a provider-based architecture so operators are not locked into one state-management backend. The default provider is SveltOS, chosen for multi-tenancy support and a lower GitOps-expertise floor; templates can also be sourced from Helm or Kustomize with Flux doing the reconciliation. The year-one capabilities that matter for day-two reality are service template chains (enforced upgrade paths, so version jumps go through a governed sequence instead of an uncontrolled leap), inter-service dependency enforcement (a service cannot deploy before its dependencies exist), and access control over how templates distribute across namespaces and teams.

KOF (k0rdent Observability and FinOps) is the telemetry-and-cost layer: OpenTelemetry collection, OpenCost visibility, VictoriaMetrics-family storage for metrics, logs, and traces, aggregation through a Prometheus proxy, Grafana dashboards plus the k0rdent UI, and Alertmanager alerting. Since February 2025 it shipped 14 releases. Two design choices stand out. First, auto-configuration by cluster role label: attach a label like KOF.cluster.role and the KOF operator rolls the observability stack onto that child or regional cluster automatically, with telemetry flowing child → regional → management for centralized querying. Second, multi-tenancy via tenant-ID labels (KOF.tenant.id), tying each tenant to isolated credentials and access scope — the kind of boundary that only gets built once teams with real governance requirements show up.

Proof it is not a demo: a bank runs 50+ clusters on it​

Feature inventories are cheap; production deployments under a regulator's gaze are not. The strongest independent evidence for k0rdent's year-one claims comes from Erick Bourgeois, Director and Head of Kubernetes Platform Engineering at RBC Capital Markets, who wrote up his team's stack in May 2026: more than 50 clusters spanning on-premises VMware and multiple clouds, operated under the auditability and drift-prevention requirements that SOX, PCI-DSS, and Basel III impose on capital-markets infrastructure.

RBC's three gaps will sound familiar to anyone past their third cluster: node configuration drift on long-lived VMs, multi-day manual cluster provisioning with no single source of truth, and DNS changes stuck behind a network-team ticket queue. Their answers map almost exactly onto k0rdent's three components plus two adjacent choices.

Kairos, the CNCF Sandbox immutable OS, gives every node a boot-from-OCI-image foundation with a CI pipeline that integration-tests each image against a live VM before publishing a tag. k0rdent, on Cluster API, models clusters as CRDs in a hub-and-spoke layout — one management cluster running k0rdent, k0smotron, and the CAPI controllers, with workload clusters running k0s, chosen because a self-contained single binary installs cleanly into an immutable image with no package manager or host-level assumptions. FluxCD reconciles the whole topology continuously, with k0smotron running even control planes as in-cluster workloads so nothing lives out-of-band. MetalLB and Traefik round out networking, and a homegrown Rust operator called bindy closes the DNS gap by managing zones and records as CRDs, cutting provisioning from hours to seconds.

The day-two numbers are the part worth quoting back to anyone who says declarative fleet management is ceremony for its own sake. Cluster provisioning went from a multi-day manual exercise to minutes from a standardized template. Cluster upgrades became a pull request: bump the desired Kubernetes version in a manifest, review, merge, let Flux apply it — no "who ran what command on which cluster" ambiguity. Compliance posture applies at creation time through CEL-based admission webhooks and uniform RBAC instead of being bolted on afterward. And the team is now building a spot-computing scheduler on top of k0rdent to absorb donated physical server capacity dynamically — the kind of second-order project that only happens when the fleet layer underneath is trusted.

Bourgeois is also honest about the price of admission, and any adopter should budget for it: immutable-OS adoption demands patience with enterprise integration (SSSD, NetworkManager, corporate CA chains all need explicit attention in the image), CRD-based management shifts responsibility left onto template review and governance, and the platform only pays off once the team invests in those review processes up front. "Just a YAML file" without governance becomes its own source of drift.

The honest audit for a small self-hosted fleet​

RBC operates at 50-plus clusters with a platform team and a compliance department. Most readers of this blog operate somewhere between one machine and a handful of them. So here is the per-layer audit the verdict table promised, translated down to that scale.

Cluster lifecycle: adopt the pattern, evaluate the tool. The core bet — clusters as reconciled CRDs instead of provisioned-by-script pets — holds at any scale, and it is the same bet a Cluster-API-based self-hosted PaaS already makes for its own machine fleet. KCM's year-one additions that transfer directly are Velero-backed recovery as part of lifecycle (not as an afterthought), a single Cluster Authentication CR instead of per-environment access snowflakes, and cluster templates that make "another environment just like staging" a minutes-long operation.

The honest caveat is provider coverage: the OSS roster is AWS, Azure, GCP, OpenStack, and VMware. There is no Hetzner or bare-metal-first path in the open-source tier — bare-metal provisioning is explicitly an Enterprise feature — so a fleet built on owned dedicated hardware cannot lift KCM wholesale today and should treat it as an architecture to mirror (CAPI + templates + GitOps reconciliation) rather than a binary to install.

Beachhead services: adopt the discipline, defer the machinery. Every fleet past one cluster eventually needs governed upgrade paths for its CNI, CSI, and runtime dependencies, and KSM's template chains plus dependency enforcement are the right shape for that problem. But the full provider-based state-manager apparatus — Service Sets, pluggable backends, cross-namespace template distribution — earns its complexity when you manage multiple cluster types for multiple teams. At one cluster type and one team, the same discipline fits in a Flux kustomization with pinned versions and an upgrade runbook. Adopt KSM's rules (no uncontrolled version jumps, dependencies before dependents, templates versioned in Git); defer its machinery until the fleet's variety demands it.

Observability and cost: borrow the rollout pattern immediately. This is the cheapest win in the whole inventory and it requires running none of k0rdent. The pattern is: a new cluster (or node pool, or tenant namespace) inherits its telemetry and cost collection by label, automatically, with aggregation flowing upward to one query surface. Whether your stack is Prometheus, VictoriaMetrics, or something else, label-driven onboarding plus a documented aggregation path kills the "we forgot to monitor the new environment" failure mode that bites every growing fleet exactly once before the fix. KOF's tenant-ID credential isolation is the part to copy second, the moment two tenants share one telemetry backend.

The gap to plan around: owned hardware. k0rdent's first year is a cloud-and-VMware story with OpenStack covering private cloud. A self-hosted platform on rented dedicated servers sits outside that triangle: no first-class OSS provider, and the roadmap energy is visibly pointed at Enterprise virtualization and AI-factory reference architectures rather than down-market bare metal. That does not invalidate the architecture — CAPI's provider model is precisely what would let a Hetzner-shaped provider slot in — but it sets expectations: for now, the borrowable parts are patterns and components (CAPI lifecycle, template chains, label-driven observability), not a turnkey installer for your fleet.

Since the anniversary: is the trajectory holding?​

A first-birthday post is a snapshot; six months later it is worth checking whether the roadmap executed. The signals since March point to yes, with the center of gravity shifting toward AI infrastructure. In May 2025 Mirantis had already shipped k0rdent Enterprise and k0rdent Virtualization, unifying VMs, containers, and AI workloads on k0s; the November 2025 Enterprise release extended VM support into Mirantis Kubernetes Engine for k0rdent.

The open-source line kept shipping through v1.8, and in July 2026 both k0s and k0rdent achieved CNCF Certified Kubernetes AI Conformance at v1.35 — a meaningful credential now that the workloads fighting for fleet capacity include GPU-backed inference and agent sandboxes, not just web services. The v2.0 roadmap the anniversary post pointed at is being built in public, with the docs treating installation, upgrades, storage, and scaling as first-class subjects rather than README afterthoughts.

None of that changes the small-fleet audit above — if anything, the AI-factory and virtualization emphasis confirms that k0rdent's center of gravity is enterprise breadth, and the down-market move is to borrow its proven patterns, not to wait for it to shrink to your size.

From tool to operating model​

The anniversary post's best line is its quietest: k0rdent's first year is a story of converging three historically separate platform concerns — clusters, state, observability and cost — into a single repeatable operating model. RBC's deployment is that sentence with receipts: one Git repository as the source of truth, FluxCD as the reconciliation engine, and drift prevented structurally at the node, cluster, and network level instead of managed operationally after the fact.

For a team deciding build-versus-adopt this quarter, the lesson is narrower and more useful than "use k0rdent." It is that the undifferentiated parts of fleet operations now have reference implementations with production proof: CAPI-backed lifecycle with recovery built in, governed upgrade paths for platform services, label-inherited observability with tenant isolation. Building those from scratch in 2026 is not engineering, it is nostalgia. Build where your fleet is actually different — your hardware, your tenant model, your compliance boundary — and adopt everywhere the anniversary inventory already has answers.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.