Network Requirements — OCP 4.18 on vSphere IPI

Riferimento operativo per il team Networking / Security prima dell’installazione IPI di OpenShift Container Platform 4.18 su VMware vSphere.

Copre: aperture firewall (BH → vCenter/VIP, nodi cluster → vCenter/ESXi, node ↔ node, control plane), DNS record obbligatori, VIP, esempi con VLAN reali e comandi di verifica.

Fonti: Red Hat OpenShift Container Platform 4.18 – Installing on VMware vSphere, sezioni Installer-provisioned infrastructure → Network connectivity requirements e Required DNS records. Link: https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/installing_on_vmware_vsphere/index

⚠ Apertura spesso dimenticata: tutti i nodi del cluster (non solo il bastion) devono raggiungere vCenter e ogni ESXi su TCP 443. Serve per Cloud Controller Manager, Machine API, vSphere CSI Driver, e cloud-provider integration. Se questa regola manca, l’installazione arriva a bootstrap ma non completa i cluster operator. Vedi §1.1 e §8.

Diagramma d’insieme

1. Aperture firewall

1.1 Bastion Host + nodi cluster → management (vCenter / ESXi)

Il Bastion Host lancia openshift-install, ma anche i control-plane e compute nodes devono raggiungere vCenter e ogni ESXi su TCP 443 — non solo durante l’installazione ma per sempre (day-2).

Source → Destination	Protocol	Port	Description
Bastion Host → vCenter	TCP	443	vCenter API (installer-provisioned)
Bastion Host → ESXi hosts	TCP	443	ESXi host API (deploy OVF RHCOS)
⚠ Control-plane nodes → vCenter	TCP	443	CCM, Machine API, cluster-cloud-controller-manager, vSphere CSI Driver Operator
⚠ Control-plane nodes → ESXi hosts	TCP	443	vSphere CSI Driver: attach/detach volumi PV
⚠ Compute nodes → vCenter	TCP	443	Kubelet cloud-provider integration
⚠ Compute nodes → ESXi hosts	TCP	443	CSI node driver: block-level operations sui PV

Perché: OpenShift su vSphere gira in modalità cloud-integrated. Il cluster-cloud-controller-manager sui master chiama vCenter per attribuire providerID, topology.kubernetes.io/zone e topology.kubernetes.io/region ai nodi. Il vSphere CSI Driver crea VMDK come PV e chiama ESXi per attach/detach. Il machine-api-operator chiama vCenter quando i MachineSet scalano. Se manca TCP 443 dai nodi verso vCenter/ESXi, l’installazione arriva al bootstrap ma non completa i cluster operator.

1.2 Bastion Host → VIP cluster

Source → Destination	Protocol	Port	Description
Bastion Host → API VIP	TCP	6443	Kubernetes API
Bastion Host → API VIP	TCP	22623	Machine Config Server (Ignition)
Bastion Host → Ingress VIP	TCP	80, 443	Console OpenShift + applicazioni

1.3 All-machine ↔ All-machine

Traffico interno al cluster fra tutti i nodi (control-plane + compute).

Protocol	Port	Description
ICMP	N/A	Reachability tests
TCP	1936	Metrics della router pod (accessibili solo internamente)
TCP	9000-9999	Host-level services (node-exporter su 9100-9101)
TCP	10250-10259	Kubernetes reserved (kubelet, kube-scheduler, kube-controller-manager)
UDP	4789	VXLAN (solo se OpenShift SDN, legacy — non default su 4.18)
UDP	6081	Geneve (OVN-Kubernetes, default su 4.18)
UDP	500	IPsec IKE (se OVN IPsec è abilitato)
UDP	4500	IPsec NAT-T (se OVN IPsec è abilitato)
ESP	N/A	IPsec Encapsulating Security Payload
UDP	9000-9999	Host-level services
TCP/UDP	30000-32767	NodePort services

1.4 All-machine → Control plane

Protocol	Port	Description
TCP	6443	Kubernetes API server

1.5 Control plane ↔ Control plane

Protocol	Port	Description
TCP	2379-2380	etcd server + peer

2. VIP requirements

L’installer IPI di vSphere richiede due IP virtuali che devono essere raggiungibili sulla stessa rete dei nodi ma non in gestione DHCP (statici, fuori dallo scope, o riservati permanentemente).

VIP	Uso	Endpoint DNS	Chi lo gestisce
API VIP	Kubernetes API + MCS Ignition (porte 6443, 22623)	`api.<cluster>.<domain>` + `api-int.<cluster>.<domain>`	Keepalived interno al cluster
Ingress VIP	Application ingress (porte 80, 443)	`*.apps.<cluster>.<domain>`	Keepalived interno al cluster (nodi con router pod)

Nota 4.18 — l’installer IPI supporta anche un load balancer esterno (user-managed, es. F5 / NSX-T / HAProxy dedicato). In quel caso i VIP e Keepalived interni non vengono creati e i bilanciatori esterni devono esporre 6443, 22623, 80, 443 verso l’esterno / verso il cluster.

3. DNS record obbligatori

Anche in modalità IPI, il DNS non è auto-provisionato: va configurato sul DNS aziendale prima di lanciare openshift-install create cluster.

Record	Type	Target	Chi lo risolve
`api.<cluster>.<domain>`	A	API VIP	Esterni + nodi cluster
`api-int.<cluster>.<domain>`	A	API VIP	Solo nodi cluster
`*.apps.<cluster>.<domain>`	A (wildcard)	Ingress VIP	Esterni + nodi cluster

Esempio BIND zone (dominio lab.example.com, cluster ocp4):

$ORIGIN example.com.
$TTL 1D
@       IN  SOA dns.example.com. root.example.com. ( 2025010101 3h 15 1w 3h )
        IN  NS  dns.example.com.

; VIP records
api.ocp4        IN A 10.42.10.10
api-int.ocp4    IN A 10.42.10.10
*.apps.ocp4     IN A 10.42.10.11

Reverse zone:

$ORIGIN 10.42.10.in-addr.arpa.
10  IN PTR api.ocp4.example.com.
10  IN PTR api-int.ocp4.example.com.
11  IN PTR apps.ocp4.example.com.

4. Esempi realistici — VLAN, subnet, IP fittizi

Assunzioni per gli esempi seguenti (rappresentative di un tipico deploy bancario/enterprise):

Item	Valore
Dominio DNS	`lab.example.com`
Nome cluster	`ocp4`
VLAN cluster (nodi + VIP)	VLAN 210 — `10.42.10.0/24`
VLAN management (bastion, vCenter, DNS)	VLAN 200 — `10.42.0.0/24`
VLAN utenti/consumer del cluster	VLAN 100 — `10.42.100.0/24`
Bastion Host	`bastion.lab.example.com` — `10.42.0.20`
vCenter	`vcenter.lab.example.com` — `10.42.0.30`
ESXi hosts	`esxi-01/02/03.lab.example.com` — `10.42.0.31-33`
DNS servers	`10.42.0.10`, `10.42.0.11`
NTP server	`10.42.0.12`
DHCP scope (nodi)	`10.42.10.100 – 10.42.10.199`
API VIP	`10.42.10.10` (fuori scope DHCP)
Ingress VIP	`10.42.10.11` (fuori scope DHCP)

4.1 Diagramma testuale (chi parla con chi)

   VLAN 100 (Users)           VLAN 200 (Management)         VLAN 210 (Cluster)
   10.42.100.0/24             10.42.0.0/24                  10.42.10.0/24
   ────────────────           ────────────────              ────────────────
   users / laptop     ──▶     bastion 10.42.0.20     ──▶    API VIP 10.42.10.10
                              vcenter 10.42.0.30    ◀──▶       (LB → masters)
                              esxi-01/02/03         ◀──▶    Ingress VIP 10.42.10.11
   (browser → *.apps) ─────────────────────────────────▶       (LB → routers)
                              DNS 10.42.0.10/11
                              NTP 10.42.0.12                master01 10.42.10.101 (DHCP-res)
                                                            master02 10.42.10.102 (DHCP-res)
                                                            master03 10.42.10.103 (DHCP-res)
                                                            worker01 10.42.10.111 (DHCP-res)
                                                            worker02 10.42.10.112 (DHCP-res)
                                                            worker03 10.42.10.113 (DHCP-res)

Le doppie frecce ◀──▶ tra vCenter/ESXi e cluster indicano che entrambe le direzioni servono: bastion + master + worker → vCenter/ESXi:443.

4.2 Regole firewall per zona (`source → destination`)

Formato: source → destination : protocol/port. Se il firewall è policy-based (Palo Alto, Fortinet, Check Point), aggrega per zona come sotto.

4.2.1 Management → Cluster

# Bastion (10.42.0.20) → cluster VIP e nodi
allow 10.42.0.20/32 → 10.42.10.10/32 tcp/6443     # Kubernetes API
allow 10.42.0.20/32 → 10.42.10.10/32 tcp/22623    # MCS Ignition
allow 10.42.0.20/32 → 10.42.10.11/32 tcp/80,443   # Console + apps
allow 10.42.0.20/32 → 10.42.10.0/24  tcp/22       # SSH ai nodi (troubleshooting)
allow 10.42.0.20/32 → 10.42.10.0/24  icmp         # ping / mtr

4.2.2 Cluster → Management ⚠ apertura critica

Questa è l’apertura che viene dimenticata più spesso. I nodi cluster devono raggiungere vCenter e ogni ESXi su 443, non solo il bastion. Senza, il cluster non completa gli operator.

# Cluster (10.42.10.0/24) → vCenter/ESXi/DNS/NTP
allow 10.42.10.0/24 → 10.42.0.30/32  tcp/443      # ⚠ vCenter API — OBBLIGATORIA per CCM/CSI/Machine API
allow 10.42.10.0/24 → 10.42.0.31/32  tcp/443      # ⚠ ESXi-01 — OBBLIGATORIA per CSI volumi
allow 10.42.10.0/24 → 10.42.0.32/32  tcp/443      # ⚠ ESXi-02 — idem
allow 10.42.10.0/24 → 10.42.0.33/32  tcp/443      # ⚠ ESXi-03 — idem
allow 10.42.10.0/24 → 10.42.0.10/32  udp/53       # DNS primary
allow 10.42.10.0/24 → 10.42.0.11/32  udp/53       # DNS secondary
allow 10.42.10.0/24 → 10.42.0.12/32  udp/123      # NTP

Se aggiungi ESXi nel tempo (scaling del cluster vSphere), aggiungi anche le loro regole. Un pattern più elegante è aprire l’intera subnet management:

allow 10.42.10.0/24 → 10.42.0.30-33 tcp/443        # tutti gli host mgmt vSphere
# oppure per subnet intera se vCenter/ESXi vivono in uno stesso range dedicato

4.2.3 Users → Cluster (accesso da rete utente)

# Utenti che aprono la console OCP o app pubblicate via router
allow 10.42.100.0/24 → 10.42.10.11/32 tcp/80,443  # Ingress VIP
allow 10.42.100.0/24 → 10.42.10.10/32 tcp/6443    # kubectl/oc dagli sviluppatori (facoltativo)

4.2.4 Cluster → Cluster (intra-VLAN)

Idealmente il firewall non filtra all’interno della VLAN 210 (single L2). Se invece è micro-segmentata (NSX-T, Palo Alto East-West):

# Control plane ↔ Control plane
allow 10.42.10.101-103 ↔ 10.42.10.101-103 tcp/2379,2380

# All ↔ All (data plane OVN-K)
allow 10.42.10.0/24 ↔ 10.42.10.0/24 udp/6081       # Geneve (obbligatorio)
allow 10.42.10.0/24 ↔ 10.42.10.0/24 tcp/10250-10259  # Kubelet, KCM, KS
allow 10.42.10.0/24 ↔ 10.42.10.0/24 udp/500,4500     # IPsec IKE + NAT-T (se OVN-IPsec on)
allow 10.42.10.0/24 ↔ 10.42.10.0/24 esp              # IPsec ESP (se OVN-IPsec on)
allow 10.42.10.0/24 ↔ 10.42.10.0/24 tcp/9000-9999    # node-exporter + host services
allow 10.42.10.0/24 ↔ 10.42.10.0/24 udp/9000-9999    # host services
allow 10.42.10.0/24 ↔ 10.42.10.0/24 tcp/30000-32767  # NodePort TCP
allow 10.42.10.0/24 ↔ 10.42.10.0/24 udp/30000-32767  # NodePort UDP
allow 10.42.10.0/24 ↔ 10.42.10.0/24 icmp             # Reachability

4.2.5 Cluster → Internet (o mirror registry)

Solo se il cluster ha internet diretto (unlikely in banking). Altrimenti sostituisci con il tuo mirror-registry interno:

allow 10.42.10.0/24 → 0.0.0.0/0 tcp/443           # Red Hat registries, Quay.io
allow 10.42.10.0/24 → 0.0.0.0/0 tcp/80            # raro

4.3 Esempi iptables/nftables per micro-segmentazione host

Esempi su un master (10.42.10.101) che deve accettare traffico peer etcd e kubelet:

# etcd peer (solo dai due altri master)
iptables -A INPUT -s 10.42.10.102,10.42.10.103 -p tcp --dport 2379:2380 -j ACCEPT

# Geneve overlay (da tutti i nodi cluster)
iptables -A INPUT -s 10.42.10.0/24 -p udp --dport 6081 -j ACCEPT

# Kubelet (dal control-plane e dai peer)
iptables -A INPUT -s 10.42.10.0/24 -p tcp --dport 10250:10259 -j ACCEPT

# Bloccare tutto il resto sulle stesse porte
iptables -A INPUT -p tcp --dport 2379:2380 -j DROP

Su RHCOS non modificare iptables a mano: usa un MachineConfig con NetworkManager dispatcher script o meglio ancora NetworkPolicy a livello di cluster.

4.4 Esempio Palo Alto (policy-based)

# Nome regola          Src Zone   Src IP           Dst Zone   Dst IP           Service                Action
"BH-to-API"            Mgmt       10.42.0.20/32    Cluster    10.42.10.10/32   tcp-6443, tcp-22623    allow
"BH-to-Ingress"        Mgmt       10.42.0.20/32    Cluster    10.42.10.11/32   tcp-80, tcp-443        allow
"BH-to-vCenter"        Mgmt       10.42.0.20/32    Mgmt       10.42.0.30/32    tcp-443                allow
"Cluster-to-vCenter"   Cluster    10.42.10.0/24    Mgmt       10.42.0.30/32    tcp-443                allow  # ⚠ CCM/CSI
"Cluster-to-ESXi"      Cluster    10.42.10.0/24    Mgmt       10.42.0.31-33    tcp-443                allow  # ⚠ CSI volumi
"Cluster-to-DNS"       Cluster    10.42.10.0/24    Mgmt       10.42.0.10-11    udp-53                 allow
"Cluster-to-NTP"       Cluster    10.42.10.0/24    Mgmt       10.42.0.12/32    udp-123                allow
"Users-to-Apps"        Users      10.42.100.0/24   Cluster    10.42.10.11/32   tcp-80, tcp-443        allow
"Cluster-Internal-*"   Cluster    10.42.10.0/24    Cluster    10.42.10.0/24    any                    allow
"Default-Deny"         any        any              any        any              any                    deny

5. DHCP

Obbligatorio DHCP sulla VLAN dove verranno creati i nodi RHCOS (VLAN 210 nell’esempio).
DHCP reservation per MAC address dei master (e possibilmente dei worker), così ricevono sempre lo stesso IP.
VIP fuori dallo scope DHCP (es. VIP 10.42.10.10-11 mentre scope DHCP è 10.42.10.100-199).
Ogni VM cluster deve ricevere via DHCP: IP, netmask, gateway, DNS server, NTP.

Esempio dnsmasq (in lab):

dhcp-range=10.42.10.100,10.42.10.199,255.255.255.0,12h
dhcp-option=option:router,10.42.10.1
dhcp-option=option:dns-server,10.42.0.10,10.42.0.11
dhcp-option=option:ntp-server,10.42.0.12
dhcp-option=option:domain-name,lab.example.com

# Reservation master
dhcp-host=00:50:56:aa:00:01,10.42.10.101,master01
dhcp-host=00:50:56:aa:00:02,10.42.10.102,master02
dhcp-host=00:50:56:aa:00:03,10.42.10.103,master03
# Reservation worker
dhcp-host=00:50:56:aa:00:11,10.42.10.111,worker01
dhcp-host=00:50:56:aa:00:12,10.42.10.112,worker02
dhcp-host=00:50:56:aa:00:13,10.42.10.113,worker03

6. NTP

Tutti i nodi RHCOS e il bootstrap devono avere accesso a NTP (default chronyd) verso un server sincronizzato. Deriva anche dai requisiti Kubernetes/etcd (skew massimo consigliato: 500 ms).

Verifica dal bastion:

chronyc tracking
chronyc sources -v

7. Verifiche di connettività

7.1 Dal Bastion

# vCenter e ESXi raggiungibili
nc -zv vcenter.lab.example.com 443
nc -zv esxi-01.lab.example.com 443
nc -zv esxi-02.lab.example.com 443
nc -zv esxi-03.lab.example.com 443

# API VIP (deve rispondere DOPO l'installazione; prima no, ma il DNS deve risolvere)
dig +short api.ocp4.lab.example.com
dig +short api-int.ocp4.lab.example.com

# Ingress wildcard
dig +short console-openshift-console.apps.ocp4.lab.example.com

# PTR reverse
dig +short -x 10.42.10.10

# Post-install: API server risponde
curl -k https://api.ocp4.lab.example.com:6443/version

# DNS + NTP + gateway raggiungibili
nc -zv 10.42.0.10 53
nc -uzv 10.42.0.12 123
ping -c 3 10.42.10.1

7.2 Dai nodi cluster (post-install, tramite `oc debug node`) ⚠

Questa verifica è fondamentale per confermare che l’apertura §1.1 nodi → vCenter/ESXi funziona:

# Da un master, verifica che vCenter e ogni ESXi rispondano su 443
oc debug node/master01
# dentro il debug pod:
chroot /host
curl -kv https://vcenter.lab.example.com/sdk 2>&1 | grep -E "Connected|SSL"
curl -kv https://esxi-01.lab.example.com/sdk 2>&1 | grep -E "Connected|SSL"
curl -kv https://esxi-02.lab.example.com/sdk 2>&1 | grep -E "Connected|SSL"
curl -kv https://esxi-03.lab.example.com/sdk 2>&1 | grep -E "Connected|SSL"

Se qualsiasi di questi restituisce timeout o connection refused, la regola firewall §1.1 non è applicata correttamente. Vedi §8.

8. Errori comuni & troubleshooting rapido

x509: certificate signed by unknown authority durante l’installazione Il CA di vCenter non è nel trust del bastion. Scaricalo:

curl -k -o /tmp/vcenter.zip https://vcenter.lab.example.com/certs/download.zip
unzip /tmp/vcenter.zip -d /tmp/vc
sudo cp /tmp/vc/certs/lin/*.0 /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Bootstrap fallisce con timeout waiting for the Kubernetes API 99% delle volte il DNS API VIP non è risolvibile dai master, o l’API VIP è nella scope DHCP e viene “rubato”. Verifica risoluzione da un master di test o direttamente dal bastion.

⚠ Bootstrap OK ma cluster operator non completano (AVAILABLE=False, DEGRADED=True) Questo è il sintomo classico di apertura nodi → vCenter/ESXi mancante (§1.1). L’installer arriva a bootstrap perché usa la connettività del bastion, ma poi il CCM sui master e il CSI operator non riescono a chiamare vCenter e restano in stallo. Diagnosi:

oc get co
oc get co --no-headers | awk '$3!="True" || $4!="False" || $5!="False"'

# I sospetti tipici
oc logs -n openshift-cloud-controller-manager -l app=vsphere-cloud-controller-manager --tail=50
oc logs -n openshift-cluster-storage-operator -l name=vsphere-csi-driver-operator --tail=50
oc logs -n openshift-machine-api -l k8s-app=controller --tail=50

# Cercare messaggi tipo:
# - "dial tcp <vcenter_ip>:443: connect: connection timed out"
# - "dial tcp <esxi_ip>:443: i/o timeout"
# - "unable to reach vCenter"

Se trovi questi errori, la regola firewall §1.1 non è applicata. Apri il ticket al Network e cita esplicitamente:

“Serve aprire TCP 443 da tutti i nodi cluster (subnet X) verso vCenter (IP) e verso ogni ESXi (IPs). Non solo dal bastion. Riferimento: Red Hat OCP 4.18 docs — Installer-provisioned infrastructure → Network connectivity requirements.”

Ingress non risponde ma API sì Il wildcard DNS *.apps non è configurato, oppure l’Ingress VIP non è raggiungibile dall’esterno. Test:

curl -kv https://console-openshift-console.apps.ocp4.lab.example.com

Se curl risolve ma il timeout è sulla connect, il problema è firewall sulla porta 443 verso l’Ingress VIP.

Pod openshift-etcd/etcd-* non partono, log dicono connection refused fra i member Firewall interno blocca TCP 2379-2380 fra i master. Frequente in ambienti con security zones per master vs. compute.

PV non si attaccano ai pod (Pending forever), evento AttachVolume.Attach failed CSI driver sui compute non raggiunge ESXi:443. Verifica dai worker con oc debug node/workerXX + curl -kv https://<esxi>/sdk.

Network Requirements — OCP 4.18 on vSphere IPI

Network Requirements — OCP 4.18 on vSphere IPI

Diagramma d’insieme

1. Aperture firewall

1.1 Bastion Host + nodi cluster → management (vCenter / ESXi)

1.2 Bastion Host → VIP cluster

1.3 All-machine ↔ All-machine

1.4 All-machine → Control plane

1.5 Control plane ↔ Control plane

2. VIP requirements

3. DNS record obbligatori

4. Esempi realistici — VLAN, subnet, IP fittizi

4.1 Diagramma testuale (chi parla con chi)

4.2 Regole firewall per zona (`source → destination`)

4.2.1 Management → Cluster

4.2.2 Cluster → Management ⚠ apertura critica

4.2.3 Users → Cluster (accesso da rete utente)

4.2.4 Cluster → Cluster (intra-VLAN)

4.2.5 Cluster → Internet (o mirror registry)

4.3 Esempi iptables/nftables per micro-segmentazione host

4.4 Esempio Palo Alto (policy-based)

5. DHCP

6. NTP

7. Verifiche di connettività

7.1 Dal Bastion

7.2 Dai nodi cluster (post-install, tramite `oc debug node`) ⚠

8. Errori comuni & troubleshooting rapido

9. Checklist finale (pre-install)

Riferimenti Red Hat

Network Requirements — OCP 4.18 on vSphere IPI

Network Requirements — OCP 4.18 on vSphere IPI

Diagramma d’insieme

1. Aperture firewall

1.1 Bastion Host + nodi cluster → management (vCenter / ESXi)

1.2 Bastion Host → VIP cluster

1.3 All-machine ↔ All-machine

1.4 All-machine → Control plane

1.5 Control plane ↔ Control plane

2. VIP requirements

3. DNS record obbligatori

4. Esempi realistici — VLAN, subnet, IP fittizi

4.1 Diagramma testuale (chi parla con chi)

4.2 Regole firewall per zona (source → destination)

4.2.1 Management → Cluster

4.2.2 Cluster → Management ⚠ apertura critica

4.2.3 Users → Cluster (accesso da rete utente)

4.2.4 Cluster → Cluster (intra-VLAN)

4.2.5 Cluster → Internet (o mirror registry)

4.3 Esempi iptables/nftables per micro-segmentazione host

4.4 Esempio Palo Alto (policy-based)

5. DHCP

6. NTP

7. Verifiche di connettività

7.1 Dal Bastion

7.2 Dai nodi cluster (post-install, tramite oc debug node) ⚠

8. Errori comuni & troubleshooting rapido

9. Checklist finale (pre-install)

Riferimenti Red Hat

4.2 Regole firewall per zona (`source → destination`)

7.2 Dai nodi cluster (post-install, tramite `oc debug node`) ⚠