Skip to content

v1.0.0

31st of August, 2026

After the BETA stage, kMetal turns GA (General Availability): the Kubernetes distribution for AI Factories and Cloud Builders is ready for production. This release takes multi-tenancy all the way down to the metal. Every tenant gets a real Kubernetes cluster of its own: its own hosted Control Plane, its own KVM-isolated worker nodes, its own private network, its own storage quota, and its own Elastic IPs. Every layer, from bare-metal bootstrap to GPU pools, is declared as a Kubernetes resource and provisioned through a single API: no hypervisor console, no networking console, no Ansible, no Terraform. Virtualization without the Hypervisor tax, Kubernetes without the Control Plane tax.

Features

  • KM-001: Control Plane Management via Hosted Control Planes

    Every tenant gets its own Kubernetes control plane backed by Kamaji: instead of dedicated machines per tenant, they run as lightweight pods on a shared set of management nodes, each with its own isolated cluster DataStore.

  • KM-002: Dedicated Tenant Clusters

    Each tenant gets a real, standards-compliant Kubernetes cluster of their own with full administrative control, their own API Server, upgraded on their own schedule: not a shared slice of someone else's.

  • KM-003: Compute Isolation

    Each tenant's worker nodes run in their own Virtual Machines (KVM) with a separate operating-system kernel: strong isolation built into the platform.

  • KM-004: Network Isolation

    Tenants can self-provision their own private and isolated network with regards on multi-tenancy: Vpc, Subnet, External IPs.

  • KM-005: Kubernetes Native Management

    Each Platform resource (compute, networking, control planes, and cluster operations) is defined as a Kubernetes resources (CRD) and managed through one interface and one workflow. No separate virtualization or networking consoles.

  • KM-006: Declarative Provisioning

    Clusters are created and managed through the industry-standard Kubernetes provisioning API (Cluster API), the same open approach the wider ecosystem uses.

  • KM-006: Delivery & Lifecycle Management

    The whole platform is defined as a Custom Resource Definition and installed, upgraded, and kept in sync automatically from a single source of truth. Drift changes are immediately identified, and fixed to maintain the desired state.

  • KM-010: Turnkey Tenant Clusters

    A complete tenant cluster (control plane, worker VMs, addons, storage integration, and isolated network) is created end to end in a single step.

  • KM-011: Standardized Cluster Blueprints

    Reusable blueprints define a standard cluster template (operating system, Kubernetes version, storage, networking, policies, and required add-ons) applied consistently across the fleet.

  • KM-012: Bring-Your-Own Storage

    Tenant clusters get persistent storage from whatever enterprise storage you already run with Quota enforcement: local disks, SAN, Ceph, and more.

  • KM-013: Tenant Workload Load Balancing

    When a tenant's application asks for a public endpoint, the platform assigns an external IP automatically: the cloud load-balancer experience, on your own hardware, with explicit (direct IP assignment) or implicit (IPAM) mode, and Quota enforcement to prevent IP exhaustion.

  • KM-014: Cluster Fleet Management

    Operate hundreds of tenant clusters as one fleet, automatically keeping each cluster to its approved configuration and required add-ons, and handling routine day-2 work like patching and certificate renewal.

  • KM-016: Self-Service Provisioning

    Tenants create and manage their own environments within limits the Platform Administrator sets: approved versions, quotas, network rules, and required components.

  • KM-017: Tenant Cluster Access

    Each tenant reaches its own clusters from outside the platform through a dedicated, ready-to-use access point.

  • KM-018: Highly Available Networking

    The tenant networking layer runs redundantly: no single node failure can cut connectivity or block network changes.

  • KM-019: Immutable Node OS

    Worker nodes run a locked-down, versioned and immutable operating-system image, updated by swapping in a new image rather than patching in place.

  • KM-020: Rolling Upgrades

    Tenant control planes are upgraded by standing up the new version alongside the old and switching over, and Kubernetes versions roll out across the fleet through the normal workflow.

  • KM-021: Operator Console

    A web console for operators to view and manage clusters, networks, and tenants — including create and edit — not just the command line.

  • KM-022: Independent External Networks

    Each tenant can connect to its own external network, so different tenants can have different upstream connectivity (ProviderNetwork).

  • KM-024: Tenant Cluster Backup & Restore

    Backup and restore of tenant control-plane state and persistent data.

  • KM-028: Secure GPU Fleet Management

    Provisioning and pooled management (with Quota Enforcement) of GPUs shared across Tenant clusters.

  • KM-040: Isolated Per-Tenant Storage

    Each tenant's storage is walled off from every other tenant's — capped usage, and the storage system's admin credentials never reach the tenant.

  • KM-044: Reserved / Elastic Tenant IPs

    Tenants reserve stable public IP addresses that stay the same even when their services are recreated — the cloud Elastic IP model.

  • KM-046: Multi-Subnet per VPC

    A tenant network (VPC) is partitioned into multiple subnets — for example separate application and data-store segments within one tenant.

  • KM-048: Under-Cluster Bootstrap

    The platform's own management cluster is stood up on bare metal on a standard operating system with a lightweight, repeatable installer — the default for typical deployments.

  • KM-049: Multiple Clusters per Tenant

    A single tenant can own several Kubernetes clusters (for example dev, staging, prod, DR) under one identity and network.

  • KM-050: Self-Service Networking

    Tenants and operators set up their own private networks on demand — networks, subnets, and public IPs — by simple declarative request, much like creating a VPC in the cloud.

  • KM-053: Undercluster Node Upgrades

    Upgrading the undercloud Kubernetes version directly from Kubernetes: no need to create Ansible or Terraform automation.

Improvements

N.R.

Bug Fixes

N.R.

Known Issues

N.R.

Upgrade Notes

N.R.