Pianificare la rete del cluster per Azure Red Hat OpenShift con piani di controllo ospitati (anteprima)

Azure Red Hat OpenShift con piani di controllo ospitati distribuisce i nodi di lavoro nella rete virtuale Azure e usa una subnet dedicata per stabilire la connettività privata tra il piano di controllo ospitato e i nodi di lavoro. È necessario pianificare il layout della rete virtuale, le subnet e gli intervalli di indirizzi IP prima di creare il cluster.

Pianificare la capacità di calcolo

I pool di nodi forniscono capacità di calcolo. Un pool di nodi è un gruppo di nodi di lavoro che condividono le stesse dimensioni della macchina virtuale, la configurazione del disco e la zona di disponibilità. È possibile creare più pool di nodi in un singolo cluster per eseguire tipi di carico di lavoro diversi in hardware diverso. Per le dimensioni supportate delle macchine virtuali del nodo di lavoro, vedere Dimensioni delle macchine virtuali supportate. Diverse decisioni relative al pool di nodi influiscono direttamente sul layout di rete, quindi è necessario pianificare la capacità di calcolo prima di ridimensionare la rete.

Rispondere alle domande seguenti consente di pianificare le subnet e gli intervalli di indirizzi IP per il cluster:

• Quanti pool di nodi gestirai? Il numero di pool di nodi determina il numero di subnet necessarie. Se tutti i pool condividono la subnet di lavoro predefinita del cluster, è sufficiente una subnet. Se si assegnano subnet separate a pool diversi, ognuna aggiunge ai requisiti CIDR della rete virtuale e della macchina.
• Distribuirai tra le zone di disponibilità? Ogni pool di nodi viene distribuito in una singola zona di disponibilità. Per distribuire i carichi di lavoro tra zone per la disponibilità elevata, è necessario un pool di nodi separato e potenzialmente una subnet separata per ogni zona. Più zone significano più subnet e un CIDR di macchine più grandi.
• Ogni pool di nodi userà la propria subnet? I pool di nodi vengono distribuiti nella subnet di lavoro predefinita del cluster, a meno che non si specifichi una subnet diversa. Le subnet separate offrono l'isolamento di rete tra i pool di nodi, ma ogni subnet deve rientrare nell'intervallo CIDR del computer e nello spazio indirizzi della rete virtuale.
• Quanti nodi eseguirai al momento di picco? Il numero massimo di nodi, inclusi i valori massimi di scalabilità automatica, determina la dimensione di ogni subnet. Il cluster supporta un massimo di 500 nodi totali in tutti i pool.
• Verranno aggiunti altri pool di nodi in un secondo momento? Gli intervalli CIDR del cluster non possono essere modificati dopo la creazione. Se si prevede di aggiungere pool di nodi con nuove subnet in futuro, il CIDR e la rete virtuale del computer devono disporre di spazio indirizzi sufficiente per supportarli.

Suggerimento

Esempio di ridimensionamento: Un cluster con 3 zone di disponibilità, fino a 50 nodi per zona e una subnet separata per zona richiede tre /26 subnet (64 indirizzi ciascuno, che ospitano 50 nodi più Azure indirizzi riservati) e una /29 subnet di integrazione rete virtuale. Tutte e quattro le subnet rientrano in un CIDR di macchina /24 (256 indirizzi). Se si prevede di aggiungere più pool di nodi in un secondo momento, usare un CIDR di computer di dimensioni maggiori, /22 ad esempio o /16 per lasciare spazio per altre subnet.

Requisiti della subnet

La rete virtuale deve contenere i componenti seguenti:

• Subnet del ruolo di lavoro : subnet predefinita in cui vengono distribuiti i nodi di lavoro del cluster. Quando si crea un pool di nodi, viene distribuito in questa subnet, a meno che non si specifichi una subnet diversa. Se si prevede di distribuire pool di nodi in più zone di disponibilità, è possibile creare una subnet separata per ogni zona. Tutte le subnet del pool di nodi devono trovarsi nella stessa rete virtuale del cluster. Dimensiona ogni subnet in base al numero di nodi worker che prevedi di eseguire al suo interno.
• Subnet di integrazione della rete virtuale - Una subnet dedicata che consente la connettività privata tra il piano di controllo ospitato (in esecuzione nell'account Azure di Red Hat) e i nodi di lavoro nella tua sottoscrizione. Deve soddisfare i requisiti seguenti:
  • Dimensioni minime di /29
  • Situato nella stessa rete virtuale della subnet di lavoro
  • Non condiviso con la subnet dei nodi worker o con alcuna subnet del pool di nodi
• Gruppo di sicurezza di rete - Gruppo di sicurezza di rete di Azure che si crea e si associa alla subnet dei nodi di lavoro. Assegnare il gruppo di sicurezza di rete direttamente alle subnet ed è non modificabile. Non si dispone delle autorizzazioni per modificarle.

Requisiti CIDR

La tabella seguente descrive i requisiti di rete virtuale e CIDR:

Requisito di rete	Predefinito	Description
Intervallo CIDR della macchina	10.0.0.0/16	Intervallo di indirizzi IP per i nodi di calcolo. Deve includere tutti gli intervalli di indirizzi CIDR per le subnet della rete virtuale, incluse le subnet che si prevede di usare per pool di nodi aggiuntivi. Le subnet devono essere contigue. Per le distribuzioni in una singola zona di disponibilità sono supportati almeno 128 indirizzi (/25). È supportato un minimo di 256 indirizzi (/24) per distribuzioni in più zone di disponibilità.
Intervallo CIDR del servizio	172.30.0.0/16	Intervallo di indirizzi IP per gli IP di servizio di Kubernetes. L'intervallo deve essere sufficientemente grande per supportare il carico di lavoro e non deve sovrapporsi ad alcun servizio esterno a cui si accede dall'interno del cluster.
Intervallo CIDR dei Pod	10.128.0.0/14	Intervallo di indirizzi IP per i pod. L'intervallo deve essere sufficientemente grande per supportare il carico di lavoro e non deve sovrapporsi ad alcun servizio esterno a cui si accede dall'interno del cluster.
Prefisso dell'host	23	Lunghezza del prefisso della subnet assegnata a ciascun nodo per i propri pod. Un valore di 23 assegna una /23 subnet (512 indirizzi IP) per nodo dall'intervallo CIDR del pod.

Usare i valori predefiniti a meno che non soddisfino i requisiti. Se è necessario modificare uno di questi valori, seguire queste linee guida:

• I CIDR dei pod, dei servizi e delle macchine non devono sovrapporsi tra loro.
• I CIDR del pod e del servizio non devono sovrapporsi ad alcun intervallo di indirizzi in uso nella rete o a qualsiasi servizio esterno a cui si accede dall'interno del cluster.
• Il CIDR della macchina deve comprendere tutte le subnet della rete virtuale utilizzate dal cluster, inclusa la subnet dei nodi di lavoro, tutte le subnet aggiuntive dei pool di nodi e la subnet di integrazione con la rete virtuale. Se si prevede di aggiungere pool di nodi con subnet separate in futuro, assicurarsi che il CIDR del computer sia sufficientemente grande da includerli. Ad esempio, se la VNet usa 10.0.0.0/16, il CIDR predefinito della macchina 10.0.0.0/16 comprende tutte le subnet.
• La rete dei pod utilizza indirizzi IP non instradabili ed è usata solo all'interno della rete definita dal software del cluster.

Connettività del cluster privato

Se si sceglie un server API privato, un ingresso predefinito privato o entrambi, è necessario stabilire la connettività di rete privata tra le reti degli utenti e la rete virtuale del cluster prima di distribuire il cluster. Senza questa connettività, gli amministratori, le pipeline CI/CD e gli utenti finali non possono raggiungere gli endpoint privati.

Le opzioni di connettività comuni includono:

• Peering VNet di Azure - Connettere due reti virtuali di Azure in modo che le risorse in ciascuna rete possano comunicare tra loro.
• Gateway VPN di Azure: connettere la rete locale alla rete virtuale del cluster tramite un tunnel VPN da sito a sito.
• Azure ExpressRoute: stabilire una connessione privata e dedicata dalla rete locale per Azure tramite un provider di connettività.

Quando si pianifica la connettività di rete privata, assicurarsi che gli intervalli di indirizzi IP delle reti in peering o connesse non si sovrappongano agli intervalli CIDR delle macchine, dei pod o dei servizi del cluster.

Passaggi successivi

Creare un cluster