Modulo 3 — Compute

⏱ Tempo di lettura: ~15 minuti 🎯 Obiettivo: capire come si gestiscono nodi, scheduling, live migration, high availability, overcommit di CPU/memoria e hot-plug in OpenShift Virtualization, partendo dai concetti DRS/HA/vMotion che già conosci.

Punto di partenza: il modello vSphere

In vSphere il piano “compute” è quello che gestisci ogni giorno:

Un cluster raggruppa più host ESXi sotto un vCenter.
DRS (Distributed Resource Scheduler) bilancia automaticamente le VM fra gli host in base a CPU/memoria.
vMotion sposta a caldo una VM da un host a un altro.
HA (vSphere HA) riavvia automaticamente le VM se un host muore.
Affinity / anti-affinity rules decidono “queste VM stanno insieme” o “queste due non devono mai stare sullo stesso host”.
L’overcommit di CPU e RAM è praticamente trasparente.
Il hot-add di CPU/RAM/disco/NIC è supportato (con qualche caveat per OS guest).

In OpenShift molti di questi concetti esistono, ma sono distribuiti fra più componenti e con un livello di automazione diverso. È il pezzo dove più si sente il salto culturale.

Il modello OpenShift: nodi, machine, machineSet

OpenShift ha la sua piramide:

        MachineSet  ─── definisce un "gruppo di nodi automatizzati"
            │
            ├─→ Machine  ─── il singolo nodo gestito (cloud o BMC)
            │       │
            │       └─→ Node  ─── il nodo dal punto di vista di Kubernetes
            │                       (= dove girano pod e VM)
            │
            └─→ MachineConfigPool / MachineConfig
                  (= profili di configurazione applicati a gruppi di nodi)

In termini VMware:

Un Node è grossomodo l’equivalente di un host ESXi: è il punto fisico dove girano i workload.
Una Machine è il record che descrive il nodo come gestito da OpenShift (specialmente utile su cloud o bare metal con BMC).
Un MachineSet è simile a un’astrazione di “gruppo di host gestiti automaticamente”: può scalare automaticamente.
Un MachineConfig è simile a un Host Profile di vSphere: un profilo declarative che descrive come deve essere configurato un nodo.

💡 Differenza importante: in vSphere l’host ESXi lo installi tu (manualmente o via Auto Deploy / Host Profiles). In OpenShift, soprattutto su cloud, i nodi vengono creati automaticamente dal MachineSet quando serve, seguendo un’immagine OS predefinita (Red Hat CoreOS) e un MachineConfig.

Tabella di mapping delle feature

Feature vSphere	Equivalente OpenShift
DRS (rebalancing automatico delle VM fra host)	Descheduler Operator + scheduler Kubernetes
vMotion (live migration)	Live Migration delle VM (basata su `virtctl migrate`)
vSphere HA (riavvio VM su altro host se ESXi muore)	Combinazione di Node Health Check Operator + fencing agents + scheduler
Affinity / anti-affinity rules	`nodeAffinity`, `podAffinity`, `podAntiAffinity` su VM e nodi
Overcommit CPU	Supportato (rapporto CPU virtuali/fisici configurabile)
Overcommit RAM	Supportato via KSM (Kernel Same-page Merging) e free page reporting
Hot-add CPU / RAM / disco / NIC	Supportato con limitazioni che dipendono dalla feature e dall’OS guest
vCenter, Aria Operations (metriche)	OpenShift Monitoring (Prometheus/Grafana) + Advanced Cluster Management (multi-cluster)
Templates, content libraries, OVA	VM templates, boot sources, instance types, DataVolumes
Import/export OVA/OVF	Migration Toolkit for Virtualization (MTV) + export OVA nativo
PCI passthrough, vGPU	PCI passthrough generico, GPU passthrough, NVIDIA vGPU supportata

Sotto Compute trovi una serie di voci che parlano di nodi e di automazione:

Voce di menu	A cosa serve	Equivalente per admin VMware
Nodes	Lista dei nodi del cluster, con stato, ruolo, risorse, taint	È la vista “Hosts and Clusters” di vCenter
NodeHealthChecks (richiede l’omonimo operator)	Definisce le regole di remediation se un nodo è in stato anomalo	Concettualmente vicino a vSphere HA: “se il nodo non risponde, fai X”
Machines	Vista delle macchine gestite dal Machine API operator	Visibile su provider cloud o bare-metal con BMC
MachineSets	Definizione dei gruppi di nodi scalabili	Un mix di Host Profile + automazione di provisioning
MachineAutoscalers	Regole di scaling automatico dei MachineSet	Equivalente di “scala in automatico l’infrastruttura quando serve”
MachineHealthChecks	Remediation più aggressiva: cancella la Machine e ne crea una nuova	Utile su cloud / bare metal con re-install automatico
Bare Metal Hosts (Operator dedicato)	Server fisici aggiunti al cluster, integrati con BMC	Il “Day 2” del bare metal: full lifecycle dell’hardware
MachineConfig / MachineConfigPool	Configurazioni dichiarative per i nodi (kernel arg, file, servizi)	È la versione moderna degli Host Profile
Hardware Devices	Gestione di device hardware esposti alle VM (es. GPU, vGPU)	Non ha un parente diretto in vSphere, è specifica di KubeVirt

Live migration: come funziona davvero

La live migration in OpenShift Virtualization è basata sulla migration nativa di KVM/QEMU. Concettualmente:

  Nodo A                                  Nodo B
  ┌─────────────────┐                    ┌─────────────────┐
  │  VM web01       │  ─────────────▶    │  VM web01       │
  │  (running)      │   memoria pre-     │  (running)      │
  │                 │   copia + dirty    │                 │
  └─────────────────┘   page tracking    └─────────────────┘

I prerequisiti sono simili a quelli di vMotion:

Lo storage della VM deve essere accessibile da entrambi i nodi → PVC con accessMode RWX (oppure meccanismi specifici per RWO).
Connettività di rete sufficiente fra i nodi (raccomandata una dedicated migration network in casi di traffico intenso, esattamente come la rete vMotion dedicata).
La VM non deve avere device “incompatibili” con la migrazione (es. PCI passthrough di una GPU specifica del nodo).

Comando CLI per migrare:

# Migrazione manuale di una VM
virtctl migrate web01 -n produzione-web

# Verifica stato
oc get vmim -n produzione-web

# Cancellare una migrazione in corso
virtctl migrate-cancel web01 -n produzione-web

In modo declarative puoi anche definire una MigrationPolicy che descrive parametri di migrazione (timeout, banda, post-copy se necessario):

apiVersion: migrations.kubevirt.io/v1alpha1
kind: MigrationPolicy
metadata:
  name: prod-default
spec:
  selectors:
    namespaceSelector:
      env: prod
  allowAutoConverge: true
  bandwidthPerMigration: 1Gi
  completionTimeoutPerGiB: 60

💡 Migrazione network dedicata. Come per vMotion, è raccomandato definire una rete dedicata per la live migration su traffico intenso. Si configura tramite l’oggetto HyperConverged (CR principale dell’operator OpenShift Virtualization), specificando una NetworkAttachmentDefinition.

DRS vs Descheduler: la grande differenza

Qui c’è il salto concettuale più grande per un admin VMware. Il DRS vSphere è un componente proattivo: monitora costantemente CPU/RAM degli host e sposta VM per bilanciare. Lo fa in modo continuo e con tante euristiche.

In OpenShift il bilanciamento non è una feature monolitica accesa di default:

Lo scheduler Kubernetes è il principale responsabile del placement iniziale: quando una VM viene avviata, lo scheduler sceglie il nodo migliore in base a risorse richieste, affinity, taint/toleration, score plugin.
Il Descheduler Operator è il componente che si avvicina di più al DRS: gira periodicamente, identifica pod/VM “mal posizionati” rispetto a una serie di policy (LowNodeUtilization, RemovePodsViolatingNodeAffinity, RemovePodsViolatingInterPodAntiAffinity…) e li rimuove. Il rescheduling lo fa poi lo scheduler standard.

Per le VM c’è una sottigliezza: il descheduler non “spegne” una VM, ma può triggerare una live migration automatica se la VM è eligible. Va però configurato con consapevolezza: non è “DRS plug-and-play”.

# Esempio di KubeDescheduler con strategia low-utilization (semplificato)
apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  managementState: Managed
  deschedulingIntervalSeconds: 600
  profiles:
    - LongLifecycle

💡 Realismo operativo. Per molti clienti che vengono da DRS, la modalità tipica è: scheduler Kubernetes + descheduler con LowNodeUtilization e LongLifecycle profile, e affinity rules di base. È un pelo meno “magico” del DRS, più trasparente, più declarative.

High availability delle VM

In vSphere “HA” è una checkbox nel cluster e funziona out-of-the-box. In OpenShift servono più pezzi:

Node Health Check Operator: definisce quando un nodo è considerato malato (es. NotReady per più di N minuti).
Fencing agent: il meccanismo che “spegne” il nodo in modo affidabile (via BMC IPMI/Redfish, su bare metal, oppure tramite cloud API). Senza fencing, il rischio è lo split brain: il nodo torna su mentre le VM sono già state schedulate altrove.
Scheduler Kubernetes: a quel punto, riposiziona le VM sui nodi sani.

Tempi tipici: dell’ordine di minuti (60-120 secondi a seconda di configurazione e fencing). vSphere HA è di solito più veloce nei rilevamenti di default. Per workload critici è importante:

avere il fencing configurato e testato, non solo abilitato sulla carta;
definire PriorityClass alte per le VM critiche, così che vincano la corsa allo scheduling;
distribuire le VM critiche con anti-affinity fra zone/rack.

⚠️ Senza il setup HA esplicito, una VM su un nodo che muore non ripartirà automaticamente. Questa è una delle prime cose che chi viene da vSphere si deve ricordare di abilitare.

💡 Infrastructure-level HA vs Application-level HA. Quanto descritto sopra è il primo livello: “se il nodo muore, la VM riparte altrove” (tempi dell’ordine dei minuti). Per servizi che non possono permettersi nemmeno quel downtime — database in cluster, file server in active/active — il secondo livello è l’HA applicativa: pacemaker su Linux, WSFC su Windows. Funziona dentro le VM esattamente come funziona in vSphere, e OpenShift fornisce un fence agent dedicato (fence_kubevirt). I dettagli nel Modulo 8 — Approfondimenti.

Overcommit CPU e memoria

OpenShift Virtualization supporta l’overcommit, con due meccanismi principali per la memoria:

KSM (Kernel Same-page Merging): il kernel deduplicare pagine identiche fra VM diverse. È l’analogo concettuale del Transparent Page Sharing di ESXi, ed è abilitato di default sui nodi RHCOS.
Free page reporting: la VM “restituisce” all’hypervisor le pagine di memoria che ha liberato (richiede QEMU guest agent / virtio-balloon nel guest).

L’overcommit di CPU è gestito a livello di scheduler (CPU requests vs limits) e dalla configurazione cpuAllocationRatio dell’operator. Il principio è simile a vSphere: dichiara meno di quello che hai e lascia che lo scheduler venda l’overcommit.

Pratica consigliata: parti conservativo (overcommit 1:1 o 1.5:1 per la CPU) e aumenta dopo aver visto dati reali con la suite Monitoring.

Hot-plug: cosa puoi (e non puoi) cambiare a caldo

Lo stato attuale supportato del hot-plug in OpenShift Virtualization:

Componente	Hot-add	Hot-remove	Note
CPU	✅	❌ (non hot-remove)	Aumento del numero di vCPU senza riavvio
Memoria	✅	❌	Espansione della RAM a caldo (richiede guest virtio-mem)
Disco (PVC come volume)	✅	✅	Aggiungere/rimuovere dischi senza riavvio
NIC bridge / SR-IOV	✅	✅	Hot-plug delle interfacce di rete secondarie
GPU / PCI passthrough	❌	❌	Richiede stop della VM

Per i dettagli sulle versioni che hanno introdotto ciascuna feature, consulta sempre il release notes della versione di OCP — questo è uno dei pezzi che evolve più velocemente.

Esempio pratico: anti-affinity per VM database

Vuoi che le tue tre VM di un cluster PostgreSQL non finiscano mai sullo stesso nodo (in vSphere lo faresti con una “Separate Virtual Machines” rule):

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: pg01
  labels:
    app: postgres-cluster
spec:
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - postgres-cluster
              topologyKey: kubernetes.io/hostname
      domain:
        ...

Tradotto: “non schedulare questa VM su un nodo (topologyKey: kubernetes.io/hostname) dove gira già un’altra VM con app=postgres-cluster”. Funziona allo stesso modo per spalmare su zone, rack, racchetta — basta cambiare la topologyKey.

Templates, instance types e boot sources

Il flusso “deploy from template” di vSphere si traduce in OpenShift in tre concetti complementari:

Boot Source: l’immagine OS di partenza (RHEL 9, Windows 2022, Fedora…). È un PVC immutabile gestito dall’operator, scaricato la prima volta dal Red Hat registry.
VM Template: una definizione completa di VirtualMachine pre-confezionata (CPU, RAM, dischi, network, OS) — concettualmente vicino a un VM template di vCenter.
Instance Type (più recente): una sorta di “T-shirt size” (small/medium/large) che descrive solo il profilo di risorse, indipendente dall’OS. Ti permette di combinare instance type + boot source per creare VM senza scrivere YAML da zero.

Un admin VMware ritrova qui qualcosa di familiare: “cataloghi predefiniti”, deploy guidato, slider per la dimensione.

Import / Export di VM esistenti

Per portare VM da vSphere a OpenShift Virtualization, lo strumento di riferimento è Migration Toolkit for Virtualization (MTV): connettore vCenter, mappatura network/storage, migrazione cold/warm.

Per export OVA dalla piattaforma OpenShift c’è il flusso VirtualMachineExport. Dettagli operativi nel modulo 6 — Operazioni quotidiane.

Differenze chiave da tenere a mente

DRS automatico non c’è di default. Il descheduler ci si avvicina, ma va configurato.
HA delle VM richiede fencing configurato. Non è una checkbox.
L’unità di gestione è il nodo, non l’host ESXi. I nodi possono essere bare metal, VM (sì, su vSphere stesso!), o cloud instance. La piattaforma è agnostica.
Lo scheduler è declarative. Affinity, taint, toleration sono in YAML versionabili in Git. Niente più rule “definite con i clic”.
Hot-plug supporta meno tipi di operazioni di vSphere (in particolare, hot-remove di CPU/RAM non c’è). Pianifica un buon sizing iniziale.
L’autoscaling dei nodi su cloud è nativo: se il cluster ha bisogno di più capacity e usi un MachineAutoscaler, OpenShift compra letteralmente nuovi nodi su AWS/Azure/GCP. È una capability che vSphere on-prem non ha senza vRA/Aria.

Best practice operative

Definisci PriorityClass chiare (system-cluster-critical, production, dev) e applicale alle VM. Sotto pressione di risorse, lo scheduler le rispetterà.
PodDisruptionBudget per gruppi di VM: definisci quante VM dello stesso “ruolo” possono andare giù contemporaneamente. Salvavita durante upgrade dei nodi.
Configura il descheduler in modalità conservative all’inizio (intervalli lunghi, profile LongLifecycle).
Testa il fencing: stacca un nodo e cronometra. Se i tempi non ti soddisfano, accorcia gli intervalli del Node Health Check.
Migration network dedicata per i cluster con tante VM e/o VM grandi (>8 GB RAM): evita di intasare la rete pod normale durante le migrazioni.

Approfondimenti ufficiali

← Modulo 2 — Networking | Avanti → Modulo 4 — Observability