the short version
- NVKE creates many isolated workload clusters from one management plane that the operator runs. Each cluster has its own control plane, etcd and node pools.
- At preview, NVIDIA Infra Controller (NICo) is the sole compatible infrastructure provider, so an installation depends on NICo for machine provisioning.
- After installation, API authentication is off and the API uses plain HTTP. The management cluster does not upgrade, scale or replace itself, and there is no management-plane upgrade or backup/restore procedure.
- The README does not describe GPU scheduling, driver or GPU Operator handling, or supported GPU models, so it gives no basis for a direct comparison with GPU Operator setups.
NVIDIA Kubernetes Engine (NVKE) is an Apache 2.0 preview from NVIDIA. Platform teams install its management plane on their own NVIDIA GPU infrastructure and use it to create and operate isolated Kubernetes workload clusters for customers, each with its own control plane, etcd and node pools. Machines are provisioned through NVIDIA Infra Controller (NICo), the sole compatible infrastructure provider at preview. The README does not cover GPU scheduling, the GPU Operator, drivers or supported GPU models, and NVIDIA does not recommend NVKE for production workloads.
The README's summary line is 'Run a managed Kubernetes service on your own NVIDIA GPU infrastructure.' The operator runs the NVKE management plane, and customers use their clusters through the Kubernetes API and kubectl. The repository shows 1,537 commits, 255 stars, 10 watchers and 71 forks. The README warns that APIs, configuration and behavior can change between releases.
NVKE deploys a management cluster and workload clusters
The README says NVKE is not a Kubernetes distribution and not a Cluster API flavour, and calls it a self-hosting factory. A throwaway seed cluster stands up a management cluster, and the management plane on that cluster then provisions and lifecycle-manages isolated workload clusters on demand. The nvkectl CLI forms the management cluster from the temporary seed cluster. Installing the management-plane services is a separate step.
a self-hosting factory for Kubernetes clusters
- Management cluster: runs the NVKE management plane and the infrastructure controllers.
- Workload clusters: run customer applications. The management plane creates and operates them through NICo, Cluster API and the node agent.
- Lifecycle operations: create, scale and delete node pools, upgrade Kubernetes, and replace nodes. The node pool guide documents manual steps and preview limits on replacement and upgrades.
- Build output: make build writes nine binaries to bin/: agent, updater, controller, nvkectl, capd-reboot-controller, nvke-os-image-check, management-engine, tenant-api and operator-api. The node agent runs on Linux.
Node identity runs on TPM and SPIFFE/SPIRE
Before a node receives join credentials, it attests through SPIFFE/SPIRE using its TPM. Encryption of etcd data is available per cluster. One commenter on Hacker News said NVKE wipes and re-attests each host between tenants. The README only documents attestation before join, so it does not confirm that description of the reuse cycle.
The README also says the FDE node images are for evaluation and provide no data-at-rest confidentiality. Teams that need encrypted tenant disks cannot rely on the shipped images for that. One Hacker News commenter was otherwise critical of the project but said the SPIFFE/TPM integration and the kind-based bootstrapper for the management cluster were the parts worth taking.
The README is silent on drivers and scheduling
The README does not mention the GPU Operator, a device plugin, a GPU-aware scheduler, GPU drivers or a list of supported GPU models. It does say that a companion project, NVIDIA Kubernetes Recipes (NVKR), builds node images and NVKE components from pinned inputs. NVKE deploys those artifacts, and NVKR owns their build and release evidence. The README does not say where GPU drivers come from or how they are installed.
Networking gets a similarly brief treatment. For a real installation, the operator supplies the machines, networking, node images and registries, and configures access to NICo. One Hacker News commenter said the stack relies on NICo and BlueField to set up isolated tenant networking, but the README does not name BlueField, so that is a practitioner's reading rather than a documented requirement. The README points to a platform and version reference that lists validated combinations and pinned dependencies, and that reference is not in the source material here.
Preview defaults leave the API open over HTTP
After installation, API authentication is off and the API uses plain HTTP. The README tells operators to configure API authentication and protected access before admitting callers.
- The management cluster does not upgrade, scale or replace itself.
- There is no management-plane upgrade procedure and no backup/restore procedure.
- FDE node images provide no data-at-rest confidentiality.
- NICo is the only compatible infrastructure provider.
NVKE manages the workload cluster lifecycle, but the README documents no upgrade, backup or restore path for the management plane itself. Teams evaluating the preview should plan for the management cluster on that basis.
How NVKE compares with GPU Operator setups
The sources do not compare NVKE with the GPU Operator on stock Kubernetes or with managed EKS or GKE. The comparison has to come from what NVKE is built to do. It targets an operator who hands out separate clusters to customers on GPU machines provisioned through NICo. The README does not address a single team running workloads on one cluster.
Commenters on Hacker News raised objections about fit and scope. One reply countered that much of the negativity came from people who manage a few Kubernetes clusters in a single region through a managed service on AWS or GCP.
- Fit: one commenter said the project is mostly useful if you are chasing NVIDIA Cloud Partner status or need NVIDIA support across the whole stack.
- Alternatives: a reply asked whether deploying straight Kubernetes is the better route for someone with a lot of NVIDIA hardware who needs to hand out isolated workloads but does not care about partner status or support.
- Scope: another commenter said the project mixes concerns that should be distinct, naming CAPI, Kamaji and gpu-operator.
- Simpler distributions: a further reply asked why one would not just run rke2 or k3s for environments outside hyperscaler-managed Kubernetes.
On the scope point, the README says NVKE is not a Cluster API flavour, though it uses Cluster API to operate workload clusters. It does not explain why NVKE bundles these concerns rather than composing existing projects. For teams that are not running clusters for customers, nothing in the source shows an advantage over a stock cluster with the GPU Operator.
Evaluating without GPUs: 6 CPUs, 12 GiB, 100 GiB
The local quickstart runs a development management plane and a workload cluster on simulated machines, and no NVIDIA account is required. It needs a Linux host or VM on amd64 or arm64 with at least 6 CPUs, 12 GiB of free memory and 100 GiB of free disk, plus Docker, virtual TPM support and the tools listed in the guide. The guide runs through workload-cluster creation and ends when the cluster's nodes report Ready, and on macOS the evaluation runs inside a Colima virtual machine. Building from source requires Go 1.27.3, as pinned in go.work, and GNU Make 4 or later. Building does not start a management plane or create a cluster.
git clone https://github.com/dsx-ai-factory/nvke.git
cd nvke
make buildQuestions this raises
Does NVKE handle GPU drivers and GPU scheduling?
The README does not mention the GPU Operator, a device plugin, a GPU-aware scheduler, GPU drivers or supported GPU models. A companion project, NVKR, builds node images and NVKE components, but the README does not say where GPU drivers come from or how they are installed.
Is NVKE secure to expose right after installation?
No. After installation, API authentication is off and the API uses plain HTTP, and the README tells operators to configure authentication and protected access before admitting callers. The shipped FDE node images are for evaluation and provide no data-at-rest confidentiality.
Can I try NVKE without GPU hardware?
Yes. The local quickstart runs a development management plane and a workload cluster on simulated machines and needs no NVIDIA account. It requires a Linux host or VM on amd64 or arm64 with at least 6 CPUs, 12 GiB of free memory, 100 GiB of free disk, Docker and virtual TPM support.
Spotted an error? Email samir.s.sengupta@gmail.com and I will correct it and date the change at the top of the note. How these notes are researched, drafted and checked is in the editorial policy.