Executive Summary
NVIDIA published NVKE as an Apache 2.0 preview, a management plane that provisions isolated Kubernetes clusters on bare-metal GPU fleets and hands them to an operator’s customers. Each workload cluster gets its own control plane, its own etcd and its own node pools, and nodes attest with their TPM before receiving a join credential. That is real multi-tenant work, and it lands on the layer where Rancher, Cluster API and every neocloud’s homegrown controller already sit.
The limits page is what makes it worth reading. NVIDIA says the preview is not for production, then documents why in unusual detail. The management cluster cannot upgrade, scale or replace its own nodes, and no procedure exists for moving management-plane services to a later release. Customers receive the admin kubeconfig. Every node built from one full-disk-encryption image inherits the same volume key, with a bootstrap passphrase that stays readable in the bootloader configuration. The isolation is real at the control plane. The operational defaults sit everywhere else, and they decide whether an operator can run it.
NVIDIA shipped a Kubernetes engine that is not a Kubernetes distribution. NVIDIA NVKE, short for NVIDIA Kubernetes Engine, is a management plane, and its documentation spends more room on what it will not do than on what it will.
The shape is a factory. A temporary seed cluster bootstraps a management cluster. That cluster asks NICo, NVIDIA’s bare-metal controller, for machines through the Cluster API provider CAPNICo. It provisions them, forms a workload cluster and hands the cluster to a customer. Nodes attest through SPIFFE/SPIRE with their TPM before they get a join credential.
NVKE uses upstream Kubernetes, kubeadm and Cluster API, and the foundation has certified that it creates conformant clusters. So NVIDIA is not competing on what Kubernetes does. It is competing on who hands out the clusters.
The tenant gets the admin kubeconfig
The limits page is blunt about access. A workload cluster is handed to a customer through its admin kubeconfig. No scoped or read-only customer role is described at preview. For an operator selling managed Kubernetes, that makes every tenant a cluster administrator, which is fine inside one cluster and a problem the moment two share a fleet.
The isolation is serious. Separate control planes, separate etcd, TPM-anchored node identity, optional per-cluster etcd encryption. That is the part an operator cannot build in a quarter, and it is why this is not vapor. The gap sits one layer up, where operability is decided.
Two defaults that would fail an audit
The full-disk-encryption images are the sharpest example, because NVIDIA documents the failure. Each image build generates a new volume encryption key, and every node built from that image inherits the same key. On first boot the node sets up TPM-based unlocking and removes the bootstrap passphrase, a public documented value, but it does not generate a per-node key or re-encrypt the volume. Anyone holding the original image and that passphrase can recover the key that decrypts every node built from it, even after TPM enrollment.
The passphrase also stays in the bootloader configuration as a luks.key kernel parameter after the bind. NVIDIA’s instruction is to use those images for evaluation only and not to rely on them for data-at-rest confidentiality. That is a disclosure, not a bug report.
The telemetry default is quieter and worse. NVIDIA’s telemetry pipeline collects metrics, logs and traces over OpenTelemetry, and the default backend keeps data in memory and gives anonymous users admin access to Grafana. The docs say to point it at your own backend for anything else. An operator who installs the preview, leaves the default and exposes the management plane has published their fleet’s telemetry with a login attached.
The management plane cannot upgrade itself
The management cluster does not manage itself. It does not upgrade, scale or replace its own nodes, there is no procedure for moving management-plane services to a later NVKE release, and no backup and restore for the management cluster or the management plane.
That limit decides the product. A control plane you cannot upgrade in place is a control plane you rebuild, and rebuilding the component that owns every tenant cluster is a change window most operators will not accept at preview quality. The repository is moving quickly, past 1,500 commits.
NICo is the only infrastructure provider the preview documents, which is coherent once you see NVKE as the Kubernetes layer of DSX OS, NVIDIA’s software stack for AI factories. If your bare metal is not on NICo, you are not the intended user yet.
The honesty is the signal. This is a reference implementation for NVIDIA Cloud Partners and platform vendors who will finish the operational half themselves, not something an enterprise adopts on a Tuesday. NVIDIA brought the control-plane isolation. Tenant lifecycle, key management and fleet upgrades are what it left for you.
Three questions to ask of any preview. Does the bare-metal fleet run on NICo today? If a tenant holds admin on their own cluster, what stops them reaching the shared physical layer? And can you rebuild the management plane from scratch inside one maintenance window?
Related reading. We covered NVIDIA’s runtime recipe versioning in Your GPU Cluster Has 268 Settings.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.