IBM Cloud Docs
Informazioni sulla rete di cluster VPC

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 da lavoratore a lavoratore tramite sottoreti VPC

Prima di creare un cluster VPC per la prima volta, è necessario creare una sottorete VPC in ogni zona in cui si desidera distribuire i nodi worker. 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, è possibile ottenere una migliore segmentazione della rete creando i cluster in VPC separati. 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.

Se i tuoi nodi di lavoro devono accedere a un endpoint pubblico esterno al cluster, puoi abilitare un gateway pubblico sulla sottorete VPC in cui sono distribuiti i nodi di lavoro. Un gateway pubblico può essere collegato o scollegato da una sottorete in qualsiasi momento.

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 di IP predefiniti per le sottoreti VPC di accesso classico sono in conflitto con le sottoreti del piano di controllo IBM Cloud Kubernetes Service. 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 si utilizzano sottoreti con intervallo personalizzato per i nodi worker, è necessario assicurarsi che le sottoreti dei nodi worker non si sovrappongano alla sottorete dei pod del 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.
  • Dopo aver creato una sottorete VPC, non è possibile ridimensionarla o modificarne l'intervallo IP.
  • Più cluster nello stesso VPC possono condividere le sottoreti.
  • Le sottoreti VPC sono vincolate a una singola regione di zona e non possono estendersi su più zone o regioni.
  • Dopo aver creato una sottorete, non è possibile spostarla in un'altra zona, regione o VPC.
  • Se i nodi worker sono collegati a una sottorete esistente in una zona, non è possibile modificare la sottorete per quella zona nel 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

IBM Cloud Kubernetes Service utilizza diversi tipi di endpoint del servizio per stabilire una connessione dagli utenti del cluster autorizzati e dai nodi di lavoro al master Kubernetes. Gli utenti del cluster autorizzati comunicano con il master Kubernetes tramite gli endpoint del servizio cloud. A seconda della versione del tuo cluster, i nodi di lavoro comunicano con il master Kubernetes tramite gli endpoint del servizio cloud o gli 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 in IBM Cloud Kubernetes Service, non è possibile disabilitare l'endpoint del servizio cloud privato o impostare un cluster con il solo endpoint del servizio cloud pubblico.

Comunicazione tra nodi di lavoro e master nei cluster VPC

La comunicazione del nodo di lavoro con il master Kubernetes viene stabilita in modo diverso in base alla tua versione del cluster.

  • La comunicazione del nodo di lavoro con il master Kubernetes viene stabilita sul VPE(virtual private endpoint)VPC. Se è abilitato anche l'endpoint del servizio cloud pubblico, il traffico worker - to - master viene stabilito per metà sull'endpoint pubblico e per metà sul VPE per la protezione da potenziali interruzioni della rete pubblica o privata.

Per proteggere la comunicazione su endpoint del servizio cloud pubblici e privati o VPE, IBM Cloud Kubernetes Service configura automaticamente una connessione di connettività tra il master Kubernetes e i nodi di lavoro quando viene creato il cluster. I nodi worker parlano in modo sicuro con il master attraverso certificati TLS, mentre il master parla con i worker attraverso la connessione Konnectivity.

Comunicazione utente - master nei cluster VPC

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

  • Endpoint del servizio cloud pubblico e privato: Per impostazione predefinita, tutte le chiamate al master avviate dagli utenti autorizzati del cluster vengono instradate attraverso l'endpoint del servizio cloud pubblico. Se gli utenti autorizzati del cluster si trovano nella rete VPC o sono connessi tramite una connessione VPC VPN, il master è accessibile privatamente 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. Solo le richieste autorizzate al master del cluster che provengono dalle sottoreti dell'allowlist sono consentite attraverso gli endpoint di servizio del cluster. 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 di IBM Cloud su rete privata o pubblica

I nodi worker possono comunicare automaticamente e in modo sicuro con altri servizi IBM Cloud che supportano endpoint di servizi cloud privati, come IBM Cloud® Container Registry, attraverso la rete privata. Se un servizio IBM Cloud non supporta endpoint di servizi cloud privati, i nodi worker devono essere connessi a una sottorete a cui è collegato un gateway pubblico. I pod su quei nodi di lavoro possono comunicare in modo sicuro con i servizi sulla rete pubblica attraverso 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.

  • Se non si collegano gateway pubblici alle proprie sottoreti, è possibile creare regole in entrata per consentire l'ingresso da servizi che supportano endpoint di servizi cloud privati.
  • Se si collegano gateway pubblici alle sottoreti, è possibile creare regole in entrata e in uscita per consentire l'ingresso e l'uscita da servizi che supportano solo endpoint di servizi cloud pubblici.

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 si prevede di collegare il cluster a reti locali, consultare 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 i conflitti di subnet quando si crea un cluster dalla CLI specificando una subnet CIDR personalizzata per i pod nell'opzione --pod-subnet e una subnet CIDR personalizzata per i servizi nell'opzione --service-subnet.
  • Se la tua soluzione VPN preserva gli indirizzi IP di origine delle richieste, puoi creare degli instradamenti statici personalizzati per garantire che i tuoi nodi di lavoro possano instradare le risposte dal tuo cluster nuovamente alla tua 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 IBM Cloud Kubernetes Service.

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 quando si crea la VPC e che non è possibile convertire una VPC esistente per utilizzare l'accesso classico. Inoltre, è possibile impostare l'accesso all'infrastruttura classica solo per una VPC per regione e non è possibile impostare più di una VPC con accesso all'infrastruttura classica in una 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 cluster, si potrebbe voler rendere l'applicazione 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 VPC, un gruppo di sicurezza, denominato nel formato kube-<vpc-id>, viene automaticamente collegato alla tua istanza ALB.

Il gruppo di sicurezza kube-<vpc-id> collegato al tuo ALB VPC è lo stesso gruppo di sicurezza utilizzato per il gateway VPE privato che comunica con il master Kubernetes. Non modificare questo gruppo di sicurezza, poiché ciò potrebbe causare interruzioni della connettività di rete tra il cluster e il master Kubernetes. Puoi invece rimuovere il gruppo di sicurezza dall'ALB VPC e sostituirlo con un gruppo di sicurezza che crei e gestisci.

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

Traffico pubblico alle applicazioni cluster

Per rendere le vostre applicazioni accessibili da Internet, potete utilizzare i 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 VPC, un gruppo di sicurezza, denominato nel formato kube-<vpc-id>, viene automaticamente collegato alla tua istanza ALB.

Il gruppo di sicurezza kube-<vpc-id> collegato al tuo ALB VPC è lo stesso gruppo di sicurezza utilizzato per il gateway VPE privato che comunica con il master Kubernetes. Non modificare questo gruppo di sicurezza, poiché ciò potrebbe causare interruzioni della connettività di rete tra il cluster e il master Kubernetes. Puoi invece rimuovere il gruppo di sicurezza dall'ALB VPC e sostituirlo con un gruppo di sicurezza che crei e gestisci.

Nota che non è necessario un gateway pubblico sulle tue sottoreti per consentire il traffico di rete in entrata da Internet ai servizi LoadBalancer o agli ALB. I gateway pubblici sono necessari solo per consentire ai nodi di lavoro di effettuare richieste in uscita agli endpoint pubblici. Per ulteriori informazioni, vedi Pianificazione del bilanciamento del carico esterno pubblico.

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 vostre applicazioni, mentre le richieste pubbliche indesiderate alle vostre applicazioni vengono negate. Inoltre, i lavoratori hanno accesso automatico a tutti i servizi IBM Cloud che supportano endpoint di servizi cloud privati.

Configurazione di rete per un cluster VPC che esegue carichi di lavoro dell'applicazione rivolti a Internet.
Configurazione della rete per un cluster VPC che esegue carichi di lavoro di app rivolti 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 queste sottoreti non è richiesto alcun gateway pubblico. 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 del servizio cloud pubblico e privato: La comunicazione tra i nodi worker e il master viene stabilita sulla rete privata attraverso l'endpoint del servizio cloud privato. Per impostazione predefinita, tutte le chiamate al master avviate dagli utenti autorizzati del cluster vengono instradate attraverso l'endpoint del servizio cloud pubblico.
  • Solo endpoint del servizio privato: La comunicazione al master da parte dei nodi worker e degli utenti del cluster avviene sulla rete privata attraverso 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.

Comunicazioni tra nodo di lavoro e altri servizi o reti

Se il carico di lavoro dell'applicazione richiede altri servizi IBM Cloud, i nodi worker possono comunicare automaticamente e in modo sicuro con i servizi IBM Cloud che supportano gli endpoint dei servizi cloud privati sulla 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-<vpc-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.

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

In questo scenario, esegui dei carichi di lavoro in un cluster VPC che sono accessibili alle richieste da Internet. L'accesso pubblico è controllato in modo che gli utenti finali possano accedere alle tue applicazioni mentre le richieste pubbliche indesiderate alle tue applicazioni vengono negate. Tuttavia, potresti dover fornire anche un'uscita pubblica limitata dai tuoi nodi di lavoro a un endpoint pubblico e voler garantire che tale uscita pubblica sia controllata e isolata nel tuo cluster. Ad esempio, è possibile che i pod delle applicazioni debbano accedere a un servizio IBM Cloud che non supporta endpoint di servizi cloud privati e deve essere accessibile attraverso la rete pubblica.

Configurazione di rete per un cluster che consente un accesso pubblico limitato e sicuro.
Configurazione della rete per un cluster VPC che consente un accesso pubblico limitato e sicuro

Comunicazioni tra i nodi di lavoro

Per ottenere questa configurazione, ad esempio, in un cluster multizona che ha nodi di lavoro in due zone, crei una sottorete VPC in una zona a cui non è collegato un gateway pubblico e una sottorete VPC in un'altra zona a cui è collegato un gateway pubblico. Successivamente, crei un cluster VPC che utilizza queste sottoreti e zone VPC.

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

Quando crei il cluster, 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 del servizio cloud pubblico e privato: La comunicazione tra i nodi worker e il master viene stabilita sulla rete privata attraverso l'endpoint del servizio cloud privato. Per impostazione predefinita, tutte le chiamate al master avviate dagli utenti autorizzati del cluster vengono instradate attraverso l'endpoint del servizio cloud pubblico.
  • Solo endpoint del servizio privato: La comunicazione al master da parte dei nodi worker e degli utenti del cluster avviene sulla rete privata attraverso 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.

Comunicazioni tra nodo di lavoro e altri servizi o reti

Dopo aver creato il cluster, crei un pool di nodi lavoro che viene distribuito solo nella zona in cui la sottorete ha un gateway pubblico collegato. Qualsiasi pod dell'applicazione distribuito nei nodi di lavoro in questo pool può effettuare richieste a un endpoint pubblico tramite il gateway pubblico. Ad esempio, se vuoi che i pod dell'applicazione inviino i log a IBM Cloud Logs (che non supporta gli endpoint privati), puoi aggiungere una regola di affinità per l'etichetta dell'ID pool di nodi di lavoro alla distribuzione dell'applicazione. Questa regola di affinità garantisce che i pod dell'applicazione che richiedono l'uscita pubblica siano limitati a un solo pool di nodi di lavoro su una sottorete. Se si distribuiscono altre applicazioni che non richiedono un'uscita pubblica, è possibile aggiungere regole di anti-affinità alla distribuzione dell'applicazione, in modo che i pod dell'applicazione vengano distribuiti solo ai pool di lavoratori su subnet senza gateway pubblico.

Se il carico di lavoro dell'applicazione richiede altri servizi IBM Cloud che supportano endpoint di servizi cloud privati, i nodi worker possono comunicare automaticamente e in modo sicuro con questi servizi sulla rete VPC privata senza utilizzare un gateway pubblico.

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 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. Ad esempio, puoi utilizzare le regole in entrata per controllare il traffico pubblico in entrata verso le tue applicazioni tramite il programma di bilanciamento del carico VPC e le regole in uscita per controllare le richieste in uscita dalle tue applicazioni tramite il gateway pubblico.

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

Estensione del data center on-premises 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 in loco.
Impostazione della 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 queste sottoreti non è richiesto alcun gateway pubblico. 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 si creano le sottoreti VPC, è possibile scegliere prefissi di indirizzi personalizzati e creare il cluster utilizzando queste sottoreti. Inoltre, è possibile specificare una subnet CIDR personalizzata per i pod e i servizi utilizzando le opzioni --pod-subnet e --service-subnet nel comando ibmcloud ks cluster create quando si crea il 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 solo per consentire la comunicazione worker-to-master e user-to-master sulla 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 dell'applicazione richiede altri servizi IBM Cloud che supportano endpoint di servizi cloud privati, i nodi worker possono comunicare automaticamente e in modo sicuro con questi servizi attraverso 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.