Nvidia has published a preview of NVKE, its own Kubernetes engine, on GitHub under Apache-2.0. The pitch is straightforward: operators of GPU datacentres should be able to sell Kubernetes as a managed service the way AWS sells EKS — with Nvidia's stack underneath.

Architecturally, NVKE is a management cluster that carves isolated workload clusters out of bare-metal servers on request. Each tenant cluster gets its own control plane, its own etcd and its own node pools, with the control plane running on dedicated servers rather than as pods inside the management cluster. Operators scale node pools and roll out Kubernetes upgrades through a CLI called `nvkectl` or through NVKE's REST API.

The provisioning chain is deliberately GPU-blind: NVKE hands out servers without GPU or fabric software, and Nvidia's GPU Operator installs the drivers, container toolkit and device plugin afterwards, following recipes from the AI Cluster Runtime. New clusters get ovn-kubernetes as their network plugin; Calico survives only for existing installations. High-availability control planes need a virtual IP, which NVKE sets up with kube-vip — without it, the Kubernetes API is reachable only through the first control-plane node's address.

The preview's security posture is the part worth reading closely. The API accepts requests over unencrypted HTTP on port 30080 of each management node; putting TLS in front of it is the operator's job. Nvidia recommends exposing only the necessary networks and enabling JWT authentication against the operator's own identity provider — and then notes that authorisation is still missing: every admitted caller may create and delete every workload cluster. Backups, restore and a documented path from one NVKE release to the next are absent from the preview too.

The management cluster itself is an odd number of servers with TPM 2.0 — one, three or five — each of which is both a control-plane node and a host for the management plane. It does not manage itself: it will not update, scale or replace its own nodes.

NVKE is also tightly bound to Nvidia's infrastructure stack. By default it obtains servers through the Nvidia Infra Controller, NICo, which is itself a Kubernetes application needing at least three nodes — so a real-hardware deployment runs two management layers on top of each other. NICo isolates tenants with BlueField DPUs in the default configuration; nodes attest their identity via SPIFFE/SPIRE against their TPM. Node images and components come from a sibling project, Nvidia Kubernetes Recipes. The target audience is Nvidia Cloud Partners and large GPU operators already managing metal with NICo.

That raises the obvious comparison. Gardener and Kamaji already run customer control planes as pods inside a central cluster, with years of production use behind them, and Nvidia's architecture chooses the more expensive path of dedicated control-plane servers. What NVKE offers that they do not is the integration — DPU tenant isolation, TPM attestation, GPU Operator and AI Cluster Runtime wired in from the start, from the vendor that defines the GPU stack.

Anyone who wants to look before committing gets a local quickstart in which a mock NICo starts each workload-cluster node as a Docker container. It needs a Linux host with at least six CPUs, 12 GB of free RAM, 100 GB of disk, Docker and virtual TPM support; on macOS the evaluation runs inside a Colima VM. Nvidia gives no date for a production-ready release.

What is notable is the sequencing. Nvidia is building the management layer for GPU clouds before the market has decided whether it wants to buy that layer from a chip vendor. The preview does not answer that question — it only makes clear that Nvidia intends to ask it.