Giuseppe Pino

NKP 2.19: bare metal, VM AHV gestite da Kubernetes e una piattaforma pensata per l'AI

Il 19 ottobre 2026 Nutanix ha rilasciato Nutanix Kubernetes Platform (NKP) 2.19. Non è la solita release di allineamento a Kubernetes upstream: le novità spostano NKP da “piattaforma per cluster Kubernetes su VM” verso un unico piano di controllo per tre tipi di workload. Container, macchine virtuali AHV e server fisici diventano gestibili con le stesse API dichiarative.

In questo articolo vediamo le novità principali, cosa cambia nelle operazioni di day-2 e, soprattutto, cosa controllare prima di aggiornare.

Le basi: versioni e compatibilità

Elemento NKP 2.19
Kubernetes di default 1.36.2 (supportate 1.36.x e 1.35.x)
Sistemi operativi nodi Rocky Linux 9.8, RHEL 9.8 (nuovi)
Prism Central pc.7.5, pc.7.6
AOS 7.5, 7.6
NDK 2.3
NAI 2.8.0, 2.8.1

Qualche componente chiave dello stack:

Componente Versione
Cluster API (CAPI) 1.12.11
CAPX (provider Nutanix) 1.10.15
containerd 2.3.1
etcd 3.6.8
Cilium 1.19.4
Calico 3.32.1
Traefik 3.6.12
Velero 1.18.0

Per i cluster attached (EKS, AKS, GKE o generici) valgono le stesse versioni 1.36.x e 1.35.x. Nutanix raccomanda di non agganciare cluster con versione superiore a n-1.

NKP Metal: Kubernetes direttamente sul ferro

La novità più rilevante dal punto di vista architetturale è NKP Metal, il supporto al deployment su server fisici.

Il flusso usa Foundation Central e il nuovo host inventory di NKP:

  • imaging e registrazione degli host fisici;
  • assegnazione degli host ai workspace;
  • creazione di cluster interamente bare metal, oppure aggiunta di node pool fisici a cluster basati su VM.

Il secondo scenario è quello più interessante in ottica progettuale. Un cluster può avere control plane e worker “generici” su AHV e un node pool fisico dedicato ai workload che richiedono accesso diretto a GPU, rete o storage locale. Il lifecycle di host e node pool resta gestito da NKP.

I casi d’uso indicati da Nutanix sono AI/ML, GPU computing ed edge.

VM Operator: le VM AHV come risorse Kubernetes

Con VM Operator, NKP 2.19 permette di gestire VM su AHV, Linux e Windows, tramite API Kubernetes e workflow dichiarativi: provisioning, aggiornamento, monitoraggio e lifecycle.

Il valore pratico è per le applicazioni ibride, dove una parte gira in container e una parte resta su VM (database legacy, componenti Windows, appliance). Il platform team può descrivere l’intera applicazione con lo stesso modello operativo e gli stessi strumenti GitOps, invece di gestire VM e container su due binari separati.

AI: catalogo dedicato, GPU con DRA e conformità CNCF

Catalogo applicazioni AI

Per le edizioni Pro e Ultimate arriva nel workspace catalog una selezione curata di applicazioni AI/ML:

Applicazione Ruolo
KAI Scheduler Scheduling GPU-aware
Kueue Gestione dei workload a code
Slurm Operator Workload HPC/batch in stile Slurm
Kubeflow Pipelines Pipeline ML
JupyterHub Ambienti di sviluppo
Milvus Operator Database vettoriale

I prerequisiti cambiano da applicazione ad applicazione e possono includere GPU operator, monitoring, ingress e cert-manager.

GPU scheduling e slicing con DRA

NKP 2.19 supporta scheduling e slicing delle GPU tramite Dynamic Resource Allocation (DRA) di Kubernetes, per GPU NVIDIA e AMD. Il partizionamento MIG di NVIDIA non è incluso in questa release: è un dettaglio da tenere presente nei dimensionamenti.

CNCF Kubernetes AI Conformance

Nutanix dichiara il supporto agli obiettivi della CNCF Kubernetes AI Conformance: una baseline vendor-neutral che, oltre alla conformità Kubernetes standard, richiede gestione degli acceleratori, gang scheduling, autoscaling, inference networking, osservabilità e sicurezza. L’obiettivo è la portabilità dei workload AI tra cloud pubblico, on-premises ed edge senza re-platforming.

AI Navigator e MCP Server

Il NKP MCP Server (Model Context Protocol) è ora abilitato di default sul management cluster, con alcuni vincoli:

  • solo licenze Pro e Ultimate;
  • solo ambienti connessi a Internet: non è incluso nei deployment air-gapped;
  • non viene installato su cluster workload o attached.

Sul fronte sicurezza, che è la prima domanda che farà qualsiasi cliente:

  • l’MCP Server applica l’RBAC di Kubernetes e restituisce solo le risorse consentite al ruolo dell’utente;
  • non espone i Secret;
  • si possono definire regole allow/deny sui resource kind esposti e field filter per limitare i dati restituiti;
  • le nuove risorse aggiunte (storage, scheduling, policy, autoscaling, networking, Flux) sono read-only.

Il catalogo delle risorse viene costruito dinamicamente dal cluster connesso (discover_resource_types), includendo le custom resource. In upgrade conviene rivedere le regole allow/deny, perché il catalogo può differire tra cluster.

AI Navigator, che usa l’MCP Server, ora vede risorse Kubernetes, Flux e oggetti NKP (cluster, workspace, licenze), indicizza documentazione e KB Nutanix tramite API, espone metriche Prometheus sulle sessioni e recupera la connessione PostgreSQL senza riavvio del pod.

Day-2: upgrade più semplici e integrazione con Prism Central

Upgrade per cluster in un solo passaggio

Dopo aver aggiornato il management cluster a 2.19, i workload cluster ClusterClass (per esempio Nutanix ed EKS) si aggiornano dalla UI o con un solo comando CLI. La sequenza è: platform application, poi Kubernetes, infrastruttura del cluster e add-on.

Per i cluster non ClusterClass c’è il nuovo comando:

nkp upgrade platform-apps

che aggiorna le platform application in modo indipendente, prima delle procedure esistenti per Kubernetes e infrastruttura. Di conseguenza nkp upgrade workspace è deprecato.

Prism Central

  • In deployment e upgrade NKP registra automaticamente i cluster in Prism Central.
  • Supporto a Prism Central Projects 2.0: un cluster NKP può usare il project di default o un project definito dall’utente, ma tutto il cluster (control plane e tutti i node pool) deve stare nello stesso project.

Registry e air-gapped

  • Supporto al registry DockerHub di Nutanix, con token generato dal portale Nutanix e fornito alla creazione del management cluster. I workload cluster ereditano il token del management cluster, ma se ne può impostare uno diverso da CLI, UI o YAML, anche dopo il provisioning.
  • Nuovo bundle nkp-release-specs-nkp-version.tar per gli ambienti air-gapped: contiene i metadati di release (versioni Kubernetes supportate, compatibilità provider) usati per la version discovery e per individuare i percorsi di upgrade supportati.

Headlamp sostituisce Kubernetes Dashboard

Il progetto upstream Kubernetes Dashboard è archiviato e NKP 2.19 lo sostituisce con Headlamp come platform application. In upgrade, la vecchia Dashboard installata da NKP resta in esecuzione: Nutanix raccomanda di migrare a Headlamp il prima possibile. Eventuali istanze di Dashboard installate autonomamente per i workload applicativi restano a carico del cliente.

Anche NKP Insights 1.9 si integra con Headlamp: le pagine di dettaglio e di Root Cause Analysis puntano alle relative dashboard.

Checklist prima dell’upgrade da 2.18

Questa è la parte da leggere con attenzione. Le release notes contengono diversi punti che possono bloccare l’upgrade o lasciare cluster in stato inconsistente.

  • Token DockerHub Nutanix: se il management cluster non ha già un token, va specificato durante l’upgrade.
  • Projects 2.0: se un cluster 2.18 ha nodi distribuiti su più project, vanno consolidati in un unico project (default o user-defined) prima dell’upgrade. Spostarsi su un project user-defined può richiedere il supporto Nutanix per migrare i volume group esistenti dal project di default.
  • Catalog GitRepository: il supporto è stato rimosso da controller e CLI. Le AppDeployment residue vanno migrate a un catalog basato su OCIRepository.
  • Flag --kommander-applications-repository: non più supportato su nkp install kommander e nkp upgrade kommander. Da togliere da eventuali script.

Fix degni di nota

Tra i problemi risolti, alcuni erano particolarmente fastidiosi in produzione:

  • il pod nutanix-cloud-controller-manager non rinnovava il token di sessione Prism Central scaduto: restava in Running mentre i nuovi nodi rimanevano NotReady;
  • le risorse OCIRepository interrogavano il registry ogni minuto, esaurendo i limiti API;
  • nkp upgrade cluster ignorava --skip-preflight-checks=Registry, bloccando gli upgrade con mirror registry;
  • l’aggiornamento delle AppDeployment falliva nei workspace con più di 10 cluster;
  • l’emissione di certificati ACME falliva per un ingress class errato (traefik invece di kommander-traefik).

Cosa significa in pratica

Con NKP Metal e VM Operator, NKP 2.19 copre container, VM AHV e server fisici con lo stesso modello dichiarativo. Per chi progetta piattaforme on-premises questo cambia la discussione: non si tratta più solo di “dove far girare Kubernetes”, ma di quale piano di controllo usare per l’intera applicazione, inclusa la parte che non è containerizzata.

Sul fronte AI, catalogo curato, DRA per GPU NVIDIA e AMD e allineamento alla CNCF AI Conformance rendono NKP una base più concreta per workload di training e inference, con il limite, per ora, dell’assenza di MIG.

Prima di aggiornare, però, la checklist sopra va presa sul serio: token DockerHub, consolidamento dei Projects e migrazione dei catalog GitRepository sono i punti che più facilmente sorprendono chi aggiorna senza leggere le release notes.

Fonte: Nutanix Kubernetes Platform 2.19 Release Notes, 19 ottobre 2026.