In early November 2026, NVIDIA’s open-sourced Kubernetes control plane finally got the attention it was designed for: on November 6 the NVIDIA Kubernetes Engine (NVKE) repository hit the front page of Hacker News, where the community’s first question was the obvious one - “can’t regular Kubernetes already deploy to GPUs?"[1] It can, and it does. But NVKE is not another Kubernetes distribution. It is a management plane that runs a managed Kubernetes service on hardware you own - the piece that sits between “I know how to run kubeadm” and “I sell GPU capacity as Kubernetes clusters to customers.”
This article compares the three real ways to get GPU Kubernetes in late 2026: NVKE on your own NVIDIA iron, a DIY cluster with k3s or kubeadm, and managed GPU clusters rented from DigitalOcean or Vultr. Every version, limit, and price below was checked against the providers’ own pages on November 6, 2026. No invented benchmarks.
What NVKE actually is
NVKE is open-source software (Apache 2.0) that an “AI factory” installs to run a managed Kubernetes service on its own NVIDIA GPU infrastructure.[2] You call the NVKE API to create Kubernetes clusters for your customers, and NVKE provisions the nodes, forms each cluster, and operates it afterwards: scaling node pools, upgrading Kubernetes, replacing nodes, and renewing certificates.[2]
Two details in that sentence carry the whole design. First, one NVKE installation manages a fleet of clusters inside a single data center, and each cluster gets its own control plane and etcd - so one customer’s control plane incident does not take down another’s.[2] Second, the repository describes itself as “a self-hosting factory for Kubernetes clusters”: a throwaway seed cluster stands up the management cluster, and the management plane on it then provisions and lifecycle-manages many isolated workload clusters on demand.[3]
Concretely, the bootstrap path looks like this:
- Day 0 - Bootstrap.
nvkectlstarts a seed cluster, uses it to form the management cluster with kubeadm, then deletes the seed.[2] - Day 1 - Configure. The operator connects the management plane to the infrastructure provider, configures API authentication, and publishes the machine images and releases that clusters will use.[2]
- Day 2 - Run clusters. Clusters are created through the API, and NVKE keeps them alive: scaling node pools, upgrading the control plane and workers to new releases, replacing nodes and renewing certificates.[2]
The components are the classic pieces of a platform, assembled: NVKR (the build system for node images and artifacts), nvkectl (the CLI), the management plane (REST API plus controllers), nvke-agent (a service on every node that runs kubeadm, configures encryption and installs the CNI - without SSH), CAPNICo (the Cluster API infrastructure provider for NVIDIA’s bare-metal controller NICo), and NKTP (the telemetry pipeline).[2][3]
Node identity is the strongest part of the security story: nodes carry a SPIRE agent (1.14.1) with a TPM plugin (1.9.0), and a node is admitted only after attesting with its TPM 2.0 device - you record each node’s TPM endorsement-key thumbprint in the site spec, and a node without one cannot join.[4][5] There is no join-token fallback in the documented bootstrap path.[5]
The preview reality check
Here is the part that decides whether NVKE is usable today: it is explicitly a preview. NVIDIA’s own words: “APIs, configuration and behavior can change between releases, and we do not recommend NVKE for production workloads."[3][6]
The known limitations are not cosmetic:[6]
- The management cluster does not manage itself. It does not upgrade, scale, or replace its own nodes, there is no management-plane upgrade procedure, and there is no documented backup or restore procedure for the management cluster’s state.[6]
- API authentication is off by default, and the API speaks plain HTTP after installation. You configure authentication and protected access before admitting any caller.[3][6]
- The full-disk-encryption (FDE) node image variant is evaluation-only. Worse, nodes built from one FDE image share its volume encryption key, so the image does not protect data at rest.[6][7]
- NICo is the sole compatible infrastructure provider at preview (through CAPNICo v0.1.0). No vSphere, no bare-metal API you already have - NVIDIA’s own controller.[3][7]
- The default telemetry backend is for evaluation only: it keeps data in memory and gives anonymous users admin access to Grafana.[6]
The platform is also prescriptive about what you must run: Kubernetes 1.36.3 is pinned for both the management and workload clusters, node OS is Ubuntu 24.04 or 26.04 LTS only (nothing else), the CNI is NVIDIA’s OVN-Kubernetes 2.4.2, and upgrades are deliberately conservative - the control plane can move one minor version up or to a later patch, and worker node pools may skew up to three minor versions behind the control plane.[7]
If you just want to kick the tires without GPU hardware, the local quickstart runs against a simulated infrastructure provider (mock-NICo) on one Linux machine with at least 6 CPUs and 12 GiB of memory.[2] That is also where the honest evaluation should start, because a real deployment requires NICo-managed NVIDIA machines, TPM 2.0 on every node, a node-image build host, registries, and an identity provider if you enable API authentication.[2][5]
What NVKE is not
Keeping the category straight matters more than the feature list. NVKE is not a Kubernetes distribution and not a Cluster API flavor - it is a self-hosted factory for clusters.[3] It is not a tool for one GPU box: it is a fleet-and-tenant product, built so an operator can resell Kubernetes capacity, not so a team can run one training cluster. If your mental model is “OpenStack, but for GPU Kubernetes,” you are close.[1]
That is exactly why it hits the comparison at all: it is the missing tier between DIY and managed.
The DIY baseline: k3s and kubeadm
The counterweight to NVKE’s ambition is a cluster you build with your own hands. Two honest paths exist on your own iron.
kubeadm is the fast path for the control plane, not a managed service. It provides kubeadm init and kubeadm join as best-practice ways to bootstrap a minimum viable cluster, and by design it cares only about bootstrapping - not about provisioning machines, and not about add-ons like dashboards or monitoring.[8] Every upgrade, node replacement, backup, and certificate renewal after bootstrap is yours. That is not a flaw; it is the definition of self-hosting.
k3s is the lightweight alternative: a CNCF-certified Kubernetes distribution shipped as a single binary under 100 MB, with a sqlite3 default datastore (etcd3, MySQL, and PostgreSQL also available) and a batteries-included stack - containerd, Flannel CNI, CoreDNS, Traefik ingress, a load-balancer controller, and a local-path provisioner.[9] For a small GPU cluster, k3s with etcd for HA is a completely defensible choice: less machinery than a kubeadm cluster, still real Kubernetes.
The GPU part is the same on both. Kubernetes has stable support for scheduling AMD and NVIDIA GPUs via device plugins since v1.26: you install the vendor’s driver and device plugin on each node, and the cluster exposes a custom resource like nvidia.com/gpu that pods request in their limits.[10] The NVIDIA device plugin is the standard way to do this.[10][11]
What you pay for with DIY is not licenses - it is everything else. Someone must own node lifecycle, control-plane upgrades, etcd backup and restore, certificate rotation, monitoring, and the operational playbook for when a GPU dies mid-training. If you have that person (or you are that person), a DIY cluster is the cheapest possible GPU Kubernetes and the one with the fewest moving parts. If you do not, the savings evaporate fast.
The managed alternative: DO and Vultr GPU instances
The third path is renting GPU capacity from a cloud and getting Kubernetes on top of it. Prices below are the on-demand rates read from the providers’ pricing pages on November 6, 2026.
DigitalOcean GPU Droplets (per GPU/hour, on-demand):[12]
| GPU | Price / GPU / hr |
|---|---|
| RTX 4000 Ada (20 GB) | $0.76 |
| RTX 6000 Ada (48 GB) | $1.57 |
| L40S (48 GB) | $1.57 |
| MI300X (192 GB) | $2.59 |
| HGX H100 (80 GB) | $4.41 |
| HGX H200 (141 GB) | $4.47 |
DO bills GPU Droplets per second with a 5-minute minimum, and powered-off Droplets are still billed - you pay until you destroy the instance.[12]
Vultr Cloud GPU (per GPU/hour, on-demand):[13]
| GPU | Price / GPU / hr |
|---|---|
| L40S (48 GB) | $1.671 |
| MI300X (192 GB) | $1.850 |
| GH200 (96 GB) | $1.990 |
| HGX H100 (80 GB) | $2.300 |
| HGX B200 (192 GB) | $3.500 |
Two observations before the comparison. First, the managed cloud path is not free of Kubernetes work either: both providers sell GPU instances, and you still bring the control plane - either a managed Kubernetes service (Vultr has one; DigitalOcean has managed Kubernetes on the same account) or your own k3s/kubeadm installed on the rented nodes. The cloud buys you hardware flexibility and zero capex, not the platform layer. Second, the prices above are for bursty and multi-region needs: NVKE on your own iron has no variable per-GPU hour, but you paid for the iron up front and you run it 24/7 either way.
When the NVIDIA approach pays off
The decision framework, honestly stated:
| Your situation | Take |
|---|---|
| You already run NVIDIA GPU iron managed by NICo, at fleet scale | NVKE is worth an evaluation - this is exactly the deployment it was built for.[2] |
| You want to resell Kubernetes capacity to customers as a service | NVKE’s core use case; the isolation model (per-cluster control plane and etcd) matches multi-tenant expectations.[2][3] |
| One to a few GPU boxes, you have platform skills | k3s or kubeadm. Fewer moving parts, everything under your control, no preview constraints.[8][9] |
| Bursty workloads, no GPU capex, regional flexibility | Managed GPU instances (DO/Vultr) with per-second pricing; pair with a managed Kubernetes service.[12][13] |
| Workloads are already served well by token-based inference | Skip the cluster entirely - see our Vultr Serverless Inference vs GPU vs OpenAI API comparison.[1] |
| Nobody on the team owns the platform layer | Managed, every time. DIY and NVKE both assume an operator who lives in this stack. |
The honest bottom line
NVKE in preview is a real product skeleton with real teeth: SPIFFE/SPIRE TPM attestation, per-cluster etcd isolation, node-agent-driven operations without SSH - the architecture is serious. But preview is preview: no control-plane upgrade path, no backup/restore procedure, authentication off by default, FDE images that do not protect data at rest, and a single infrastructure provider.[6][7] Right now NVKE makes sense for an AI factory operator with NICo-managed NVIDIA hardware who wants to productize spare capacity - not for a team picking its first Kubernetes setup.
For everyone else, the choice is unchanged: DIY (k3s/kubeadm) when you own the operations, managed GPU instances when you want the flexibility and can live with the hourly rate. The market that NVKE targets is real, and NVIDIA publishing it as open source under Apache 2.0 means the preview get real tested by early adopters - the same dynamic that made the DIY clusters above as boring and reliable as they are today.[2][3]
Prices and preview status move; the figures above are the official values on the day this was written and should be re-checked on the sources below before you budget or commit iron.
Sources
- Hacker News - “Nvidia Kubernetes Engine (NVKE)”, front page November 6, 2026 (community discussion; trend signal, not a fact source). https://news.ycombinator.com/item?id=50387738 - checked 2026-11-06
- NVIDIA Docs - “What is NVKE” (product definition, components, Day 0/1/2 workflow, local quickstart requirements, Apache 2.0). https://docs.nvidia.com/nvke/ - checked 2026-11-06
- GitHub - dsx-ai-factory/nvke README (“self-hosting factory for Kubernetes clusters”, preview status, API auth off and plain HTTP by default, NICo sole provider). https://github.com/dsx-ai-factory/nvke - checked 2026-11-06
- NVIDIA Docs - “Prepare nodes” (SPIRE agent 1.14.1, TPM plugin 1.9.0, TPM 2.0 attestation, endorsement-key thumbprints in site spec, no join tokens). https://docs.nvidia.com/nvke/documentation/install-nvke/prepare-nodes - checked 2026-11-06
- NVIDIA Docs - “Prepare nodes” (node admission via TPM attestation; requirements for a real installation: TPM 2.0 on every node, node images, registries, identity provider). https://docs.nvidia.com/nvke/documentation/install-nvke/prepare-nodes - checked 2026-11-06
- NVIDIA Docs - “Preview status and known limitations” (management cluster does not manage itself, no upgrade procedure, no backup/restore, auth off by default, FDE evaluation-only, NKTP backend evaluation-only). https://docs.nvidia.com/nvke/documentation/overview/preview-status-and-known-limitations - checked 2026-11-06
- NVIDIA Docs - “Supported platforms and versions” (Kubernetes 1.36.3 pinned, Ubuntu 24.04/26.04 LTS only, OVN-Kubernetes 2.4.2, upgrade policy, worker skew up to 3 minors, FDE shared key, CAPNICo v0.1.0). https://docs.nvidia.com/nvke/documentation/overview/supported-platforms-and-versions - checked 2026-11-06
- Kubernetes Docs - “Kubeadm” (kubeadm init/join fast paths; bootstrapping only, not machine provisioning or add-ons). https://kubernetes.io/docs/reference/setup-tools/kubeadm/ - checked 2026-11-06
- K3s Docs - “Lightweight Kubernetes” (single binary under 100 MB, sqlite3 default datastore, etcd3/MySQL/PostgreSQL options, bundled components). https://docs.k3s.io/ - checked 2026-11-06
- Kubernetes Docs - “Schedule GPUs” (stable GPU support via device plugins since v1.26,
nvidia.com/gpuresource, limits-only semantics). https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/ - checked 2026-11-06 - NVIDIA - k8s-device-plugin (NVIDIA device plugin quick start). https://github.com/NVIDIA/k8s-device-plugin - checked 2026-11-06
- DigitalOcean - GPU Droplets pricing (on-demand per-GPU-hour rates; per-second billing, 5-minute minimum, powered-off still billed). https://www.digitalocean.com/pricing/gpu-droplets - checked 2026-11-06
- Vultr - Pricing page, “Cloud GPU” section (on-demand per-GPU-hour rates). https://www.vultr.com/pricing/ - checked 2026-11-06