From the NVIDIA edition of November 10, 2026
Manage Kubernetes Clusters for GPU Infrastructure with NVIDIA Kubernetes Engine
NVIDIA · AI factory / GPU infrastructure software · Global
- Publisher
- NVIDIA Technical Blog
- Original publication
- November 10, 2026
- Source retrieved
- 2026-11-11
- Event date
- 2026-11-10
What happened
NVIDIA announced two open source projects, NVIDIA Kubernetes Engine (NVKE) and NVIDIA Kubernetes Recipes (NVKR), for running managed Kubernetes services on GPU infrastructure. NVKR builds version-pinned node and container images and records build inputs; NVKE provisions and manages clusters through a REST API and controllers, with servers supplied by NVIDIA Infra Controller. Both are Apache 2.0, in public preview, and NVIDIA states they are not yet recommended for production workloads. NVKE is described as a Certified Kubernetes AI Platform and Installer, conformance tested on Kubernetes 1.36. Firmus and SK Telecom are integrating them; Mirantis, Rafay, Spectro Cloud, OpenNebula Systems, vCluster and Netris are incorporating components.
Why it matters
Limited and indirect. This targets AI factory operators and cloud providers, not typical agencies or campuses. It matters to SLED teams only where a state, university or research-computing center operates its own GPU cluster or buys capacity from a provider that adopts it.
Evidence and measured results
Vendor technical post with a walkthrough; no independent test, customer deployment or performance data. Partner integrations are stated as in progress.
Limitations and uncertainty
Vendor-authored; public preview; not recommended for production; walkthrough prerequisites are substantial (multiple CPU servers, GPU pool, NICo installation, build host).
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-10; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Institutions running or buying GPU capacity need a supportable way to offer Kubernetes access to tenants.
- Stakeholders
- Research computing director
- Infrastructure or platform lead
- Cloud or colocation provider
- Procurement
- Discovery questions
- Do you operate GPU clusters or buy them as a service?
- What Kubernetes management tools do you use today?
- What support level do you require for production?
- Value hypothesis
- Reproducible images and an API-driven cluster lifecycle may reduce manual GPU cluster operations once the projects mature.
- Potential engagement
- Lab-scale evaluation and architecture review of NVKE and NVKR against current cluster management.
- Unsupported claims
- That NVKE is production ready
- That partner integrations are shipping
- Any cost or staffing savings
Pre-sales engineering
Role takeaway
- Fit
- Fits operators building managed Kubernetes on bare-metal GPU servers, especially with NICo.
- Architecture and integration
- nvkectl seed cluster forms a management cluster; NVKE REST API and controllers create workload clusters; NICo supplies servers via CAPNICo; NVKR supplies images.
- Prerequisites
- Three CPU servers for management
- Three CPU servers plus GPU pool for a workload cluster
- NICo with enrolled capacity
- Build host with Docker and KVM
- Registry and HTTP image server
- Constraints
- Public preview; APIs may change
- Not recommended for production
- Heavy hardware prerequisites
- Security
- Verify image signing, SPIFFE attestation and tenant isolation yourself; no assessment is provided in the post.
- Proof of value
- Run the single-machine quickstart
- Build a node image and reproduce it
- Provision a test cluster and exercise upgrade and recovery
Delivery
Role takeaway
- Work
- Lab proof of concept: image build, management plane, one test workload cluster.
- Dependencies
- NICo capacity
- Network and registry
- Image hosting
- Ownership
- Infrastructure team lead with named on-call owner.
- Skills and adoption
- Needs Kubernetes, Cluster API, bare-metal and image-build skills.
- Governance checkpoints
- Review preview limitations before hardware commitment
- Change control for version pins
- Upgrade and recovery test review
- Acceptance criteria
- Proposed: reproducible node image rebuild
- Proposed: successful cluster provision, upgrade and recovery test
- Risks
- API changes during preview
- Hardware prerequisites
- Skills gap
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Management cluster seeded by nvkectl, workload clusters with separate control planes and node pools, bare-metal lifecycle via NICo and Cluster API, attested SPIFFE node identity, and an OpenTelemetry telemetry chart. Teams can adopt NVKE and NVKR together or separately.
Governance
Who approves, reviews and stays accountable for outcomes?
Version-pinned, recorded build inputs support reproducibility and change control. Preview status means APIs may change and production support is not offered.
Security and privacy
What data, permissions and controls need testing?
Signed, version-pinned images and attested node identity are positive design points as described; the post gives no security assessment, and tenant isolation behavior is not tested in the source.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Bare-metal GPU Kubernetes operations demand scarce platform engineering skills; open source documentation and a local quickstart lower the learning barrier but not the staffing need.
Procurement
What should contracts, pricing and exit terms secure?
Apache 2.0 licensing and open code allow inspection, but preview status means no production support commitment; contracts with any provider adopting NVKE should state support, versioning and exit terms.
Operating model
Which teams own the service once it runs?
Suggests a platform-team model where an AI factory operator runs the management plane and tenants consume clusters through APIs, with release sets controlling validated Kubernetes versions.
Publication history
- 2026-11-10NVIDIA · Issue 665 resources
Stable resource ID: nvidia-kubernetes-engine-recipes-public-preview-20261110