Modulo 2 — Networking

⏱ Tempo di lettura: ~15 minuti 🎯 Obiettivo: tradurre il vocabolario di rete vSphere/NSX nel modello OpenShift (OVN-Kubernetes, Multus, NMState, NetworkAttachmentDefinition, Routes, NetworkPolicy).

Punto di partenza: il modello vSphere

In vSphere il networking è organizzato a livelli:

• vSwitch / Distributed vSwitch (DvSwitch): switch virtuali che vivono sull’host ESXi (vSwitch standard) o sono gestiti centralmente da vCenter (DvSwitch).
• Port group: la zona del DvSwitch a cui colleghi le NIC delle VM, di solito mappata a una VLAN.
• NSX-T: lo strato software-defined networking che aggiunge segmenti overlay, microsegmentazione (firewall distribuito), gateway, load balancer.
• vNIC della VM: tipicamente VMXNET3 (paravirtuale) o E1000 (legacy).

L’admin VMware pensa per port group + VLAN, e per “policy NSX” se serve isolamento applicativo.

Il modello OpenShift: SDN nativa + reti aggiuntive

OpenShift parte da una premessa diversa: c’è un Software Defined Network (SDN) integrato che dà a ogni pod (e a ogni VM, perché in OpenShift Virtualization una VM è di fatto un pod speciale) un IP, un nome DNS interno, e regole di firewall declarative.

Le componenti chiave sono:

        ┌─────────────────────────────────────────────────────────┐
        │                  Cluster OpenShift                      │
        │                                                         │
        │   ┌─────────────────────────────────────────────────┐   │
        │   │          OVN-Kubernetes (CNI default)           │   │
        │   │   - rete pod ↔ pod                              │   │
        │   │   - rete VM ↔ VM ↔ pod (peer nativi)            │   │
        │   │   - NetworkPolicy (= microsegmentation)         │   │
        │   │   - Egress firewall, IPAM, dual-stack IPv4/v6   │   │
        │   └─────────────────────────────────────────────────┘   │
        │                                                         │
        │   ┌─────────────────────────────────────────────────┐   │
        │   │   Multus + NetworkAttachmentDefinition          │   │
        │   │   (= reti secondarie, "port group aggiuntivi")  │   │
        │   └─────────────────────────────────────────────────┘   │
        │                                                         │
        │   ┌─────────────────────────────────────────────────┐   │
        │   │   NMState Operator                              │   │
        │   │   (= configurazione dell'hardware di rete       │   │
        │   │   sui nodi: bond, bridge, VLAN, MTU)            │   │
        │   └─────────────────────────────────────────────────┘   │
        │                                                         │
        │   ┌─────────────────────────────────────────────────┐   │
        │   │   Ingress / Routes / Services                   │   │
        │   │   (= "esposizione" delle applicazioni)          │   │
        │   └─────────────────────────────────────────────────┘   │
        └─────────────────────────────────────────────────────────┘

OVN-Kubernetes (spesso abbreviato OVN-K) è il CNI plugin di default: usa Open Virtual Network sotto il cofano e implementa overlay GENEVE fra i nodi. Pensa a OVN-K come “NSX-T + DvSwitch in un pacchetto unico, integrato e gestito da OpenShift”.

Multus è il moltiplicatore: permette di attaccare a una VM più reti, cosa essenziale se la tua VM ha bisogno (per dire) di una rete di gestione + una rete di backup + una rete dati. È il concetto-ponte verso il “ho 4 vNIC su 4 port group diversi” che già conosci.

NMState Operator è il pezzo che gestisce la configurazione di rete sui nodi: bond LACP, bridge Linux, VLAN tagged, MTU jumbo, route statiche. È l’equivalente di “vai su ESXi e configura il vmnic con vSwitch X, poi metti il port group con VLAN Y”.

Tabella di mapping delle feature di rete

Feature vSphere	Equivalente OpenShift Virtualization
vSwitch / DvSwitch (configurazione di rete sull’host)	NMState Operator (NodeNetworkConfigurationPolicy)
Port group (VLAN, isolamento di livello 2)	NetworkAttachmentDefinition (rete secondaria via Multus)
NSX-T overlay segments	UserDefinedNetwork (UDN) — rete overlay per namespace
NSX Distributed Firewall (microsegmentazione)	NetworkPolicy + ACL OVN-K
NSX Load Balancer	Routes (HTTP/S) + Services (L4) + MetalLB/cloud LB
Comunicazione VM ↔ VM su DvSwitch	Comunicazione VM ↔ VM ↔ pod nativa sulla SDN, senza dover passare da un ingress
Port mirroring + tool di traffic analysis NSX	Network Observability Operator (basato su eBPF/Flowlogs)
VMXNET3 come vNIC paravirtuale	virtio-net (paravirtuale, equivalente concettuale)
E1000 / E1000e per VM legacy	e1000e disponibile anche in OpenShift Virtualization

⚠️ La microsegmentazione non si fa più “fra VM e VM” come in NSX: si fa fra namespace o, dentro lo stesso namespace, fra pod/VM con label diverse. Concettualmente è uguale, ma il punto di applicazione è la NetworkPolicy (un oggetto Kubernetes), non una regola nel firewall distribuito.

Il menu Networking della web console

Nella OpenShift web console le voci principali per il networking sono raccolte sotto Networking:

Voce di menu	Cosa rappresenta	Equivalente / commento
NodeNetworkConfigurationPolicy	Definizione dichiarativa della rete sui nodi (bond, bridge, VLAN…)	È la “configurazione del DvSwitch” dell’host, ma in YAML
NodeNetworkState	Stato corrente della rete su ciascun nodo	Vista equivalente a “controllo cosa sta facendo l’host ESXi a livello rete”
NetworkAttachmentDefinition	Reti aggiuntive utilizzabili dalle VM (VLAN, bridge, SR-IOV)	Il port group sta qui
UserDefinedNetwork	Rete overlay primaria per un namespace	Equivalente di un segment NSX-T per un’applicazione isolata
Service	Endpoint L4 stabile per esporre un’applicazione dentro o fuori dal cluster	Concetto Kubernetes-native, non ha un parente diretto in vSphere
Routes / Ingresses	Esposizione di applicazioni HTTP/S verso l’esterno	Il “load balancer applicativo” — una mini-NSX LB integrata
NetworkPolicy	Regole di firewall L3/L4 fra pod/VM e namespace	È il firewall distribuito di NSX, in versione Kubernetes

Esempio pratico: VM con rete di management + rete dati

Caso reale: una VM Linux che deve avere due interfacce, una sulla VLAN 100 (management) e una sulla VLAN 200 (dati storage). In vSphere creeresti due port group e attaccheresti due vNIC.

In OpenShift il flusso è:

Step 1 — Configurare il bridge sui nodi (NMState):

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br-vlan100-200
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
  desiredState:
    interfaces:
      - name: br1
        type: linux-bridge
        state: up
        bridge:
          options:
            stp:
              enabled: false
          port:
            - name: ens3f1     # NIC fisica del nodo

Step 2 — Definire i port group come NetworkAttachmentDefinition:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: pg-mgmt-vlan100
  namespace: produzione-app
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "pg-mgmt-vlan100",
      "type": "bridge",
      "bridge": "br1",
      "vlan": 100,
      "ipam": {}
    }
---
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: pg-dati-vlan200
  namespace: produzione-app
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "pg-dati-vlan200",
      "type": "bridge",
      "bridge": "br1",
      "vlan": 200,
      "ipam": {}
    }

Step 3 — Attaccare le NIC della VM:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: app01
spec:
  template:
    spec:
      domain:
        devices:
          interfaces:
            - name: default            # rete cluster (pod network)
              masquerade: {}
            - name: nic-mgmt
              bridge: {}
            - name: nic-dati
              bridge: {}
      networks:
        - name: default
          pod: {}
        - name: nic-mgmt
          multus:
            networkName: pg-mgmt-vlan100
        - name: nic-dati
          multus:
            networkName: pg-dati-vlan200

Tre attacchi: la rete cluster di default (utile perché ti dà connettività al servizio DNS interno e ai service) e le due reti VLAN come “port group aggiuntivi”.

Esposizione delle applicazioni: Service, Route, MetalLB

Qui la differenza concettuale rispetto a vSphere è grande: in vSphere “esponi una VM” significa quasi sempre “metti la sua IP su una VLAN routata e configura il firewall a monte”. In OpenShift c’è un’astrazione in più:

• Service (Kubernetes): IP virtuale stabile interno al cluster, con load balancing fra repliche. Tre tipi principali:

  • ClusterIP — accesso solo dall’interno del cluster
  • NodePort — accessibile sul <IP nodo>:<porta>
  • LoadBalancer — espone via load balancer esterno (in cloud è automatico, on-prem serve MetalLB o un LB hardware)

• Route (OpenShift-specific): esposizione HTTP/HTTPS con hostname dedicato (es. app01.apps.miocluster.example.com), terminazione TLS, ridistribuzione del traffico. È il pezzo più simile a un virtual server NSX LB lato applicativo.

• MetalLB: un load balancer L2/BGP che gira dentro il cluster, utile on-prem dove non c’è un LB cloud. Ti permette di assegnare un IP “esterno” ai service di tipo LoadBalancer.

💡 Per VM “tradizionali” che si vogliono comportare come server fisici (es. un database accessibile via IP statico in VLAN dati), l’approccio più vicino al modo VMware è NIC su NetworkAttachmentDefinition in modalità bridge → IP statico interno alla VM via cloud-init o configurato a mano. Niente Service/Route necessari.

NetworkPolicy: la microsegmentazione

Esempio pratico: “tutte le VM nel namespace produzione-app possono parlare con il database (label tier=db) solo sulla porta 5432”.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: solo-app-verso-db
  namespace: produzione-app
spec:
  podSelector:
    matchLabels:
      tier: db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              tier: app
      ports:
        - protocol: TCP
          port: 5432

Questa è la regola di firewall distribuito di NSX-T, riscritta in YAML. Funziona per pod e per VM allo stesso modo (le VM in OpenShift Virtualization hanno label come i pod).

User Defined Networks (UDN): il “segmento NSX overlay”

Una novità più recente è UserDefinedNetwork: permette di creare reti overlay dedicate per un namespace, con isolamento di default (i pod nel namespace possono parlare solo fra loro, non con altri namespace), senza dover scrivere NetworkPolicy esplicite.

È molto vicino al concetto di segment overlay NSX-T dedicato a un’applicazione: comodo per dare a ogni team il proprio “ambiente di rete” senza interferenze.

Differenze chiave da tenere a mente

1. VM e pod sono peer di rete nativi. Una VM può parlare con un pod (e viceversa) senza dover passare da un ingress, una NodePort o un proxy. È diverso dal mondo vSphere dove “VM” e “container” vivono in piani logicamente separati.
2. Il firewall è declarativo. Niente console NSX: scrivi NetworkPolicy in YAML, le applichi in Git, le metti in CI/CD. Tracciabilità completa.
3. L’IPAM è gestito. Il CNI assegna automaticamente gli IP. Per le reti secondarie via Multus puoi però usare DHCP, IPAM statico, o whereabouts.
4. Niente “vCenter unico”. OpenShift su più siti = più cluster. La continuità di rete fra siti si gestisce con Submariner, ACM, o reti underlay tradizionali — non c’è una “Cross-vCenter NSX” da configurare.
5. MTU e jumbo frame richiedono attenzione doppia: vanno coordinati fra l’underlay fisico (NIC, switch), l’overlay GENEVE di OVN-K (overhead ~50 byte) e l’MTU della NIC della VM. È una delle cause più comuni di “la VM non riesce a passare pacchetti grandi”.

Best practice operative

• Definisci un piano di NMState policy chiaro fin dall’inizio: bond + bridge sui worker, con MTU coerente con la rete fisica. Cambiare bridge name dopo che hai 200 VM è doloroso.
• Documenta le NetworkAttachmentDefinition come documenteresti i port group: una per VLAN, naming consistente (pg-<scopo>-vlan<id>).
• NetworkPolicy in deny-by-default per i namespace di produzione: poi aggiungi solo le regole Allow strettamente necessarie. È l’equivalente del “firewall a default deny” che già fai con NSX.
• Usa MetalLB on-prem per dare un’esperienza “Service tipo LoadBalancer” simile al cloud, evita NodePort in produzione.
• Network Observability Operator acceso fin dall’inizio: è il tuo equivalente di “port mirroring + flow analysis” e ti salva nei troubleshooting di traffico VM↔VM.

Approfondimenti ufficiali

• About OpenShift networking
• OVN-Kubernetes network plugin
• k8s NMState Operator
• Multiple networks (Multus + UDN)
• Network Observability Operator
• MetalLB

---

← Modulo 1 — Storage | Avanti → Modulo 3 — Compute