Il Supervisor è il pezzo di vSphere Foundation che molti amministratori toccano per ultimo e che l’esame invece chiede di saper configurare a mente fredda, con i campi giusti nell’ordine giusto. Qui vediamo il caso che il blueprint nomina esplicitamente: il Supervisor dentro un cluster, non distribuito su tre zone.

Che cosa attivi davvero

Quando attivi il Supervisor su un cluster vSphere, vCenter costruisce un piano di controllo Kubernetes che consente di eseguire workload in modo dichiarativo sul cluster. Non è una singola appliance: sono da una a tre control plane VM, collocate sugli host ESX da vSphere DRS, più un processo Spherelet su ogni host — la documentazione lo descrive come un kubelet portato nativamente su ESX, ed è ciò che fa partecipare gli host al cluster Kubernetes. Sopra girano il Virtual Machine Service, responsabile del deployment di VM stand-alone e dei nodi dei cluster VKS, e i moduli VKS/Cluster API. Quando il control plane è in alta disponibilità, le tre VM hanno indirizzi IP individuali, un IP flottante e un IP riservato per le patch: sono indirizzi da prevedere nella subnet di management, non tre.

«Within a Cluster» significa che il Supervisor vive in un solo cluster vSphere, cioè una sola vSphere Zone. Nel wizard è l’opzione Cluster Deployment, contrapposta a vSphere Zones Deployment, che colloca ciascuna control plane VM in una zona diversa. Con un cluster solo, attivare l’alta disponibilità del control plane ti protegge dal guasto di un host, non dal guasto del cluster.

I prerequisiti che fanno fallire il wizard

Il cluster deve avere vSphere DRS e vSphere HA attivi, con DRS in Fully Automate mode: questo è il controllo che più spesso blocca l’attivazione. Servono tre host ESX, quattro se il cluster usa vSAN, con 8 vCPU e 64 GB di memoria per host; ogni control plane VM chiede 4 vCPU, 16 GB di memoria e 16 GB di storage.

Sul fronte rete, in VVF lo stack è quello di vSphere: un vSphere Distributed Switch e port group distribuiti dedicati — uno di Management, uno di Transit Network, uno di Virtual Server Network e almeno uno di Workload. L’MTU deve essere 1600 o superiore su qualunque distributed port group coinvolto. La subnet di workload non deve sovrapporsi a quella di management, e il CIDR riservato ai Kubernetes Services è un /16 privato univoco per ogni Supervisor. Devono essere raggiungibili DNS e NTP, e va garantito il routing fra la Supervisor Management Network e vCenter e fra quella rete e la vmkernel management NIC usata dallo Spherelet. Infine: si accede al Supervisor per FQDN, non per indirizzo IP, altrimenti si incappa in problemi di certificato.

Le storage policy: tre campi, non uno

Prima del wizard vanno create le VM Storage Policy da Menu > Policies and Profiles > VM Storage Policies > Create VM Storage Policy, tipicamente con le tag-based placement rules sui datastore. Il wizard del Supervisor chiede tre policy distinte: Control Plane Storage Policy, Ephemeral Disks Storage Policy e Image Cache Storage Policy. La prima decide su quali datastore finiscono le control plane VM; le altre due servono ai dischi effimeri e alle immagini dei container. Nulla vieta di puntarle tutte alla stessa policy su un datastore vSAN, ma restano tre campi da compilare.

Il percorso completo con Foundation Load Balancer

Dal menu home si apre Supervisor Management e si clicca Get Started. Nella pagina vCenter Server and Network si sceglie il vCenter, il vSphere Distributed Switch e, in Load Balancer Type, il Foundation Load Balancer; qui c’è anche l’opzione per attivare l’alta disponibilità del control plane a tre nodi. In Supervisor location si sceglie Cluster Deployment, indicando nome, datacenter e una zona compatibile. Seguono Storage con le tre policy; Management Network, in DHCP o Static con Network, IP Addresses, Subnet Mask, Gateway, DNS Servers, DNS Search Domains, NTP Servers; Workload Network con Network Name, Port Group e il CIDR interno per i servizi Kubernetes. La pagina Load Balancer chiede nome, Network Topology (One Arm o Two Arm), Size (Small, Medium, Large, Extra Large), il numero di VM per l’alta disponibilità e le tre reti — Management, Virtual Server, Transit — ciascuna con port group, range IP, maschera e gateway. In Advanced Settings si imposta Control Plane Size e, opzionalmente, gli API Server DNS Names; si può esportare la configurazione. Poi Ready to complete e Finish.

La via breve: Easy Supervisor, e quello che ti costa

Sul cluster, Actions > Activate Supervisor apre la versione semplificata: si sceglie DHCP o Static, si indica il Port Group che farà da Primary Workload Network, il Service CIDR, l’FQDN, una storage policy per la control plane VM, e si clicca Activate.

Il prezzo è alto e va conosciuto: una sola control plane VM con una sola vNIC e nessun load balancer. Senza load balancer non sono supportati vSphere Pod né Supervisor Services — è disponibile solo il VM Service — non c’è provisioning di volumi persistenti, i Service Kubernetes di tipo LoadBalancer non ottengono un IP esterno e lo scale-out del control plane è impossibile. Aggiungendo poi un load balancer si può passare da 1 a 3 control plane VM da Configure > General > Control Plane, cliccando Activate accanto a «Control Plane HA is not activated»: operazione che non si torna indietro.

Dopo l’attivazione

La taglia del control plane si cambia da Supervisor Management > Supervisor > Configure > General > Control Plane Size > Edit: Tiny (2 CPU, 8 GB), Small (4 CPU, 16 GB), Medium (8 CPU, 24 GB), Large (16 CPU, 32 GB), sempre con 32 GB di storage. Si può solo scalare verso l’alto, e serve il privilegio Modify cluster-wide configuration. Le workload network aggiuntive si creano da Configure > Network > Workload Network > Add, con range IP univoci per ciascuna; se il Supervisor è stato configurato in DHCP, non se ne aggiungono. I vSphere Namespace, infine, ottengono un resource pool dedicato nel Supervisor, quote di CPU, memoria e storage, permessi da vCenter Single Sign-On o da un provider OIDC registrato, e l’associazione a storage policy e content library.

Trappole tipiche d’esame

  • VVF non ha NSX, quindi niente vSphere Pod. La documentazione è netta: i vSphere Pod sono supportati solo con Supervisor configurati con NSX come networking stack. Su vSphere Foundation i container girano nei cluster VKS, e il Supervisor usa lo stack VDS con Foundation Load Balancer. Se una risposta propone vSphere Pod su un Supervisor con VDS, è la distrattrice.
  • Easy Supervisor non è «lo stesso Supervisor, più veloce». Senza load balancer perdi volumi persistenti, Supervisor Services e scale-out. Uno scenario che chiede volumi persistenti esclude la configurazione semplificata.
  • DRS «attivo» non basta: deve essere in Fully Automate mode, insieme a vSphere HA. Partially Automated è una risposta sbagliata travestita da ragionevole.
  • Control Plane Size e numero di control plane VM sono due cose diverse. La taglia (Tiny/Small/Medium/Large) si scala solo verso l’alto; il passaggio da 1 a 3 VM è l’attivazione dell’HA del control plane ed è irreversibile.
  • Dettagli di rete che l’esame ama: MTU 1600 o superiore sui distributed port group (non 1500), subnet di workload distinta da quella di management, CIDR /16 privato e univoco per i Kubernetes Services, accesso per FQDN e non per IP.