Il blueprint chiede di descrivere «the deployment of Supervisor-based Services in VMware vSphere Foundation». Non basta elencare i servizi: serve sapere dove passa il confine fra ciò che si registra su vCenter, ciò che si installa sul Supervisor e ciò che su VVF non c’è perché manca NSX.

Che cos’è un Supervisor Service

La documentazione li definisce senza mezzi termini: i Supervisor Services sono «vSphere certified Kubernetes operators that deliver Infrastructure-as-a-Service components and tightly-integrated Independent Software Vendor services to developers». Non sono feature del Supervisor da accendere con una spunta: sono operatori Kubernetes che qualcuno impacchetta, tu registri e poi installi.

Si consumano in due modi, e la distinzione ricorre negli scenari. Alcuni sono shared services, come Harbor: forniscono direttamente una funzionalità ai workload. Altri sono operator-based, come MinIO: pubblicano delle CRD e sono gli sviluppatori a creare le proprie istanze nel loro namespace. Il pacchetto arriva come file YAML — in Carvel format o in SupervisorServiceDefinition format — e i servizi supportati si scaricano da vmware.com/go/supervisor-service.

Il vSphere Namespace è il confine

Il namespace «sets the resource boundaries where vSphere Pods, VMs, and VKS clusters, and Supervisor Services can run». Lo crea l’amministratore vSphere dal vSphere Client, e il Supervisor genera automaticamente un resource pool dedicato. Dentro quel confine si impostano limiti di CPU e memoria, quote di storage (in Kubernetes diventano storage quota) e un tetto al numero di oggetti Kubernetes; finché non imponi vincoli il namespace vede le risorse del Supervisor come illimitate. Sempre lì si assegnano i permessi a utenti e gruppi presi dalle identity source di vCenter Single Sign-On o da un provider OIDC, e si associano VM class e content library con i template per il self-service.

Quando installi un Supervisor Service, però, «a vSphere Namespace is automatically created» per le risorse del servizio. Compare nell’inventory accanto a quelli dei team, ma non è un namespace di progetto: è il contenitore del servizio.

Il ciclo di vita: due passaggi, due privilegi

Passo 1 — registrare il servizio su vCenter. Dal menu home del vSphere Client, Supervisor Management > Services, si sceglie il vCenter dal menu a tendina in alto e si trascina il file YAML nella card Add New Service; Next, eventuale EULA, Finish. Serve il privilegio Manage Supervisor Services sul vCenter. Il servizio «is registered with vCenter» e la versione entra in stato Active. Nessun workload si è ancora mosso.

Passo 2 — installarlo su un Supervisor. Dalla card del servizio, Actions > Manage Service, si sceglie la versione dal menu Install Version, si seleziona il Supervisor, Next. Qui girano i compatibility pre-checks: i warning si accettano e si prosegue, gli error bloccano. Nel campo YAML Service Config si inseriscono le proprietà di configurazione, se il servizio ne richiede. Serve il privilegio Manage Supervisor Services on Supervisors: privilegio diverso, oggetto diverso. Allora «the service YAML file is applied on the Supervisor, and all the vSphere Pods and necessary resources are created» e il servizio passa da Configuring a Configured. Lo stato si segue da Supervisors > (Supervisor) > Configure > Supervisor Services > Overview, schede Installed e Available.

L’upgrade non ha un pulsante dedicato: si aggiunge la nuova versione a vCenter e poi la si installa sul Supervisor, verificando che quella presente sia più vecchia. Una versione si può deactivate, e la si rimette in circolo da Active Versions > Manage Versions > Reactivate. Se le immagini stanno in un registry privato, vanno configurate trust e autenticazione del Supervisor verso quel registry; con certificato TLS firmato da una CA pubblica la configurazione della CA non serve.

Che cosa cambia davvero su vSphere Foundation

Su VVF il networking stack del Supervisor è il vSphere Distributed Switch, con Foundation Load Balancer o Avi Load Balancer; NSX non è nello SKU. E la documentazione è categorica: «vSphere Pods are only supported with Supervisors that are configured with NSX as the networking stack». Poiché alcuni servizi per costruzione creano vSphere Pod — «when deployed, the Contour Supervisor Service creates vSphere Pods in the namespace provisioned for the service» — il carico containerizzato su VVF vive nei cluster VKS.

Secondo paletto: il Simplified (Easy) Supervisor senza load balancer dichiara che «vSphere Pods and Supervisor Services are not supported with this configuration. Only the VM Service is available», e nemmeno i persistent volume. Un Supervisor Service presuppone quindi una configurazione con load balancer.

Terzo, il servizio disegnato apposta per questo scenario è la Local Consumption Interface: «for vSphere Foundation users who do not have access to VCF Automation, the Local Consumption Interface provides an interface within the vSphere Client that allows creation of VMs, VKS Clusters, and Volumes». Su Harbor distingui i due volti: quello regionale, integrato col software depot, e quello che il VI administrator installa come Supervisor Service sul singolo Supervisor, che «does not have connectivity with the software depot».

Trappole tipiche d’esame

  • Registrare non è installare. Il YAML aggiunto a vCenter rende il servizio Active nel catalogo, ma finché non lo installi su un Supervisor nessun namespace lo vede. Due privilegi distinti: Manage Supervisor Services (vCenter) e Manage Supervisor Services on Supervisors (Supervisor).
  • vSphere Pod contro cluster VKS. Il blueprint nomina i vSphere Pod, ma su VVF non c’è NSX: se lo scenario chiede dove girano i container, la risposta è VKS.
  • Il Supervisor «facile» non fa tutto. Nella configurazione semplificata senza load balancer resta solo il VM Service: niente Supervisor Services, niente persistent volume, niente scale-out del control plane.
  • L’upgrade passa da vCenter. Non c’è un comando che aggiorni in loco: prima la nuova versione nel catalogo di vCenter, poi l’installazione sul Supervisor.
  • Il namespace del servizio non è quello del team. L’installazione ne crea uno per le risorse del servizio; cancellarlo o riusarlo come namespace di progetto è l’errore che lo scenario nasconde.