Considerazioni sulla topologia di rete e sulla connettività per Azure Red Hat OpenShift

Articolo
07/11/2023

Esaminare le considerazioni sulla progettazione e le raccomandazioni per la topologia di rete e la connettività quando si usa l'acceleratore di zona di destinazione di Azure Red Hat OpenShift.

Considerazioni relative alla progettazione

Azure Red Hat OpenShift richiede una subnet primaria e una subnet secondaria.
- Usare la subnet primaria per distribuire i nodi master del cluster.
- Usare la subnet secondaria per distribuire i nodi di lavoro del cluster.
- La subnet secondaria e la subnet primaria devono essere entrambe una route minima /27 .
- Non è possibile modificare la subnet secondaria o la subnet primaria dopo la distribuzione del cluster.
- La subnet primaria e la subnet secondaria non possono avere un gruppo di sicurezza di rete associato. Il cluster Azure Red Hat OpenShift crea e gestisce automaticamente un gruppo di sicurezza di rete.
- La subnet secondaria e la subnet primaria non possono sovrapporsi alle reti locali o a qualsiasi altra rete in Azure.
Pianificare attentamente gli indirizzi IP e le dimensioni della subnet della rete virtuale per supportare il ridimensionamento del cluster. Potrebbe essere necessario aggiungere nodi.
È possibile esporre i servizi e le route di Azure Red Hat OpenShift usando servizi di bilanciamento del carico pubblici o interni. Configurare i servizi di bilanciamento del carico interni nella stessa subnet dei nodi secondari. In un cluster in uscita con restrizioni non è possibile usare i servizi di bilanciamento del carico pubblici a causa del routing asimmetrico.
Azure Red Hat OpenShift usa CoreDNS per fornire la risoluzione dei nomi ai pod in esecuzione nel cluster.
- CoreDNS risolve direttamente i domini interni del cluster.
- Azure Red Hat OpenShift supporta anche server DNS personalizzati nella rete virtuale.
- Altri domini vengono inoltrati ai server DNS configurati in Azure Rete virtuale. I server DNS saranno il resolver DNS predefinito di Azure o tutti i server DNS personalizzati configurati a livello di rete virtuale.
- È possibile personalizzare l'inoltro DNS in Azure Red Hat OpenShift CoreDNS.
- Se nella rete virtuale non sono configurati server DNS personalizzati, Azure Red Hat OpenShift usa il sistema di risoluzione DNS di Azure predefinito.
Per altre informazioni sul DNS, vedere Configurazione DNS dell'endpoint privato di Azure.
È possibile inviare traffico di rete in uscita (in uscita) tramite Firewall di Azure o tramite un cluster di appliance virtuale di rete.
- Per impostazione predefinita, i cluster Azure Red Hat OpenShift hanno accesso a Internet senza restrizioni.
- È possibile distribuire Azure Red Hat OpenShift con traffico in uscita limitato aggiungendo una route definita dall'utente con una route definita dall'utente con una 0.0.0.0/0 route per Firewall di Azure o a un'appliance virtuale di rete. Azure Red Hat OpenShift ha una funzione di blocco in uscita che garantisce l'accesso, anche se il traffico in uscita è limitato da un'appliance firewall o da altri mezzi.
- È possibile scegliere tra due modelli di distribuzione di Azure Red Hat OpenShift:
  - Endpoint server API privato e controller di ingresso privato
  - Endpoint server API pubblico e controller di ingresso pubblico
- Se si usa l'accesso in uscita senza restrizioni, è necessario gestire attentamente le porte in uscita per assicurarsi di non usare tutte le porte in uscita disponibili. Per altre informazioni, vedere Usare SNAT (Source Network Address Translation) per le connessioni in uscita.
Per impostazione predefinita, tutti i pod in un cluster Azure Red Hat OpenShift possono inviare e ricevere traffico senza limitazioni. Tutti i pod in un progetto sono accessibili da altri pod ed endpoint di rete. Per isolare uno o più pod in un progetto, è possibile creare NetworkPolicy oggetti nel progetto per indicare le connessioni in ingresso consentite. Red Hat OpenShift software-defined networking (SDN) supporta l'uso dei criteri di rete nella modalità di isolamento di rete predefinita.
Una mesh di servizi offre funzionalità come gestione traffico, resilienza, criteri, sicurezza, identità avanzate e osservabilità. Per altre informazioni su Red Hat OpenShift Service Mesh, vedere Differenze di Service Mesh e Istio.
Meccanismi di bilanciamento del carico globali come Gestione traffico di Azure e Frontdoor di Azure aumentano la resilienza instradando il traffico tra più cluster, potenzialmente in aree di Azure diverse.

Cluster privati

Un indirizzo IP del cluster dell'API Azure Red Hat OpenShift può essere pubblico o privato. I cluster privati espongono l'API Azure Red Hat OpenShift su un indirizzo IP privato, ma non su uno pubblico. L'API Azure Red Hat OpenShift non deve essere accessibile tramite il relativo indirizzo IP. Accedere invece all'API Azure Red Hat OpenShift tramite il nome di dominio completo (FQDN). DNS di Azure risolve il nome di dominio completo dell'API Azure Red Hat OpenShift nel relativo indirizzo IP.

In linea con le procedure comprovate della zona di destinazione di Azure, la risoluzione DNS per i carichi di lavoro di Azure è offerta da server DNS centralizzati distribuiti nella sottoscrizione di connettività. I server DNS di Azure si trovano in una rete virtuale hub o in una rete virtuale di servizi condivisi connessa a un'istanza di Azure rete WAN virtuale. I server DNS risolvono in modo condizionale nomi pubblici e specifici di Azure usando DNS di Azure (indirizzo 168.63.129.16IP). I server risolvono i nomi privati usando i server DNS aziendali. Questo modello di connettività è comune ed è importante consentire l'accesso privato ad altre risorse di Azure se si usano endpoint privati.

Traffico dagli utenti dell'applicazione al cluster

Usare i controller in ingresso per esporre le applicazioni in esecuzione nei cluster Azure Red Hat OpenShift.

I controller di ingresso forniscono il routing a livello di applicazione con un lieve aumento della complessità.
Azure Red Hat OpenShift crea una voce DNS generica che semplifica l'accesso alle applicazioni esposte nel cluster. Una voce DNS di esempio è *.apps.<cluster-ID>.<region>.aroapp.io. È utile per un cluster privato instradare il traffico per l'applicazione.
Azure Red Hat OpenShift offre un controller e route in ingresso predefiniti.
È possibile usare l'ingresso di Azure Red Hat OpenShift con Frontdoor di Azure.
Allineare la configurazione alla progettazione dei filtri in uscita per evitare il routing asimmetrico. Le route definite dall'utente potrebbero causare il routing asimmetrico.
Se lo scenario richiede la terminazione TLS, valutare la modalità di gestione dei certificati TLS.

Importante

Se si usa Firewall di Azure per limitare il traffico in uscita e creare una route definita dall'utente per forzare tutto il traffico in uscita, assicurarsi di creare una regola DNAT (Destination Network Address Translation) appropriata in Firewall di Azure per consentire correttamente il traffico in ingresso. L'uso del servizio Firewall di Azure con una route definita dall'utente interrompe la configurazione in ingresso a causa del routing asimmetrico. Il problema si verifica se la subnet di Azure Red Hat OpenShift ha una route predefinita che passa all'indirizzo IP privato del firewall, ma si usa un servizio di bilanciamento del carico pubblico (in ingresso o servizio Kubernetes di tipo Load Balancer). In questo caso, il traffico del servizio di bilanciamento del carico in ingresso viene ricevuto tramite l'indirizzo IP pubblico, ma il percorso di ritorno passa attraverso l'indirizzo IP privato del firewall. Poiché il firewall è con stato, elimina il pacchetto restituito perché il firewall non rileva una sessione stabilita. Per informazioni su come integrare Firewall di Azure con il servizio di bilanciamento del carico in ingresso o del servizio, vedere Integrare Firewall di Azure con Azure Load Balancer Standard.

I passaggi seguenti descrivono il flusso se si usa Frontdoor di Azure con un cluster privato di Azure Red Hat OpenShift e un controller di ingresso:

I client dalla rete Internet pubblica risolvono il nome DNS per l'applicazione che punta a Frontdoor di Azure.
Frontdoor di Azure usa il servizio collegamento privato di Azure per accedere all'indirizzo IP privato del servizio di bilanciamento del carico di rete interno di Azure e accedere a un'applicazione nel controller di ingresso di Azure Red Hat OpenShift.

Questi passaggi descrivono il flusso per un'applicazione non Web che accede a un cluster privato di Azure Red Hat OpenShift:

I client dalla rete Internet pubblica risolvono il nome DNS per l'applicazione che punta all'indirizzo IP pubblico di Firewall di Azure o a un'appliance virtuale di rete.
Firewall di Azure o l'appliance virtuale di rete inoltrano il traffico (DNAT) al cluster privato di Azure Red Hat OpenShift usando l'indirizzo IP privato del servizio di bilanciamento del carico di rete interno di Azure per accedere all'applicazione nel controller di ingresso di Azure Red Hat OpenShift.

Traffico dai pod di Azure Red Hat OpenShift ai servizi back-end

I pod in esecuzione all'interno del cluster Azure Red Hat OpenShift potrebbero dover accedere a servizi back-end come Archiviazione di Azure, Azure Key Vault, database SQL di Azure e Azure Cosmos DB. È possibile usare endpoint servizio di rete virtuale e collegamento privato di Azure per proteggere la connettività a questi servizi gestiti da Azure.

Se si usano endpoint privati di Azure per il traffico back-end, è possibile usare le zone di Azure DNS privato per la risoluzione DNS per i servizi di Azure. Poiché i resolver DNS per l'intero ambiente si trovano nella rete virtuale hub (o nella rete virtuale dei servizi condivisi, se si usa il modello di connettività rete WAN virtuale), creare queste zone private nella sottoscrizione di connettività. Per creare il record A necessario per risolvere il nome di dominio completo del servizio privato, è possibile associare la zona DNS privata nella sottoscrizione di connettività all'endpoint privato nella sottoscrizione dell'applicazione. Questa operazione richiede autorizzazioni specifiche in tali sottoscrizioni.

È possibile creare manualmente i record A, ma l'associazione della zona DNS privata all'endpoint privato comporta una configurazione meno soggetta a configurazioni errate.

La connettività back-end dai pod Di Azure Red Hat OpenShift ai servizi PaaS (Platform as a Service) di Azure esposti tramite endpoint privati segue questa sequenza:

I pod di Azure Red Hat OpenShift risolvono il nome di dominio completo di Azure PaaS usando i server DNS centrali nella sottoscrizione di connettività, definiti come server DNS personalizzati nella rete virtuale Azure Red Hat OpenShift.
L'indirizzo IP risolto è l'indirizzo IP privato degli endpoint privati, a cui si accede direttamente dai pod di Azure Red Hat OpenShift.

Il traffico tra i pod di Azure Red Hat OpenShift e gli endpoint privati per impostazione predefinita non passa attraverso l'istanza di Firewall di Azure nella rete virtuale hub (o l'hub virtuale protetto, se si usa un rete WAN virtuale), anche se il cluster Azure Red Hat OpenShift è configurato per il filtro in uscita con Firewall di Azure. L'endpoint privato crea una /32 route nelle subnet della rete virtuale dell'applicazione in cui viene distribuito Azure Red Hat OpenShift.

Suggerimenti per la progettazione

Se i criteri di sicurezza richiedono l'uso di un indirizzo IP privato per l'API Azure Red Hat OpenShift, distribuire un cluster Azure Red Hat OpenShift privato.
Usare Protezione DDoS di Azure per proteggere la rete virtuale usata per il cluster Azure Red Hat OpenShift, a meno che non si usi Firewall di Azure o Web Application Firewall in una sottoscrizione centralizzata.
Usare la configurazione DNS collegata alla configurazione di rete complessiva con Azure rete WAN virtuale o un'architettura hub-spoke, le zone DNS di Azure e la propria infrastruttura DNS.
Usare collegamento privato di Azure per proteggere le connessioni di rete e usare la connettività privata basata su IP ad altri servizi di Azure gestiti che supportano collegamento privato, ad esempio Archiviazione di Azure, Registro Azure Container, database SQL di Azure e Azure Key Vault.
Usare un controller di ingresso per fornire sicurezza e routing HTTP avanzati e offrire un singolo endpoint per le applicazioni.
Tutte le applicazioni Web configurate per l'uso di un ingresso devono usare la crittografia TLS e non devono consentire l'accesso tramite HTTP non crittografato.
Usare Frontdoor di Azure con Web Application Firewall per pubblicare in modo sicuro le applicazioni Azure Red Hat OpenShift in Internet.
Se i criteri di sicurezza richiedono di esaminare tutto il traffico Internet in uscita generato nel cluster Azure Red Hat OpenShift, proteggere il traffico di rete in uscita usando Firewall di Azure o un'appliance virtuale di rete di terze parti distribuita nella rete virtuale dell'hub gestito. Per altre informazioni, vedere Controllare il traffico in uscita verso un cluster Azure Red Hat OpenShift.
Usare il livello Azure Load Balancer Standard anziché il livello Basic per le applicazioni non Web.

Passaggi successivi

Pianificare l'organizzazione delle risorse per Azure Red Hat OpenShift.

Condividi tramite