Modulo 8 — Approfondimenti

⏱ Tempo di lettura: ~25 minuti 🎯 Obiettivo: coprire quattro argomenti che il learning path principale tocca di sfuggita ma che diventano importanti in scenari reali: il modello RBAC come “permessi a folder/cluster” di vCenter, gli Hosted Control Planes come pattern multi-tenant, le VM ad alte prestazioni (NUMA, huge pages, reservation), e l’HA a livello applicativo (pacemaker, WSFC).

Questo modulo integra il materiale del corso Red Hat Map vSphere features to OpenShift Virtualization.

Indice

Access Control: il modello RBAC vs i permessi vCenter
Hosted Control Planes: cluster dentro cluster
High-Performance VMs: NUMA, huge pages, reservation
Application-level HA: pacemaker e WSFC su OpenShift

1. Access Control: il modello RBAC vs i permessi vCenter

Il modello vCenter che già conosci

In vSphere l’access control è gerarchico e organizzato per “scope”:

Datacenter, Cluster, Folder, VM, Network, Datastore sono tutti oggetti su cui si possono attribuire permessi.
I Ruoli (es. Administrator, Virtual Machine Power User, Read-only) sono predefiniti, e possono essere personalizzati.
I Permessi legano un ruolo a un utente/gruppo su un oggetto specifico, con o senza propagazione ai figli.

Esempio tipico: “il team applicativo X ha Virtual Machine Power User sulla folder Produzione-WebApp, propagato ai figli”. Pulito, intuitivo, ma vincolato alla gerarchia di vCenter.

Il modello OpenShift: RBAC + namespace

OpenShift usa il Role-Based Access Control (RBAC) standard di Kubernetes, con qualche aggiunta:

              ┌────────────────────────────────────────┐
              │                Cluster                 │
              │                                        │
              │   ┌──────────────────────────────┐     │
              │   │       ClusterRole            │     │
              │   │  (regole "cosa puoi fare")   │     │
              │   └──────────────┬───────────────┘     │
              │                  │                     │
              │     ┌────────────┴────────────┐        │
              │     ▼                         ▼        │
              │  ClusterRoleBinding     RoleBinding    │
              │  (permessi a livello     (permessi     │
              │   cluster, su tutto)      su singolo   │
              │                           namespace)   │
              │                                        │
              └────────────────────────────────────────┘

Quattro componenti chiave:

Role / ClusterRole: definiscono cosa si può fare (verbi: get, list, create, update, delete) su quali risorse (kind: vm, vmi, pod, service…). Un Role è scoped a un namespace, un ClusterRole vale ovunque.
RoleBinding / ClusterRoleBinding: legano un Role/ClusterRole a un utente, gruppo o ServiceAccount.

Mapping concettuale

Concetto vSphere	Equivalente OpenShift
Datacenter / Cluster (scope di permessi)	Cluster (root del RBAC, controllabile via ClusterRoleBinding)
Folder	Namespace (organizzazione + isolamento RBAC)
Ruolo predefinito Administrator	ClusterRole `cluster-admin`
Ruolo predefinito Virtual Machine Power User	ClusterRole `kubevirt.io:edit` (gestione VM in un namespace)
Ruolo predefinito Read-only	ClusterRole `view`
Ruolo custom	ClusterRole/Role custom (definito in YAML)
Permesso “user X su folder Y”	RoleBinding di un utente a un namespace
Permesso ereditato dai figli	Implicito: chi ha permesso sul namespace ha permesso su tutte le risorse dentro

I tre ruoli “default” di OpenShift Virtualization

OpenShift Virtualization aggiunge tre ruoli pronti all’uso per la gestione delle VM:

ClusterRole	Cosa permette	Equivalente concettuale vCenter
`kubevirt.io:admin`	Gestione completa di VM e risorse correlate nel namespace	Administrator limitato alla folder
`kubevirt.io:edit`	Creare, modificare, avviare/fermare VM	Virtual Machine Power User
`kubevirt.io:view`	Solo lettura: lista VM, vedere stato, accedere alla console in read-only	Read-only / Virtual Machine User

Esempio pratico: dare al team “pagamenti” il controllo del proprio namespace

In vSphere assegneresti Virtual Machine Power User alla folder Pagamenti-Prod per il gruppo gr-team-pagamenti. In OpenShift:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pagamenti-vm-edit
  namespace: pagamenti-prod
subjects:
  - kind: Group
    name: gr-team-pagamenti
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: kubevirt.io:edit
  apiGroup: rbac.authorization.k8s.io

Il gruppo gr-team-pagamenti (sincronizzato da LDAP/IdP esterno) ha ora pieno controllo delle VM nel namespace pagamenti-prod, ma non può vedere nulla negli altri namespace, e non ha permessi cluster-wide.

Quando il modello RBAC è più potente di vCenter

Tre scenari dove RBAC vince:

Granularità sulle azioni. Puoi creare un ruolo che permette di avviare e fermare una VM ma non di modificare la sua definizione. In vCenter le permission sono granulari, ma RBAC arriva al livello dei singoli verbi sull’API.
Custom resource. Se aggiungi un operator (es. ODF, MTV, ACM), le sue risorse sono soggette a RBAC come tutto il resto. Un team che gestisce le migrazioni MTV può avere accesso al “kind” Plan senza poter toccare le VM.
Service Account. Ogni applicazione/script automatizzato gira con un ServiceAccount dedicato, che ha solo i permessi che gli servono. È molto più pulito del “service account vCenter con privilegi globali” che si finiva spesso a creare.

Quando il modello vCenter è più semplice

Onestà: per un admin VMware, la “folder hierarchy” è più immediata di namespace + label. Tre cose che richiedono adattamento:

Niente gerarchia di folder. I namespace sono “piatti” — non puoi avere Produzione/WebApp/Frontend annidato. Si compensa con label e con convenzioni di naming (prod-webapp-frontend).
Permessi “trasversali”. Per dire “questo utente vede tutte le VM in produzione, su qualunque namespace” servono pattern come ClusterRole con resourceNames o hook a sistemi esterni (Open Policy Agent / Kyverno).
Audit dei permessi richiede tooling. oc auth can-i ti dice se un utente può fare qualcosa, ma per una vista d’insieme tipo “chi può accedere a cosa” servono strumenti come rbac-tool o ACM Governance.

Approfondimenti ufficiali

2. Hosted Control Planes: cluster dentro cluster

Il problema che risolvono

In vSphere, “creare un cluster Kubernetes per il team X” significa di solito:

creare 3 VM control-plane + N VM worker;
installarle, configurarle, mantenerle;
avere un cluster vSphere che ospita un cluster Kubernetes dentro VM.

È funzionale ma pesante: ogni nuovo cluster Kubernetes richiede 3+ VM per il solo control plane, con consumo di risorse e overhead di management.

La soluzione OpenShift: Hosted Control Planes (HCP)

Hosted Control Planes è un modello dove il control plane di un cluster “figlio” gira come pod dentro un cluster “padre”, invece che su VM dedicate. Solo i nodi worker del cluster figlio sono “veri” — possono essere VM (anche su OpenShift Virtualization), bare metal, o cloud instance.

   ┌──────────────────────────────────────────────────────────┐
   │                  Cluster "host" (padre)                  │
   │                                                          │
   │   ┌──────────────────┐  ┌──────────────────┐             │
   │   │  HCP del         │  │  HCP del         │  ...        │
   │   │  cluster A       │  │  cluster B       │             │
   │   │  (etcd, kube-    │  │  (etcd, kube-    │             │
   │   │   apiserver,     │  │   apiserver,     │             │
   │   │   controller-mgr)│  │   controller-mgr)│             │
   │   │  → girano come   │  │  → girano come   │             │
   │   │    pod qui       │  │    pod qui       │             │
   │   └──────────────────┘  └──────────────────┘             │
   │                                                          │
   └──────────────────────────────────────────────────────────┘
            │                          │
            ▼                          ▼
      Worker nodes                Worker nodes
      cluster A                   cluster B
      (VM su CNV /                (VM su CNV /
      bare metal / cloud)         bare metal / cloud)

Vantaggi

Densità. Niente più 3 VM da 4 vCPU sprecate per il control plane di ogni cluster. Su un cluster host singolo puoi ospitare decine di control plane figli.
Tempi di provisioning. Creare un nuovo cluster figlio richiede minuti, non ore. Il control plane è “solo” un set di pod.
Aggiornamenti più facili. Patchare il control plane di un cluster significa rolling update di pod, non reinstallazione di VM.
Multi-tenancy economico. Ogni team può avere il suo cluster “monouso” senza dover negoziare la condivisione delle risorse.

Mapping concettuale

Pattern vSphere	Pattern OpenShift con HCP
Cluster Kubernetes deployato su VM con Tanzu Kubernetes Grid (TKG)	Cluster figlio con HCP, control plane come pod
Provisioning con Cluster API + vSphere provider	Provisioning con HyperShift + KubeVirt provider
3 VM control-plane per ogni cluster	0 VM control-plane (girano come pod)
vCenter come management plane multi-cluster	RHACM + HyperShift

Quando ha senso usare HCP

Hai più team che vogliono cluster propri (dev, QA, staging, prod x N).
Vuoi minimizzare l’overhead di management plane sul cluster fisico/principale.
Vuoi tempi di creazione cluster nell’ordine dei minuti, tipico di scenari self-service.

Quando non ha senso: cluster con requisiti molto specifici di tuning del control plane, o quando il cluster host non è abbastanza grande/affidabile da ospitare control plane critici.

Approfondimenti ufficiali

3. High-Performance VMs: NUMA, huge pages, reservation

Il problema

Per la maggior parte delle VM (web server, app stateless, DB di sviluppo) le impostazioni di default sono perfette. Per workload latency-sensitive o throughput-intensive — database in-memory, data warehousing, analytics, servizi telco — servono ottimizzazioni specifiche, esattamente come in vSphere fai con NUMA awareness, huge pages, latency sensitivity, resource reservations, SIOC/NIOC.

OpenShift Virtualization supporta gli equivalenti, ma li espone come oggetti dichiarativi.

Mapping concettuale

Feature vSphere	Equivalente OpenShift Virtualization
NUMA awareness (CPU/RAM “vicine”)	NUMA-aware scheduling (con CPU Manager + Topology Manager)
Large pages / huge pages (TLB efficiency)	Hugepages (1Gi o 2Mi, esposte come risorsa allocabile)
CPU reservation / shares	`cpu.requests` = `cpu.limits` (Guaranteed QoS class)
Memory reservation	`memory.requests` = `memory.limits`
Latency Sensitivity = High	`dedicatedCpuPlacement: true` + `isolateEmulatorThread: true`
SIOC (Storage I/O Control)	Storage CSI con QoS / IOPS limit (driver-dependent)
NIOC (Network I/O Control)	NetworkPolicy + bandwidth annotations (limitato)
CPU/Memory shares (priorità in contesa)	PriorityClass + QoS class

Esempio: VM database con NUMA pinning + huge pages

Una VM che ospita un PostgreSQL ad alte performance, con:

16 vCPU “pinned” su un nodo NUMA singolo,
32 Gi di RAM in huge pages 1Gi,
garanzia di non venir mai migrata o evicted.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: pg-prod-01
  namespace: pagamenti-prod
spec:
  template:
    spec:
      domain:
        cpu:
          sockets: 1
          cores: 16
          dedicatedCpuPlacement: true       # CPU pinning
          isolateEmulatorThread: true       # thread emulator su CPU separata
          numa:
            guestMappingPassthrough: {}     # NUMA topology dal nodo alla VM
        memory:
          guest: 32Gi
          hugepages:
            pageSize: 1Gi                   # huge pages 1 GiB
        resources:
          requests:
            memory: 32Gi
            cpu: "16"
          limits:
            memory: 32Gi
            cpu: "16"
      evictionStrategy: External            # protezione contro live migration
      priorityClassName: production-critical

Punti chiave del manifest:

dedicatedCpuPlacement: true → la VM ottiene CPU “esclusive” sul nodo, non condivise con altri pod.
requests = limits per CPU e memoria → la VM finisce nella Guaranteed QoS class (la più alta), che la rende l’ultima a essere evictata.
hugepages: pageSize: 1Gi → richiede che il nodo abbia huge pages 1Gi pre-allocati nel kernel (configurabile via MachineConfig).
evictionStrategy: External → niente live migration automatica triggerata dal descheduler.

Configurare il nodo per le huge pages

Le huge pages vanno pre-allocate al boot del nodo, non sono dinamiche. Si fa con un MachineConfig che modifica i kernel arg:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker-hp
  name: 50-hugepages-worker-hp
spec:
  kernelArguments:
    - hugepagesz=1G
    - hugepages=64           # 64 huge pages da 1Gi = 64 Gi pre-allocati

Ovviamente, i nodi con questo profilo (role: worker-hp) andranno scelti con cura: dedicati alle VM ad alte prestazioni, con un MachineConfigPool separato.

NUMA-aware scheduling

Per far sì che lo scheduler di OpenShift consideri la topologia NUMA dei nodi, vanno abilitati due manager:

CPU Manager in modalità static (decide allocazione CPU per pod)
Topology Manager in modalità single-numa-node (allinea CPU + memoria
- dispositivi PCI sullo stesso NUMA node)

Si configurano via PerformanceProfile del Node Tuning Operator:

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: high-perf-vm
spec:
  cpu:
    isolated: "4-31"        # CPU "isolate" per le VM
    reserved: "0-3"         # CPU per il sistema operativo del nodo
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      - size: 1G
        count: 64
  numa:
    topologyPolicy: single-numa-node
  realTimeKernel:
    enabled: false           # solo se servono workload real-time
  nodeSelector:
    node-role.kubernetes.io/worker-hp: ""

💡 Quando vale la pena. Tutto questo introduce complessità operativa. Per il 90% delle VM non serve. Riservalo a workload dove hai metriche reali (latenza p99, throughput) che dimostrano che il default non basta.

Approfondimenti ufficiali

4. Application-level HA: pacemaker e WSFC su OpenShift

Due livelli di HA, da non confondere

Quando si parla di HA per VM, ci sono due livelli distinti:

Infrastructure-level HA (= “se il nodo muore, la VM riparte altrove”). È quella che abbiamo coperto nel modulo Compute: richiede Node Health Check + fencing, con tempi nell’ordine dei minuti.
Application-level HA (= “il servizio applicativo non si ferma mai, anche se un nodo o una VM muoiono”). Questo è il livello dove si usano tool tradizionali come pacemaker (per Linux) o Windows Server Failover Cluster (WSFC), con tempi di failover di pochi secondi.

In vSphere fai esattamente la stessa distinzione: vSphere HA è il primo livello, RHEL HA / WSFC dentro le VM è il secondo. Funziona uguale in OpenShift Virtualization, e questa è una buona notizia per chi ha già applicazioni cluster-aware.

Mapping concettuale

Scenario	vSphere	OpenShift Virtualization
Nodo muore → VM riparte altrove	vSphere HA (auto, 15-30s)	Node Health Check + fencing (~minuti)
Servizio Linux highly-available (es. database)	RHEL HA con pacemaker dentro le VM	RHEL HA con pacemaker dentro le VM (identico)
Servizio Windows highly-available (es. SQL Server, file server)	WSFC dentro le VM	WSFC dentro le VM (identico)
Storage shared per cluster Linux	iSCSI / FC / NFS	PVC RWX su CSI / Fibre Channel direct
Storage shared per WSFC	RDM / shared VMDK	iSCSI direct dentro la VM, o block-mode PVC

Cosa cambia operativamente

Le tecnologie pacemaker e WSFC funzionano dentro le VM, quindi la maggior parte della configurazione è identica a quella che già conosci. Ci sono però tre punti di attenzione specifici di OpenShift Virtualization:

1. Storage shared

Per un cluster di database con pacemaker servono dischi condivisi. In vSphere usavi multi-writer VMDK o RDM. In OpenShift le strade sono:

PVC con accessMode RWX dove tutti i nodi del cluster pacemaker accedono allo stesso volume. Funziona se il driver CSI supporta block-mode RWX (Ceph RBD con clustered FS, alcuni driver SAN).
Connessione iSCSI/FC dalla guest direttamente al backend storage, bypassando OpenShift. È il pattern più “tradizionale” e quello che funziona meglio con cluster pacemaker complessi.
Fibre Channel passthrough (con FC HBA passthrough alla VM, supportato in alcune configurazioni hardware).

2. Anti-affinity esplicita

Le VM del cluster HA devono girare su nodi diversi. In vSphere lo facevi con DRS anti-affinity rule. In OpenShift Virtualization usi podAntiAffinity sulle VM (vedi esempio in Modulo 3 — Compute):

spec:
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: cluster-pacemaker
                    operator: In
                    values: ["pgsql-prod"]
              topologyKey: kubernetes.io/hostname

3. Fencing del cluster pacemaker

Il pacemaker stesso ha bisogno di fencing per evitare split brain. I fencing agent storici (IPMI, iLO, iDRAC, DRAC, vCenter) sono tutti nel pacchetto fence-agents. Per OpenShift Virtualization c’è il fence agent fence_kubevirt che permette al pacemaker di “spegnere” una VM tramite l’API KubeVirt. È il pattern più pulito, perché il pacemaker non deve sapere nulla del nodo fisico sottostante.

Approfondimenti ufficiali

Riassunto del modulo

Quattro temi spesso “saltati” in introduzioni:

RBAC è il modello permission di OpenShift: più granulare di vCenter sui verbi, più piatto sulla gerarchia. Tre ruoli pronti per le VM.
Hosted Control Planes è la risposta moderna al “creare cluster Kubernetes”: niente più 3 VM control-plane per cluster figlio. Il pattern da conoscere se gestisci più team con esigenze di cluster propri.
High-Performance VM richiedono qualche pezzo in più (PerformanceProfile, huge pages al boot, NUMA topology), ma replicano fedelmente il setup vSphere “Latency Sensitivity = High” + reservation. Da usare con giudizio.
Application-level HA (pacemaker, WSFC) funziona uguale: le tecnologie girano dentro le VM. Le accortezze sono lo storage condiviso (RWX o passthrough), l’anti-affinity, e il fencing tramite fence_kubevirt.

← Modulo 7 — Conclusione | Torna all’indice