From the NVIDIA edition of November 7, 2026
NVIDIA Kubernetes Engine (NVKE) preview documentation: supported features and known limitations, including plain-HTTP API, no authorization, and no management-plane backup or upgrade
NVIDIA · AI infrastructure / Kubernetes platform software · Global (operator-installed on own NVIDIA GPU infrastructure)
- Publisher
- NVIDIA Kubernetes Engine documentation
- Original publication
- Undated documentation page; NVKE preview surfaced publicly Nov 6–7, 2026 per independent reporting
- Source retrieved
- 2026-11-08
What happened
NVIDIA's NVKE documentation describes an open-source preview management system that lets an AI-factory operator create isolated Kubernetes workload clusters (own control plane, etcd, node pools) on its own GPU bare metal through NVIDIA Infra Controller (NICo). The known-limitations page states NVKE is not recommended for production; the API serves plain HTTP on port 30080 with authentication off after install; NVKE does no authorization, so any admitted caller can create or delete every workload cluster; customers receive only a non-revocable admin kubeconfig; and the management cluster has no self-management, upgrade, or backup/restore procedure.
Why it matters
Limited and indirect today. State shared-services centers, statewide research-computing consortia and large campus AI factories that hand out GPU clusters to agencies or departments are the closest SLED analogue to the 'operator with customers' NVKE targets. The vendor's own limitations list makes NVKE an evaluation item, not a deployable multi-tenant service, for public-sector environments in 2026.
Evidence and measured results
Vendor documentation read in full on the limitations page: supported-at-preview list (node OS images, nvkectl bootstrap, NICo provisioning, JWT authentication, OVN-Kubernetes, optional etcd encryption, node-pool scaling, NKTP telemetry, mock-NICo local quickstart) and known limitations for the management cluster, API/access, node pools, artifacts and telemetry. No performance or deployment metrics are reported.
Limitations and uncertainty
Vendor documentation for a preview; behavior and APIs may change. Page is undated, so the publication date is left null. No measured outcomes, customer deployments or U.S. public-sector use are described.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-07; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Operators of shared GPU estates need a repeatable way to give each department or agency its own isolated Kubernetes cluster.
- Stakeholders
- State shared-services or central IT platform lead
- Research computing director
- CISO / security architecture
- Enterprise architecture
- Discovery questions
- How do you provision isolated GPU clusters for tenants today?
- Which tenancy, credential-revocation and audit controls are mandatory?
- Are you pursuing any NVIDIA Cloud Partner-style operating model?
- Value hypothesis
- If NVKE matures past preview, it could reduce custom tooling for multi-tenant GPU cluster provisioning on NVIDIA bare metal; today the value is an informed roadmap comparison.
- Potential engagement
- Short tenancy-architecture review comparing current cluster provisioning with NVKE preview capabilities and gaps.
- Unsupported claims
- Production readiness
- Built-in role-based authorization
- Any public-sector deployment
- Cost or staffing savings
Pre-sales engineering
Role takeaway
- Fit
- Only operators running many customer clusters on NVIDIA bare metal managed through NICo; weak fit for single-team clusters.
- Architecture and integration
- Management cluster runs NVKE management plane and CAPNICo; workload clusters provisioned via NICo with OVN-Kubernetes networking and SPIFFE/SPIRE node attestation.
- Prerequisites
- TPM 2.0 management nodes in odd counts
- Operator-supplied SPIRE CA
- NICo or LaunchLayer provider
- Operator TLS endpoint and JWT identity provider
- Constraints
- Not recommended for production
- No authorization layer
- No management-plane upgrade or backup/restore
- Admin kubeconfigs cannot be revoked
- Security
- API is plain HTTP with authentication off after install; must be network-fenced, TLS-fronted and JWT-protected before any caller is admitted.
- Proof of value
- Stand up mock-NICo quickstart and document every hardening step
- Verify API is unreachable without TLS and JWT
- Test kubeconfig hand-off and credential lifetime against policy
Delivery
Role takeaway
- Work
- Lab evaluation of NVKE preview with a documented hardening and gap report.
- Dependencies
- Platform engineering capacity
- Identity provider for JWT
- Lab hardware or VM meeting quickstart specs
- Ownership
- Central platform engineering team, with security architecture sign-off.
- Skills and adoption
- Requires Kubernetes, Cluster API, SPIFFE/SPIRE and OVN-Kubernetes skills; not an end-user capability.
- Governance checkpoints
- Security review before any network exposure
- Credential-handling procedure for admin kubeconfigs
- Exit decision before any tenant data
- Acceptance criteria
- Proposed: gap list mapped to agency security baseline completed
- Proposed: API reachable only through TLS with JWT
- Proposed: no production or tenant data used
- Risks
- Preview API changes
- Unrecoverable management cluster without backup
- Over-privileged tokens
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?
Requires a dedicated management cluster (TPM nodes, SPIRE CA supplied by the operator), NICo or LaunchLayer as infrastructure provider, operator-built node images and registries, and an operator-supplied TLS endpoint in front of the API. GPU drivers and device plugins are handled outside NVKE (GPU Operator, per independent reporting).
Governance
Who approves, reviews and stays accountable for outcomes?
Because NVKE does no authorization and admin kubeconfigs cannot be revoked until certificate expiry, any SLED pilot must restrict token issuance to staff allowed to manage every tenant cluster and record kubeconfig hand-offs as privileged-credential events.
Security and privacy
What data, permissions and controls need testing?
Default plain-HTTP, unauthenticated API; tokens cross the network unencrypted without an operator TLS proxy; no per-user customer credentials; non-revocable admin kubeconfigs; the etcd encryption key file from bootstrap is the only off-node copy and must be stored securely.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Operating NVKE requires specialized platform engineers; small SLED IT teams are unlikely to staff it during preview.
Procurement
What should contracts, pricing and exit terms secure?
Do not cite NVKE as a supported managed-Kubernetes capability in RFP responses; ask vendors for production status, support terms and authorization model.
Operating model
Which teams own the service once it runs?
Fits a provider-to-tenant operating model (central IT serving agencies); requires credential lifecycle procedures NVKE itself does not supply.
Publication history
- 2026-11-07NVIDIA · Issue 636 resources
Stable resource ID: nvidia-nvke-preview-status-known-limitations