NVKE is a preview for people operating a cluster service
NVIDIA Kubernetes Engine lets a platform team offer customers their own Kubernetes clusters on NVIDIA infrastructure. That means taking responsibility for the management plane as well as the machines. The current README warns against production workloads, so I'd approach NVKE as an evaluation project for an infrastructure team, even though our recorded CLI checks passed.
Each workload cluster gets its own control plane, etcd and node pools. Customers work through the Kubernetes API and kubectl. This separation makes NVKE relevant when you're building a cluster service. If you only need somewhere to run an application, operating the service beneath it adds a job you may not want.
What happened when we ran it
Our NVKE sandbox completed the install step in 102 seconds and the build in 190 seconds, then passed 37 Go tests in 91 seconds, with 0 failures. The November 5, 2026 run used commit 073f331, and the measured Go project lives in ./cli/. The record lists 740 dependencies. These successful repository steps do not establish that we installed a management plane or provisioned a cluster.
The sandbox configuration specified 3 CPUs, 8 GB RAM and image golang:1.24-bookworm. The image name does not establish the actual Go or operating-system version. Across the checkout, the scan recorded 3,160 files, approximately 453,272 source lines and 28.6 MB. It found 83 CI workflow files, no Dockerfile and no tests directory. The passing Go result shows why a missing directory named tests says little by itself.
Our run contains no GPU workload, node-attestation result or cluster recovery exercise. Nor does it measure the current whole-workspace build. Keep the CLI result in the adoption record, but require a separate demonstration of the cluster lifecycle your operators will own.
The local quickstart needs a larger machine than our CLI run
The local quickstart requires a Linux host with at least 6 CPUs, 12 GiB of free memory and 100 GiB of free disk. Those documented requirements exceed our source-check sandbox's CPU and memory allocation. Don't budget a working evaluation from the CLI timing.
No GPU hardware or NVIDIA account is needed for that route. It uses mock-NICo to simulate the infrastructure provider and starts workload nodes as Docker containers. Docker access and virtual TPM support still matter. This gives a prospective operator a way to inspect the workflow before arranging physical machines, without demonstrating compatibility with those machines.
The guide distinguishes a finished provisioning workflow from nodes reporting Ready: networking can still be starting after the cluster is marked Provisioned. For an acceptance record, save both outcomes. Follow the documented cleanup sequence too, particularly deleting the workload cluster before stopping the simulator. These are documentation-based recommendations, not steps reproduced in our run.
Recovery and access limits rule out a production recommendation
The preview limitations say there is no management-plane upgrade procedure and no backup or restore procedure. A service needs an answer for losing its management state. A successful CLI check doesn't supply one. I would stop a production evaluation at that boundary until the selected release provides a recovery path the team can exercise.
The same page says NVKE does no authorization: an authenticated API caller can use every endpoint. That matters when deciding who can manage customer clusters. Authentication alone cannot express narrower operator permissions here. Map the people and automation that need access before considering a shared deployment.
The README also says installation leaves API authentication off and uses plain HTTP. Protected access is operator configuration. Keep a local experiment isolated, and treat identity and transport configuration as deployment work. We did not examine live traffic or verify access controls.
Check the provider against the selected release
The README calls NICo the sole preview infrastructure provider, while the limitations page also describes enabled LaunchLayer deployments. That disagreement is a reason to check the exact configuration and release you intend to use. It prevents a blanket compatibility recommendation from these sources.
GitHub records a November 6, 2026 push. Issue 2165, opened that day, requests a shared Helm chart for NVKE's custom resource definitions. Together they show current development and issue activity. An open request is no evidence that the proposed chart has shipped, and activity does not establish support response times. Freeze the evaluation revision rather than combining instructions from moving branches.
Cluster API and Gardener answer different platform needs
Cluster API provides declarative APIs and tooling for provisioning, upgrading and operating multiple Kubernetes clusters. Consider it when your team wants lifecycle building blocks and can select the infrastructure provider. NVKE itself uses Cluster API, so this is a choice about how much platform behavior to assemble yourself.
Gardener manages Kubernetes clusters as a service and hosts workload-cluster control planes in seed clusters. Evaluate it when that hosting model fits your service design. Neither alternative was measured alongside NVKE, and neither is a drop-in substitute established by this review.
Start NVKE with a disposable local cluster and a written acceptance record. Before assigning real customer workloads, require answers for management-state recovery and which callers may delete a cluster. Those decisions belong to the service operator, even when the CLI checks are green.