Informazioni sulla rete di cluster VPC

Quando crei il tuo cluster, devi scegliere una configurazione di rete in modo che alcuni componenti cluster possano comunicare tra loro e con reti o servizi esterni al cluster.

Comunicazione tra lavoratori tramite sottoreti VPC

Prima di creare un cluster VPC per la prima volta, è necessario creare una sottorete VPC in ciascuna zona in cui si desidera distribuire i nodi di lavoro. Una sottorete VPC è un intervallo di indirizzi IP privati specificato (blocco CIDR) e configura un gruppo di nodi di lavoro e pod come se fossero collegati allo stesso cavo fisico.

Quando crei un cluster, specifichi una sottorete VPC esistente per ogni zona. Ogni nodo di lavoro che aggiungi in un cluster viene distribuito con un indirizzo IP privato dalla sottorete VPC in quella zona. Dopo il provisioning del nodo di lavoro, l'indirizzo IP del nodo di lavoro persiste dopo un'operazione di reboot, ma cambia dopo le operazioni di replace e update.

Le sottoreti forniscono un canale per la connettività tra i nodi di lavoro all'interno del cluster. Inoltre, qualsiasi sistema connesso a una delle sottoreti private nello stesso VPC può comunicare con i nodi di lavoro. Ad esempio, tutte le sottoreti di un VPC possono comunicare tramite l'instradamento di livello 3 privato con un router VPC integrato. Se hai più cluster che devono comunicare tra loro, puoi creare i cluster nello stesso VPC. Tuttavia, se i cluster non devono comunicare tra loro, è possibile ottenere una migliore segmentazione della rete creando i cluster in VPC separate. Puoi anche creare degli ACL (Access Control List) per le tue sottoreti VPC per mediare il traffico sulla rete privata. Gli ACL sono costituiti da regole in entrata e in uscita che definiscono quali ingressi e uscite sono consentiti per ciascuna sottorete VPC.

Quando crei un cluster di VPC e abiliti entrambi gli endpoint del servizio cloud pubblico e privato durante la creazione del cluster, l'endpoint del servizio cloud pubblico viene utilizzato per impostazione predefinita per accedere a componenti come la console web Red Hat OpenShift del tuo cluster. Affinché i pod della console stabiliscano una connessione pubblica sicura su Internet tramite l'endpoint del servizio pubblico, devi abilitare un gateway pubblico su ogni sottorete VPC a cui vengono distribuiti i tuoi nodi di lavoro.

Quando crei un cluster VPC e abiliti solo l'endpoint del servizio cloud privato durante la creazione del cluster, l'endpoint del servizio cloud privato viene utilizzato per impostazione predefinita per accedere ai componenti Red Hat OpenShift come la console web Red Hat OpenShift o OperatorHub. Devi essere connesso alla rete VPC privata, ad esempio tramite una connessione VPN, per accedere a tali componenti o eseguire i comandi kubectl nel tuo cluster.

L'intervallo di indirizzi IP predefinito per le sottoreti VPC è 10.0.0.0 – 10.255.255.255. Per un elenco di intervalli di indirizzo IP per ogni zona VPC, vedi Prefissi di indirizzo predefiniti del VPC.

Se abiliti l'accesso classico quando crei il tuo VPC, i prefissi di indirizzo predefiniti di accesso classico determinano automaticamente gli intervalli IP di tutte le sottoreti che crei. Tuttavia, gli intervalli IP predefiniti per le sottoreti VPC di accesso classico sono in conflitto con le sottoreti per il piano di controllo Red Hat OpenShift on IBM Cloud. Invece, devi creare il VPC senza i prefissi di indirizzo predefiniti automatici e quindi creare i tuoi propri prefissi di indirizzo e sottoreti all'interno di tali intervalli per il tuo cluster.

Devi creare il tuo cluster utilizzando sottoreti con un intervallo personalizzato? Consulta questa guida sui prefissi di indirizzo personalizzati. Se utilizzi sottoreti con intervallo personalizzato per i tuoi nodi di lavoro, devi assicurarti che le sottoreti dei nodi di lavoro non si sovrappongano alla sottorete dei pod del tuo cluster.

Non eliminare le sottoreti che colleghi al tuo cluster durante la creazione del cluster o quando aggiungi nodi di lavoro in una zona. Se elimini una sottorete VPC utilizzata dal tuo cluster, qualsiasi programma di bilanciamento del carico che utilizza gli indirizzi IP dalla sottorete potrebbe presentare dei problemi e potresti non essere in grado di creare nuovi programmi di bilanciamento del carico.

Quando crei le sottoreti VPC per i tuoi cluster, tieni presente le seguenti funzioni e limitazioni. Per ulteriori informazioni sulle sottoreti VPC, vedi Caratteristiche delle sottoreti nel VPC.

  • La dimensione CIDR predefinita di ogni sottorete VPC è /24, che può supportare fino a 253 nodi di lavoro. Se prevedi di distribuire più di 250 nodi di lavoro per ogni zona in un cluster, considera la possibilità di creare una sottorete di dimensioni maggiori.
  • Una volta creata una sottorete VPC, non è possibile modificarne le dimensioni né cambiare l'intervallo di indirizzi IP.
  • Più cluster nello stesso VPC possono condividere le sottoreti.
  • Le sottoreti VPC sono associate a una singola zona o regione e non possono estendersi su più zone o regioni.
  • Una volta creata una sottorete, non è possibile spostarla in un'altra zona, regione o VPC.
  • Se sono presenti nodi di lavoro collegati a una sottorete esistente in una zona, non è possibile modificare la sottorete di quella zona all'interno del cluster.
  • Gli intervalli 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16 non sono consentiti.

Comunicazione da operatore a master e da utente a master utilizzando endpoint privati virtuali o endpoint del servizio cloud

Red Hat OpenShift on IBM Cloud utilizza diversi tipi di endpoint di servizio per stabilire una connessione dagli utenti autorizzati del cluster e dai nodi worker al master Kubernetes. Gli utenti autorizzati del cluster comunicano con il master Kubernetes attraverso gli endpoint dei servizi cloud. A seconda della versione del cluster, i nodi worker comunicano con il master Kubernetes attraverso endpoint di servizi cloud o endpoint privati virtuali VPC.

Prima di creare un cluster, è necessario abilitare l'account per utilizzare gli endpoint del servizio. Per abilitare gli endpoint del servizio, esegui ibmcloud account update --service-endpoint-enable true.

Nei cluster VPC di Red Hat OpenShift on IBM Cloud non è possibile disabilitare l'endpoint del servizio cloud privato né configurare un cluster utilizzando esclusivamente l'endpoint del servizio cloud pubblico.

Per impostazione predefinita, il cluster VPC viene creato con un endpoint di servizio sia pubblico che privato. Per creare cluster con nodi di lavoro connessi solo alla rete privata, devi abilitare solo l'endpoint del servizio privato durante la creazione del cluster. non abilitare l'endpoint del servizio pubblico. Ad esempio, per creare un cluster VPC con solo un endpoint del servizio cloud privato nella CLI, includi l'opzione --disable-public-service-endpoint. Se si seleziona questa opzione, il cluster verrà creato con router e controller Ingress che, per impostazione predefinita, espongono le applicazioni solo sulla rete privata. Se in seguito vuoi esporre le tue applicazioni su una rete pubblica, devi creare manualmente dei router e controller Ingress pubblici.

Comunicazione tra nodi di lavoro e master nei cluster VPC

La comunicazione tra i nodi worker e il master di Kubernetes utilizza, per impostazione predefinita, l'endpoint privato virtuale(VPE)della VPC. Il gateway VPE per il tuo cluster utilizza uno di questi due formati di nome host a seconda della regione: CLUSTERID.vpe.private.REGION.containers.cloud.ibm.com oppure CLUSTERID.private.REGION.containers.cloud.ibm.com. Tutto il traffico da worker a master viene instradato attraverso questo gateway VPE privato.

Se la connessione al gateway VPE non va a buon fine e nel cluster è disattivata la protezione del traffico in uscita, i nodi di lavoro ricorrono all'endpoint del servizio cloud pubblico. Questa soluzione di ripiego viene attivata solo quando il gateway VPE è irraggiungibile, non durante il normale funzionamento. Se è abilitata la protezione del traffico in uscita, non avviene alcun ripiego sull'endpoint pubblico.

Per proteggere la comunicazione su endpoint o VPE del servizio cloud pubblico e privato, Red Hat OpenShift on IBM Cloud configura automaticamente una connessione Konnectivity tra il master Kubernetes e i nodi di lavoro quando viene creato il cluster. I nodi worker comunicano in modo sicuro con il master tramite certificati TLS, mentre il master comunica con i worker tramite la connessione Konnectivity.

Comunicazione utente - master nei cluster VPC

È possibile consentire agli utenti autorizzati del cluster di comunicare con il master di Kubernetes abilitando gli endpoint del servizio cloud pubblico e privato, oppure solo l'endpoint del servizio cloud privato.

  • Endpoint dei servizi cloud pubblici e privati: per impostazione predefinita, tutte le chiamate al master avviate da utenti autorizzati del cluster vengono instradate tramite l'endpoint del servizio cloud pubblico. Se gli utenti autorizzati del cluster si trovano nella rete VPC o sono connessi tramite una connessione VPN VPC, è possibile accedere al master in modo privato tramite l'endpoint del servizio cloud privato.
  • Solo endpoint del servizio cloud privato: per accedere al master tramite l'endpoint del servizio cloud privato, gli utenti del cluster autorizzati devono trovarsi nella tua rete VPC o essere connessi tramite una connessione VPN VPC.

È possibile proteggere l'accesso alla rete degli endpoint dei servizi del cluster utilizzando restrizioni basate sul contesto. Attraverso gli endpoint di servizio del cluster sono consentite solo le richieste autorizzate rivolte al master del cluster provenienti da sottoreti presenti nell'elenco delle sottoreti consentite. L'uso di restrizioni basate sul contesto aiuta a prevenire le attività di scansione non autorizzate. Per ulteriori informazioni, vedere Uso delle restrizioni basate sul contesto.

Comunicazioni tra nodo di lavoro e altri servizi o reti

Consenti ai tuoi nodi di lavoro di comunicare in modo sicuro con altri servizi IBM Cloud, reti in loco, altri VPC e con le risorse dell'infrastruttura classica IBM Cloud.

Comunicazione con altri servizi IBM Cloud tramite la rete privata o pubblica

I nodi di lavoro possono comunicare in modo automatico e sicuro con altri servizi di IBM Cloud che supportano endpoint di servizi cloud privati, come IBM Cloud® Container Registry, tramite la rete privata. Se un servizio di IBM Cloud non supporta gli endpoint dei servizi cloud privati, i nodi di lavoro possono comunicare in modo sicuro con i servizi tramite la rete pubblica, utilizzando il gateway pubblico della sottorete.

Tieni presente che se utilizzi gli ACL (access control list) per le tue sottoreti VPC, devi creare delle regole in entrata e in uscita per consentire ai tuoi nodi di lavoro di comunicare con questi servizi.

Comunicazioni con le risorse nei data center in loco

Per connettere il cluster con il tuo data center in loco, puoi utilizzare la VPN IBM Cloud® Virtual Private Cloud o IBM Cloud® Direct Link.

Se prevedi di collegare il tuo cluster a reti locali, consulta le seguenti informazioni utili:

  • Potresti avere dei conflitti di sottorete con l'intervallo 172.30.0.0/16 predefinito fornito da IBM per i pod e l'intervallo 172.21.0.0/16 per i servizi. È possibile evitare conflitti tra sottoreti quando si crea un cluster dalla CLI specificando un CIDR di sottorete personalizzato per i pod nell'opzione --pod-subnet e un CIDR di sottorete personalizzato per i servizi nell'opzione --service-subnet .
  • Se la tua soluzione VPN conserva gli indirizzi IP di origine delle richieste, puoi creare instradamenti statici personalizzati per garantire che i tuoi nodi di lavoro possano reinstradare le risposte dal tuo cluster alla rete in loco.
  • Tieni presente che gli intervalli di sottorete 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16 non sono consentiti perché sono riservati per la funzionalità del piano di controllo Red Hat OpenShift on IBM Cloud.

Comunicazioni con le risorse in altri VPC

Per connettere un intero VPC a un altro VPC nel tuo account, puoi utilizzare la VPN IBM Cloud VPC o IBM Cloud® Transit Gateway.

  • Per iniziare a lavorare con la VPN IBM Cloud VPC, attieniti alla procedura in Connessione di due VPC utilizzando la VPN per creare un gateway VPC su una sottorete in ciascun VPC e creare una connessione VPC tra i due gateway VPC. Nota che se hai personalizzato gli ACL (access control list) o i gruppi di sicurezza nel tuo VPC, devi assicurarti che gli ACL e i gruppi di sicurezza consentano ai tuoi nodi di lavoro di comunicare con i nodi di lavoro nell'altro VPC.
  • Per iniziare con IBM Cloud Transit Gateway, vedi la documentazione diTransit Gateway. Le istanze Transit Gateway possono essere configurate per l'instradamento tra VPC che si trovano nella stessa regione (instradamento locale) o VPC che si trovano in regioni differenti (instradamento globale).

Comunicazioni con le risorse classiche di IBM Cloud

Se devi connettere il tuo cluster alle risorse presenti nella tua infrastruttura classica IBM Cloud, puoi configurare un VPC con accesso classico o utilizzare IBM Cloud Transit Gateway.

  • Per un'introduzione a un VPC con l'accesso classico, vedi Configurazione dell'accesso all'infrastruttura classica. Si noti che è necessario abilitare l'accesso classico al momento della creazione della VPC e che non è possibile convertire una VPC esistente per utilizzare l'accesso classico. Inoltre, è possibile configurare l'accesso all'infrastruttura classica per una sola VPC per regione e non è possibile configurare più di una VPC con accesso all'infrastruttura classica in una stessa regione.
  • Per un'introduzione a IBM Cloud Transit Gateway, vedi la documentazione di Transit Gateway. Puoi connettere più VPC all'infrastruttura classica, ad esempio utilizzando IBM Cloud Transit Gateway per gestire l'accesso tra i tuoi VPC in più regioni alle risorse nella tua infrastruttura classica IBM Cloud.

Comunicazioni esterne alle applicazioni in esecuzione sui nodi di lavoro

Consenti le richieste di traffico privato o pubblico dall'esterno del cluster alle tue applicazioni eseguite sui nodi di lavoro.

Traffico privato alle applicazioni cluster

Quando si distribuisce un'applicazione nel proprio cluster, potrebbe essere opportuno renderla accessibile solo agli utenti e ai servizi che si trovano sulla stessa rete privata del cluster. Il bilanciamento del carico privato è ideale per rendere la tua applicazione disponibile alle richieste provenienti dall'esterno del cluster, senza esporre l'applicazione al pubblico generale. Puoi anche utilizzare il bilanciamento del carico privato per testare l'accesso, l'instradamento delle richieste e altre configurazioni della tua applicazione, prima di esporla al pubblico tramite servizi di rete pubblica.

Per consentire le richieste di traffico di rete privata dall'esterno del cluster alle tue applicazioni, puoi utilizzare i servizi di rete Kubernetes privata, come ad esempio creando servizi LoadBalancer. Ad esempio, quando crei un servizio LoadBalancer Kubernetes nel tuo cluster, un programma di bilanciamento del carico per VPC viene creato automaticamente nel tuo VPC all'esterno del cluster. Il programma di bilanciamento del carico VPC è multizonale e instrada le richieste per la tua applicazione tramite le NodePort private che vengono aperte automaticamente sui tuoi nodi di lavoro. Per gli ALB e gli NLB VPC, un gruppo di sicurezza, denominato sotto forma di kube-lbaas-<cluster-id>, viene automaticamente collegato ai bilanciatori di carico.

Per ulteriori informazioni, vedi Pianificazione del bilanciamento del carico esterno privato.

Traffico pubblico alle applicazioni cluster

Per rendere le tue app accessibili dalla rete Internet pubblica, puoi utilizzare servizi di rete pubblici. Anche se i tuoi nodi di lavoro sono connessi solo alle sottoreti VPC private, il programma di bilanciamento del carico VPC creato per i servizi di rete pubblici può instradare le richieste pubbliche alla tua applicazione sulla rete privata fornendo all'applicazione un URL pubblico. Quando un'applicazione è esposta pubblicamente, chiunque abbia l'URL pubblico può inviare una richiesta alla tua applicazione.

Puoi utilizzare i servizi di rete Kubernetes pubblica, come ad esempio creando i servizi LoadBalancer. Ad esempio, quando crei un servizio LoadBalancer Kubernetes nel tuo cluster, un programma di bilanciamento del carico per VPC viene creato automaticamente nel tuo VPC all'esterno del cluster. Il programma di bilanciamento del carico VPC è multizonale e instrada le richieste per la tua applicazione tramite le NodePort private che vengono aperte automaticamente sui tuoi nodi di lavoro. Per gli ALB e gli NLB VPC, un gruppo di sicurezza, denominato sotto forma di kube-lbaas-<cluster-id>, viene automaticamente collegato ai bilanciatori di carico.

Scenari di esempio per le configurazioni di rete del cluster VPC

Ora che hai compreso i principi di base della rete del cluster, consulta alcuni scenari di esempio in cui varie configurazioni di rete del cluster VPC possono soddisfare le tue esigenze di carico di lavoro.

Scenario: Esegui carichi di lavoro dell'applicazione con connessione Internet in un cluster VPC

In questo scenario, esegui dei carichi di lavoro in un cluster VPC che sono accessibili alle richieste da Internet. L'accesso pubblico è controllato dai gruppi di sicurezza, in modo che gli utenti finali possano accedere alle tue app, mentre le richieste pubbliche indesiderate alle tue app vengano respinte. Inoltre, i vostri dipendenti hanno accesso automatico a tutti i servizi IBM Cloud che supportano gli endpoint dei servizi cloud privati.

Configurazione di rete per un cluster VPC che esegue carichi di lavoro di applicazioni rivolte a Internet.
Configurazione di rete per un cluster VPC che esegue carichi di lavoro di applicazioni rivolte a Internet

Comunicazioni tra i nodi di lavoro

Per ottenere questa configurazione, crei le sottoreti VPC in ogni zona in cui vuoi distribuire i nodi di lavoro. Per eseguire i componenti predefiniti di Red Hat OpenShift, come la console web o OperatorHub,, sono necessari dei gateway pubblici per queste sottoreti. Successivamente, crei un cluster VPC che utilizza queste sottoreti VPC.

Comunicazioni tra nodo di lavoro e master e tra utente e master

Puoi scegliere di consentire le comunicazioni tra nodo di lavoro e master e tra utente e master sulle reti pubbliche e private o solo sulla rete privata.

  • Endpoint dei servizi cloud pubblici e privati: la comunicazione tra i nodi di lavoro e il master viene stabilita sulla rete privata tramite l'endpoint del servizio cloud privato. Per impostazione predefinita, tutte le chiamate al master avviate da utenti autorizzati del cluster vengono instradate tramite l'endpoint del servizio cloud pubblico.
  • Solo endpoint di servizio privato: la comunicazione verso il master, sia da parte dei nodi worker che degli utenti del cluster, viene stabilita sulla rete privata tramite l'endpoint di servizio cloud privato. Gli utenti del cluster autorizzati devono trovarsi nella tua rete VPC o essere connessi tramite una connessione VPN VPC.

Comunicazioni tra nodo di lavoro e altri servizi o reti

Se il carico di lavoro della tua app richiede altri servizi di IBM Cloud, i tuoi nodi di lavoro possono comunicare in modo automatico e sicuro con i servizi di IBM Cloud che supportano endpoint di servizi cloud privati tramite la rete VPC privata.

Comunicazioni esterne alle applicazioni in esecuzione sui nodi di lavoro

Dopo aver verificato la tua applicazione, puoi esporla a Internet creando un servizio LoadBalancer Kubernetes pubblico o utilizzando gli ALB (application load balancer) Ingress pubblici predefiniti. Il programma di bilanciamento del carico VPC che viene creato automaticamente nel VPC all'esterno del tuo cluster quando utilizzi uno di questi servizi instrada il traffico verso la tua applicazione. Puoi migliorare la sicurezza del tuo cluster e controllare il traffico di rete pubblico alle tue applicazioni sostituendo il gruppo di sicurezza kube-lbaas-<cluster-id>, che viene automaticamente applicato all'ALB VPC, con un gruppo di sicurezza che crei e gestisci. Quando viene applicato agli ALB, i gruppi di sicurezza controllano quale traffico in entrata è consentito al tuo cluster tramite l'ALB.

Sei pronto a iniziare a usare un cluster per questo scenario? Dopo aver pianificato la configurazione ad alta disponibilità, vedere Creazione di cluster VPC.

Estendi il tuo data center locale a un cluster VPC

In questo scenario, esegui dei carichi di lavoro in un cluster VPC. Tuttavia, vuoi che questi carichi di lavoro siano accessibili solo a servizi, database o altre risorse presenti nelle tue reti private in un data center in loco. I carichi di lavoro del tuo cluster potrebbero dover accedere ad alcuni altri servizi IBM Cloud che supportano le comunicazioni sulla rete privata.

Configurazione di rete per un cluster VPC che estende un data center on-premise.
Configurazione di rete per un cluster VPC che estende un data center on-premise

Comunicazioni tra i nodi di lavoro

Per ottenere questa configurazione, crei le sottoreti VPC in ogni zona in cui vuoi distribuire i nodi di lavoro. Per eseguire i componenti predefiniti di Red Hat OpenShift, come la console web o OperatorHub,, sono necessari dei gateway pubblici per queste sottoreti. Successivamente, crei un cluster VPC che utilizza queste sottoreti VPC.

Tieni presente che potrebbero verificarsi dei conflitti di sottorete tra gli intervalli predefiniti per i nodi di lavoro, pod e servizi e le sottoreti nelle tue reti in loco. Quando crei le sottoreti della tua VPC, puoi scegliere prefissi di indirizzo personalizzati e quindi creare il tuo cluster utilizzando tali sottoreti. Inoltre, è possibile specificare un CIDR di sottorete personalizzato per i pod e i servizi utilizzando le opzioni --pod-subnet e --service-subnet nel comando ibmcloud oc cluster create al momento della creazione del cluster.

Comunicazioni tra nodo di lavoro e master e tra utente e master

Quando si crea il cluster, si abilita l'endpoint del servizio cloud privato esclusivamente per consentire la comunicazione da worker a master e da utente a master tramite la rete privata. Gli utenti del cluster autorizzati devono trovarsi nella tua rete VPC o essere connessi tramite una connessione VPN VPC.

Comunicazioni tra nodo di lavoro e altri servizi o reti

Per connettere il cluster con il tuo data center in loco, puoi configurare il servizio VPN VPC. La VPN IBM Cloud VPC connette il tuo intero VPC a un data center in loco. Se il carico di lavoro della tua app richiede altri servizi di IBM Cloud che supportano endpoint di servizi cloud privati, i tuoi nodi di lavoro possono comunicare in modo automatico e sicuro con tali servizi tramite la rete VPC privata.

Comunicazioni esterne alle applicazioni in esecuzione sui nodi di lavoro

Dopo aver verificato la tua applicazione, puoi esporla alla rete privata creando un servizio LoadBalancer Kubernetes privato o utilizzando gli ALB (application load balancer) Ingress privati predefiniti. Il programma di bilanciamento del carico VPC che viene creato automaticamente nel VPC all'esterno del tuo cluster quando utilizzi uno di questi servizi instrada il traffico verso la tua applicazione. Nota che il programma di bilanciamento del carico VPC espone la tua applicazione solo alla rete privata in modo che qualsiasi sistema in loco con una connessione alla sottorete VPC possa accedere all'applicazione. Puoi migliorare la protezione del tuo cluster e controllare le applicazioni del traffico pubblico modificando il gruppo di protezione VPC predefinito per il tuo cluster. I gruppi di sicurezza sono costituiti da regole che definiscono quale traffico in entrata è consentito per i tuoi nodi di lavoro.

Sei pronto a iniziare a usare un cluster per questo scenario? Dopo aver pianificato la configurazione ad alta disponibilità, vedere Creazione di cluster VPC.

Passi successivi

Per continuare il processo di pianificazione, imparare a proteggere le informazioni sensibili nel cluster prendendo decisioni sul livello di crittografia da configurare. Se siete pronti per iniziare a configurare la rete, passate a Comprendere la rete Secure by Default del cluster VPC.