NVIDIA Kubernetes Engine turns owned GPU servers into managed Kubernetes clusters

NVIDIA has opened up a project called NVIDIA Kubernetes Engine (NVKE), a management plane that creates and operates Kubernetes clusters on bare-metal GPU servers that the operator owns. According to a post on dev.to, the aim is to let platform teams run something close to a managed Kubernetes service on their own hardware, instead of maintaining glue scripts for provisioning machines, forming clusters, isolating tenants and replacing broken nodes.

The project is written in Go and licensed under Apache-2.0. It is currently a preview: APIs, configuration and behavior can change between releases, and the project does not recommend it for production workloads.

How it is structured

An installation has two kinds of cluster. A temporary seed cluster bootstraps a management cluster using the nvkectl command line tool, and installing the management plane services is a separate step afterwards. The management cluster then provisions workload clusters, each with its own Kubernetes control plane, its own etcd and its own node pools.

Machine provisioning goes through NVIDIA Infra Controller (NICo), which the dev.to article identifies as the only supported infrastructure provider in the preview. The management plane combines NICo, Cluster API and a node agent, and describes itself as a factory for Kubernetes clusters rather than a Kubernetes distribution or a Cluster API flavour.

Users talk to their workload clusters with plain kubectl and the standard Kubernetes API, without needing to know NVKE exists underneath.

Lifecycle, identity and builds

NVKE handles the cluster lifecycle: requesting clusters through the NVKE API or nvkectl, creating and scaling node pools, upgrading Kubernetes and replacing nodes. Some of these steps are manual in the preview.

On the security side, nodes attest themselves through SPIFFE/SPIRE using their TPM before they receive join credentials, so a machine has to prove what it is before it can join a cluster. Encryption of etcd data is available per cluster.

A companion project, NVIDIA Kubernetes Recipes (NVKR), builds node images and NVKE components from pinned inputs; NVKE deploys those artifacts while NVKR owns the build and release evidence.

Trying it without GPUs

Evaluation does not require GPU hardware or an NVIDIA account. The local quickstart creates a development management plane and a workload cluster on simulated machines. The stated requirements are a Linux host or VM on amd64 or arm64, at least 6 CPUs, 12 GiB of free memory, 100 GiB of free disk, Docker and virtual TPM support. On macOS, the evaluation runs inside a Colima virtual machine instead.

A real installation means bringing your own machines, networking, node images, registries and NICo access. The project publishes documentation on NVIDIA's docs site, and the code can be built from the public repository with Go 1.27.3 and GNU Make 4 or later.

Caveats to read twice

The dev.to post highlights several limitations worth knowing before an evaluation:

API authentication is disabled by default and the API speaks plain HTTP after installation, so authentication and protected access must be configured before any callers are let in.

The management cluster does not upgrade, scale or replace itself, and there is no management-plane upgrade procedure or backup and restore procedure yet.

FDE node images provide no data-at-rest confidentiality and are intended for evaluation only.

With NICo as the sole provider, hardware managed in any other way is unsupported for now.

Node replacement and Kubernetes upgrades include manual steps and preview limits.

Why it matters

GPU servers are expensive and scarce, and teams that share a pool of them usually choose between one big shared cluster with namespace-level isolation and bespoke automation per tenant. NVKE targets a middle path: dedicated control planes and etcd per workload cluster, running on hardware a single organisation owns, with TPM-backed node identity suited to bare-metal multi-tenancy. If NVIDIA matures the project, it could become a standard building block for internal GPU cloud offerings, where each team or customer gets something that feels like managed Kubernetes on dedicated GPU capacity.

For now, the gaps matter. Unauthenticated APIs by default, no management-plane upgrades or backups, and a single infrastructure provider make NVKE an evaluation target rather than something to put in front of production traffic. Platform teams building shared GPU infrastructure should test it on simulated machines, read the known limitations, and revisit once the preview restrictions lift.