In un ambiente vSphere tradizionale la richiesta «mi serve una macchina virtuale» diventa un ticket, e l’amministratore diventa una coda. Il VM Service ribalta il flusso: espone una API dichiarativa in stile Kubernetes per la gestione delle VM e delle risorse vSphere associate, così che chi sviluppa possa dispiegare e far girare macchine virtuali — oltre ai container — in un ambiente Kubernetes condiviso. L’amministratore non approva più le singole VM: definisce il recinto dentro cui gli altri si servono da soli.

Perché una VM e non un container

La documentazione è esplicita sui casi d’uso: applicazioni che non si riescono a containerizzare, carichi che richiedono un kernel custom o un sistema operativo particolare, applicazioni che per natura stanno bene su una VM, e team che vogliono evitare di gestire una piattaforma non-Kubernetes accanto alla piattaforma a container. Ogni VM così creata è una macchina completa, con il proprio sistema operativo, isolata e immune alle interferenze delle altre VM o dei workload vicini.

Su VVF c’è una precisazione che vale la pena tenere ben ferma. I vSphere Pod richiedono NSX come networking stack, e vSphere Foundation non include NSX: i container quindi girano nei cluster VKS. Il VM Service, invece, funziona benissimo — è il modello di Supervisor previsto su VVF, con networking VDS e Foundation Load Balancer. Non confondere poi il VM Service con VCF Automation, che su VVF non c’è: qui l’interfaccia di self-service è kubectl, non un portale di cataloghi.

Le quattro cose che prepara l’amministratore

Un namespace vuoto non produce self-service. Prima di passare la mano servono quattro assegnazioni.

Il vSphere Namespace. È il confine di risorse dentro cui girano VM, cluster VKS e Supervisor Service. Alla creazione nasce senza limiti, e l’amministratore imposta i tetti su CPU, memoria, storage e numero di oggetti Kubernetes; in vSphere viene creato un resource pool dedicato per ciascun namespace, e i limiti di storage diventano quote Kubernetes. L’accesso si concede assegnando permessi a utenti e gruppi provenienti dalle identity source di vCenter Single Sign-On o da un provider OIDC.

Le storage policy. Si creano da Policies and Profiles > VM Storage Policies > Create VM Storage Policy e vanno bene tutti i datastore condivisi: VMFS, NFS o vSAN. Quando la policy viene assegnata al namespace, il Supervisor la converte in una storage class Kubernetes: nella conversione le maiuscole diventano minuscole e gli spazi diventano trattini, quindi conviene nominarle già in minuscolo e senza spazi, altrimenti chi scrive lo YAML non ritrova il nome che vede l’amministratore.

Le VM class. Una VM class è un template che definisce CPU, memoria e reservation — è il guardrail di policy e governance. Il Supervisor ne fornisce alcune predefinite, con una convenzione di nome che dice già tutto: le guaranteed-* riservano interamente le risorse, le best-effort-* ammettono l’overcommit. Se ne creano di personalizzate dalla vSphere Client, con DCLI o con le utility PowerShell per VKS, configurando hardware, opzioni VM e parametri avanzati. Una classe va poi aggiunta a uno o più namespace per renderla utilizzabile.

La content library. È la sorgente delle VM image — template con sistema operativo, applicazioni e dati — che nel namespace compaiono come oggetti VirtualMachineImage. L’amministratore la associa al namespace dove le VM verranno dispiegate, oppure la assegna a livello di Supervisor, rendendola disponibile a tutti i namespace. La libreria può essere di sola lettura o writable: in quest’ultimo caso gli utenti DevOps possono gestire gli item e pubblicare nuove VM image.

Come si dispiega davvero una VM

Chi sviluppa verifica prima di avere visibilità sulle risorse del namespace — VM class e VM image — poi scrive una specifica YAML che combina VM image, VM class e storage class e la applica con kubectl apply -f. La personalizzazione del guest passa dai bootstrap provider: cloud-init per il caso comune, oppure vAppConfig per le proprietà OVF.

Il caso delle proprietà OVF merita attenzione perché è controintuitivo: l’indirizzo IP si conosce solo dopo la creazione della VM. Le proprietà devono essere marcate ovf:userConfigurable="true" nell’OVF, e nello YAML si punta a una ConfigMap con transport: vAppConfig; dentro la ConfigMap si usano espressioni di template con funzioni come V1alpha2_FirstIP(), V1alpha2_FormatIP() o V1alpha2_FormatNameservers(), che vengono risolte a deployment avvenuto. Su un Supervisor a tre zone il posizionamento si guida con la label topology.kubernetes.io/zone.

Che cosa resta in mano all’amministratore

Dalla vSphere Client si va sul cluster con Supervisor abilitato, si espande il namespace sotto Namespaces e si seleziona la VM. Il Summary mostra il guest OS, gli indirizzi IP e — in alto — il tag Developer Managed; con Switch to New View compaiono anche la VM class, la VM image e il namespace. È monitoraggio, non gestione: il ciclo di vita di queste VM non si gestisce dalla vSphere Client, si gestisce con kubectl dal namespace.

Esiste però il percorso inverso, per portare una VM esistente sotto il VM Service: tasto destro sulla VM, Migrate > Change Management Layer, si sceglie il namespace di destinazione e si specificano storage policy, rete e parametri del guest OS. Servono i privilegi Namespaces.View, Namespaces.Edit e VirtualMachine.Supervisor.Transfer.

Trappole tipiche d’esame

  • VM Service non è VCF Automation, e VVF non è VCF. Su vSphere Foundation il self-service delle VM è il VM Service sul Supervisor, consumato via kubectl. Le risposte che tirano in ballo VCF Automation, i workload domain o NSX sono fuori perimetro per questo esame.
  • «Developer Managed» significa davvero developer managed. Una domanda tipica descrive un amministratore che prova a spegnere o cancellare dalla vSphere Client una VM creata dal VM Service. Non può: dalla vSphere Client vede e monitora, il ciclo di vita sta nel namespace.
  • Tre assegnazioni distinte, non una. VM class, storage policy e content library si assegnano separatamente al namespace, e la mancanza di una sola blocca il deploy. Se lo sviluppatore «non vede nessuna immagine», il problema è la content library, non la VM class.
  • guaranteed e best-effort parlano di reservation, non di dimensione. La taglia (small, large) è un’altra dimensione del nome: la coppia guaranteed/best-effort dice solo se le risorse sono riservate interamente o se è ammesso l’overcommit.
  • Il nome della storage class non è il nome della policy. Il Supervisor abbassa le maiuscole e sostituisce gli spazi con trattini: una policy chiamata «Gold VM Storage» diventa la storage class gold-vm-storage, ed è quello il nome che va nello YAML.
  • Container su VVF = VKS, non vSphere Pod. Il blueprint nomina i vSphere Pod, ma la documentazione ne pone il limite: richiedono NSX. Su vSphere Foundation la risposta corretta per i container è il cluster VKS.