La documentazione Broadcom presenta vSphere Foundation come una «unified workload platform for running VMs and containers side by side in a native Kubernetes runtime». Quel runtime ha un nome preciso: vSphere Supervisor. Attivarlo trasforma uno o più cluster vSphere in un piano di controllo Kubernetes gestito da vCenter, dove gli oggetti Kubernetes convivono con le VM tradizionali nello stesso inventario. Ma la frase «container su vSphere» nasconde due strade molto diverse — i cluster VKS e i vSphere Pod — e su VVF solo la prima è praticabile. Capire perché è il cuore di questo obiettivo.

Il Supervisor su VVF parla VDS, non NSX

Il Supervisor si può configurare con due stack di rete. Con NSX ottieni segmenti virtuali, VPC e il load balancer NSX. Con il vSphere Distributed Switch tutti gli host sono collegati allo stesso VDS e i distributed port group diventano le workload network; per la connettività verso gli utenti DevOps e i servizi esterni serve un load balancer, e la documentazione indica Foundation Load Balancer oppure Avi Load Balancer.

Poiché VVF non comprende NSX, sul nostro perimetro la configurazione è una sola: VDS + Foundation Load Balancer. Il FLB è leggero e incluso con vCenter 9.0, e questa scelta determina tutto il resto — compreso ciò che non potrai fare.

Prima di attivare: i prerequisiti che l’esame chiede a memoria

I requisiti infrastrutturali per l’abilitazione VKS sono espliciti: vCenter 9.0 o successivo, ESX 8.0 U3 o successivo, almeno 3 host ESX con un minimo di 8 CPU e 64 GB di RAM ciascuno, vSphere DRS abilitato in Fully Automated e vSphere HA abilitato. Lo storage deve essere condiviso fra tutti gli host — vSAN, VMFS o NFS — e serve almeno una VM storage policy: il wizard ne chiederà tre distinte (Control Plane, Ephemeral Disk, Image Cache), ma una sola policy può coprirle tutte. Nei deployment multi-zona le policy devono avere la zonal topology abilitata.

Sul fronte rete, il modello con FLB richiede un VDS che colleghi tutti gli host e tre distributed port group (Management Network, Transit Network, Virtual Server Network) con MTU 1600 o superiore, un Kubernetes Services CIDR privato /16 univoco per Supervisor, e la latenza fra cluster della stessa zona entro 100 ms. Servono un server DNS e un server NTP configurati su tutti gli host ESX e su vCenter.

Zone e attivazione

Prima del Supervisor si creano le vSphere Zone: da vCenter, Configure → vSphere Zones → Add New vSphere Zone, assegnando un cluster a ciascuna. Ne serve almeno una, che diventa la Management Zone; per dare HA a livello di cluster al control plane del Supervisor se ne usano tre. Tutti i cluster di una zona devono essere collegati allo stesso VDS.

L’attivazione parte dal menu home del vSphere Client: Supervisor Management → Get Started. Il wizard scorre pagine prevedibili — vCenter Server and Network (stack VDS, load balancer FLB), Supervisor Location (nome, HA del control plane, cluster), Storage (le tre policy), Management Network (assegnazione statica e 5 indirizzi consecutivi: tre nodi, un IP flottante, uno per l’upgrade), Workload Network, Load Balancer (2 IP consecutivi sulla management più i range di VIP) e Advanced Settings (Control Plane Size e i DNS name dell’API server). Le control plane VM sono da 1 a 3, con 4 vCPU, 16 GB di memoria e 16 GB di disco ciascuna.

Il vSphere Namespace è il confine

Un vSphere Namespace «sets the resource boundaries where vSphere Pods, VMs, VKS clusters, and Supervisor Services can run». Concretamente è un resource pool con quote di CPU e memoria, quote di storage che Kubernetes vede come storage class, limiti sul numero di oggetti e permessi assegnati a utenti o gruppi provenienti da vCenter Single Sign-On o da un provider OIDC registrato sul Supervisor. Alla creazione non ha limiti finché non glieli imponi, e può essere mappato fino a tre vSphere Zone.

Deployare un cluster VKS

Dal vSphere Client: Supervisor Management → Namespaces → apri il namespace → Resources → tile Kubernetes → Create Cluster, scegli Cluster API come Cluster Type, la Default Configuration, eventualmente scarichi il manifest YAML e concludi. Da riga di comando si usa la VCF CLI: vcf kubernetes-release get per le versioni disponibili, vcf cluster create -f nome.yaml, vcf cluster list -A, vcf cluster node-pool list. L’accesso passa da vcf cluster kubeconfig get nome --export-file nome.kubeconfig e poi kubectl --kubeconfig nome.kubeconfig get nodes.

Sotto il cofano VKS è un’implementazione di Cluster API: il VM Service gestisce il ciclo di vita delle VM di control plane e worker, la CNI è Antrea (default) o Calico, il CSI paravirtuale gira dentro il cluster e si integra con Cloud Native Storage attraverso il Supervisor, le VM class descrivono configurazioni hardware riutilizzabili e le VKr (vSphere Kubernetes release) forniscono la distribuzione Kubernetes firmata. Nota operativa sulla 9.0: usa nomi univoci per i cluster VKS, non riciclarli.

vSphere Pod e «other services»: dove la strada finisce

Un vSphere Pod è «a VM with a small footprint that runs one or more Linux containers», con riserve di risorse esplicite; sull’host lo esegue lo Spherelet, «a kubelet that is ported natively to ESX», e usa tre tipi di storage (ephemeral VMDK, persistent volume VMDK, container image VMDK). Bello — ma la documentazione è categorica: «vSphere Pods are only supported with Supervisors that are configured with NSX as the networking stack». Su VVF, quindi, i container girano nei cluster VKS, non nei vSphere Pod.

Il corollario tocca anche i Supervisor Services, gli «operatori Kubernetes certificati» che si registrano su vCenter e si installano sul Supervisor: quando li installi «the service YAML file is applied on the Supervisor, and all the vSphere Pods and necessary resources are created». Un Supervisor ne può avere una sola versione attiva alla volta; alcuni sono core service (VKS, Velero), aggiornabili ma non rimovibili. E nel Simplified Supervisor senza load balancer la doc lo dice per esteso: «vSphere Pods and Supervisor Services are not supported with this configuration», niente persistent volume, niente IP esterno per i Service di tipo LoadBalancer, niente scale out del control plane.

Trappole tipiche d’esame

  • «Deploy vSphere Pods» è nel blueprint, ma il vincolo è NSX. Se la domanda descrive un ambiente VVF con networking VDS e chiede come far girare un container, la risposta è un cluster VKS. Il vSphere Pod è la risposta giusta solo dove lo stack di rete è NSX.
  • Supervisor ≠ cluster VKS. Il Supervisor è il piano di controllo che vCenter attiva sui cluster vSphere; i cluster VKS sono cluster Kubernetes conformi upstream che deployi dentro un vSphere Namespace. Attivare il Supervisor non ti dà ancora un cluster su cui far girare workload upstream.
  • Namespace Kubernetes ≠ vSphere Namespace. Il secondo è un oggetto di inventario vSphere con resource pool, quote, storage policy e permessi SSO/OIDC: è lì che si impostano i confini, non con un kubectl create namespace.
  • DRS «abilitato» non basta: deve essere Fully Automated, e HA deve essere attivo. È un dettaglio che l’esame ama trasformare in distrattore, insieme ai 3 host ESX e agli 8 CPU / 64 GB minimi.
  • Il Simplified Supervisor è comodo ma amputato. Senza load balancer perdi persistent volume, Supervisor Services, IP esterni e scale out, e la singola control plane VM è un single point of failure: non è la risposta a una domanda che chiede resilienza o servizi aggiuntivi.