Connessioni VLAN per i nodi di lavoro

Tutti i nodi di lavoro devono essere collegati a una VLAN privata, in modo che ciascun nodo di lavoro possa inviare e ricevere informazioni dagli altri nodi di lavoro. La VLAN privata fornisce sottoreti private che vengono utilizzate per assegnare gli indirizzi IP privati ai nodi di lavoro e ai servizi dell'applicazione privati. Puoi creare un cluster con dei nodi di lavoro che sono connessi anche a una VLAN pubblica. La VLAN pubblica fornisce sottoreti pubbliche che vengono utilizzate per assegnare gli indirizzi IP pubblici ai nodi di lavoro e ai servizi dell'applicazione pubblici. Tuttavia, se è necessario proteggere le applicazioni dall'interfaccia di rete pubblica, sono disponibili diverse opzioni per garantire la sicurezza del cluster, come la creazione di politiche di ret Calico i o l'isolamento dei carichi di lavoro della rete esterna sui nodi worker periferici.

La prima volta che si crea un cluster in una zona, nel proprio account dell'infrastruttura IBM Cloud vengono automaticamente configurate una VLAN pubblica e una VLAN privata relative a quella zona. Se specifichi che i nodi di lavoro devono essere connessi solo a una VLAN privata, il provisioning automatico viene eseguito solo per la VLAN privata in quella zona. Per ogni cluster successivo che crei in tale zona, puoi specificare la coppia di VLAN che vuoi utilizzare. Puoi riutilizzare le stesse VLAN pubbliche e private che sono state create per te perché più cluster possono condividere VLAN.

Per ulteriori informazioni su VLAN, sottoreti e indirizzi IP, vedi Panoramica della rete in IBM Cloud Kubernetes Service.

Devi creare il tuo cluster utilizzando sottoreti personalizzate? Consulta Utilizzo delle sottoreti esistenti per creare un cluster.

Comunicazione del nodo di lavoro tra sottoreti e VLAN

In diverse situazioni, è necessario consentire ai componenti del cluster di comunicare attraverso più VLAN private. Ad esempio, se si desidera creare un cluster multizona, se si dispone di più VLAN per un cluster o se si hanno più sottoreti sulla stessa VLAN, i nodi di lavoro che si trovano su sottoreti diverse all’interno della stessa VLAN o su VLAN diverse non possono comunicare automaticamente tra loro. Devi abilitare il VRF (Virtual Routing and Forwarding) o lo spanning della VLAN per il tuo account dell'infrastruttura IBM Cloud.

• VRF (Virtual Routing and Forwarding): VRF consente a tutte le VLAN e sottoreti private nel tuo account dell'infrastruttura di comunicare tra loro. Inoltre, VRF è necessario per consentire ai lavoratori e al master di comunicare tramite l'endpoint del servizio cloud privato, nonché di comunicare con altre istanze di IBM Cloud che supportano gli endpoint del servizio cloud privato. Per controllare se una VRF è già abilitata, utilizza il comando ibmcloud account show. Per abilitare VRF, esegui ibmcloud account update --service-endpoint-enable true. L'output di questo comando ti richiede di aprire un caso di supporto per abilitare il tuo account all'utilizzo di VRF e degli endpoint del servizio. Il VRF elimina l'opzione di estensione delle VLAN per il tuo account, poiché tutte le VLAN sono in grado di comunicare tra loro. Quando VRF è abilitato, qualsiasi sistema connesso a qualsiasi VLAN privata nello stesso account IBM Cloud può comunicare con i nodi di lavoro del cluster. Puoi isolare il tuo cluster da altri sistemi sulla rete privata applicando delle politiche di rete privata Calico.
• Spanning VLAN: non è possibile abilitare l'endpoint del servizio cloud privato se si sceglie di abilitare lo spanning VLAN anziché il VRF. Abilitare lo spanning VLAN quando non è possibile o non si desidera abilitare il VRF, ad esempio quando non è necessario che il master sia accessibile sulla rete privata oppure se si utilizza un dispositivo gateway per accedere al master tramite la VLAN pubblica. Si noti che, ad esempio, se si dispone già di un dispositivo gateway e poi si aggiunge un cluster, le nuove sottoreti portatili assegnate al cluster non vengono configurate sul dispositivo gateway, ma la funzione VLAN spanning consente il routing tra le sottoreti.

Solo endpoint del servizio pubblico

Se non desideri o non puoi abilitare il VRF per il tuo account, i tuoi nodi di lavoro possono connettersi automaticamente al master Kubernetes tramite la VLAN pubblica, utilizzando l'endpoint del servizio cloud pubblico.

• La comunicazione tra i nodi di lavoro e il master viene stabilita in modo sicuro sulla rete pubblica tramite l'endpoint del servizio cloud pubblico.
• Il master è accessibile pubblicamente solo agli utenti autorizzati del cluster tramite l'endpoint del servizio cloud pubblico. Gli utenti del tuo cluster possono accedere in modo sicuro al tuo master Kubernetes su Internet per eseguire, ad esempio, i comandi kubectl.
• È possibile proteggere l'accesso agli endpoint dei servizi pubblici e privati del cluster utilizzando restrizioni basate sul contesto.

Endpoint dei servizi cloud pubblici e privati

Per rendere il tuo master accessibile pubblicamente o privatamente agli utenti del cluster, puoi abilitare gli endpoint del servizio cloud pubblico e privato. VRF è richiesto nel tuo account IBM Cloud e devi abilitare il tuo account per l'utilizzo degli endpoint del servizio. Per abilitare VRF e gli endpoint del servizio, esegui ibmcloud account update --service-endpoint-enable true.

• Se i nodi di lavoro sono collegati a VLAN pubbliche e private, la comunicazione tra i nodi di lavoro e il master avviene sia tramite la rete privata, attraverso l'endpoint del servizio cloud privato, sia tramite la rete pubblica, attraverso l'endpoint del servizio cloud pubblico. Instradando metà del traffico nodo di lavoro-master sull'endpoint pubblico e metà sull'endpoint privato, le tue comunicazioni master-nodo di lavoro sono protette da eventuali interruzioni della rete pubblica o privata. Se i nodi di lavoro sono collegati esclusivamente a VLAN private, la comunicazione tra i nodi di lavoro e il master avviene sulla rete privata esclusivamente tramite l'endpoint del servizio cloud privato.
• Il master è accessibile pubblicamente agli utenti autorizzati del cluster tramite l'endpoint del servizio cloud pubblico. È possibile accedere al master in modo privato tramite l'endpoint del servizio cloud privato, a condizione che gli utenti autorizzati del cluster si trovino nella rete privata IBM Cloud o siano connessi alla rete privata tramite una connessione VPN o IBM Cloud Direct Link. Nota: devi esporre l'endpoint master tramite un programma di bilanciamento del carico privato in modo che gli utenti possano accedere al master tramite una VPN o una connessione IBM Cloud Direct Link.
• È possibile proteggere l'accesso agli endpoint dei servizi pubblici e privati del cluster utilizzando restrizioni basate sul contesto.

Solo endpoint del servizio privato

Per rendere il tuo master accessibile solo privatamente, puoi abilitare l'endpoint del servizio cloud privato. VRF è richiesto nel tuo account IBM Cloud e devi abilitare il tuo account per l'utilizzo degli endpoint del servizio. Per abilitare VRF e gli endpoint del servizio, esegui ibmcloud account update --service-endpoint-enable true. Si noti che l'utilizzo dell'endpoint del servizio cloud privato non comporta alcun costo per la larghezza di banda, né in termini di fatturazione né di misurazione.

• La comunicazione tra i nodi di lavoro e il master viene stabilita sulla rete privata tramite l'endpoint del servizio cloud privato.
• Il master è accessibile privatamente se gli utenti del cluster autorizzati si trovano nella tua rete privata IBM Cloud o sono connessi alla rete privata tramite una connessione VPN o DirectLink. Nota che devi esporre l'endpoint master attraverso un programma di bilanciamento del carico privato affinché gli utenti possano accedere al master tramite una connessione VPN o DirectLink.
• È possibile proteggere l'accesso agli endpoint dei servizi pubblici e privati del cluster utilizzando restrizioni basate sul contesto.

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, attraverso la rete privata dell'infrastruttura IBM Cloud. Se un servizio IBM Cloud non supporta gli endpoint dei servizi cloud privati, i nodi di lavoro devono essere collegati a una VLAN pubblica in modo da poter comunicare in modo sicuro con i servizi tramite la rete pubblica.

Se si utilizzano policy di " Calico " o un dispositivo gateway per controllare le reti pubbliche o private dei nodi di lavoro, è necessario consentire l'accesso agli indirizzi IP pubblici dei servizi che supportano gli endpoint dei servizi cloud pubblici e, facoltativamente, agli indirizzi IP privati dei servizi che supportano gli endpoint dei servizi cloud privati.

• Consenti l'accesso agli indirizzi IP pubblici dei servizi nelle politiche Calico
• Consenti l'accesso agli indirizzi IP privati dei servizi che supportano gli endpoint dei servizi cloud privati nelle politiche di " Calico "
• Consenti l'accesso agli indirizzi IP pubblici dei servizi e agli indirizzi IP privati dei servizi che supportano gli endpoint dei servizi cloud privati nel firewall di un dispositivo gateway

IBM Cloud® Direct Link per la comunicazione sulla rete privata con risorse nei data center in loco

Per connettere il tuo cluster al tuo data center in loco, come con IBM Cloud Private, puoi configurare IBM Cloud Direct Link. Con IBM Cloud Direct Link, crei una connessione diretta e privata tra i tuoi ambienti di rete remota e IBM Cloud Kubernetes Service senza instradamento su internet pubblico.

Connessione VPN per la comunicazione tramite la rete pubblica con risorse situate in data center locali

• Nodi di lavoro collegati a VLAN pubbliche e private: Impostare un servizio VPN nel cluster per fornire un canale di comunicazione end-to-end sicuro su Internet tra il cluster e una rete locale. Esistono diverse opzioni open source, vedi Connettività VPN classica.

• Nodi di lavoro collegati esclusivamente a una VLAN privata: configurare un endpoint VPN su un dispositivo gateway, ad esempio un Vyatta ( Virtual Router Appliance ).

Se hai intenzione 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 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.

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 privato dall'esterno del cluster alle tue applicazioni, puoi creare servizi di rete Kubernetes privata, come NodePort, NLB e ALB Ingress privati. Puoi quindi utilizzare le politiche pre-DNAT Calico per bloccare il traffico verso le NodePort pubbliche dei servizi di rete privata. Per ulteriori informazioni, vedi Pianificazione del bilanciamento del carico esterno privato.

Traffico pubblico alle applicazioni cluster

Per rendere le tue app accessibili dall'esterno tramite Internet, puoi creare bilanciatori di carico di rete (NLB) pubblici NodePorts, e bilanciatori di carico delle applicazioni (ALB) Ingress. I servizi di rete pubblica si collegano a questa interfaccia di rete pubblica fornendo alla tua applicazione un indirizzo IP pubblico e, a seconda del servizio, un URL pubblico. Quando un'applicazione viene esposta pubblicamente, chiunque disponga dell'indirizzo IP del servizio pubblico o dell'URL che hai configurato per la tua applicazione può inviare una richiesta a tale applicazione. Puoi quindi utilizzare le politiche pre-DNAT Calico per controllare il traffico ai servizi di rete pubblica, come ad esempio consentendo il traffico solo da specifici CIDR o indirizzi IP di origine e bloccando tutto l'altro traffico. Per ulteriori informazioni, vedi Pianificazione del bilanciamento del carico esterno pubblico.

Per una maggiore sicurezza, è possibile isolare i carichi di lavoro di rete sui nodi worker periferici.

I nodi di lavoro edge possono migliorare la sicurezza del tuo cluster consentendo a un minor numero di nodi di lavoro connessi alle VLAN pubbliche di essere accessibili esternamente e isolando il carico di lavoro della rete. Quando etichetti i nodi di lavoro come nodi edge, i pod NLB e ALB vengono distribuiti solo su quei nodi di lavoro specificati. Inoltre, per impedire che altri carichi di lavoro vengano eseguiti sui nodi periferici, è possibile contrassegnare tali nodi come “tainted ”. Puoi quindi distribuire gli NLB e gli ALB sia pubblici che privati ai nodi edge. Ad esempio, se i tuoi nodi di lavoro sono connessi solo a una VLAN privata, ma hai bisogno di consentire l'accesso pubblico a un'applicazione nel tuo cluster, puoi creare un pool di lavoro edge in cui i nodi edge siano connessi alle VLAN pubbliche e private. Puoi distribuire gli NLB e gli ALB pubblici su questi nodi edge per garantire che solo quei nodi di lavoro gestiscano le connessioni pubbliche.

Comunicazione tra i nodi di lavoro nei cluster classici con carichi di lavoro che si affacciano su Internet

Per ottenere questa configurazione, crei un cluster connettendo i nodi di lavoro alle VLAN pubbliche e private.

Se si crea il cluster con VLAN sia pubbliche che private, in seguito non sarà possibile rimuovere tutte le VLAN pubbliche da quel cluster. In caso di rimozione di tutte le VLAN pubbliche da un cluster, diversi componenti cluster smettono di funzionare. Crea invece un nuovo pool di nodi di lavoro che sia connesso solo a una VLAN privata.

Comunicazione da operatore a master e da utente a master nei cluster classici con carichi di lavoro che si affacciano su Internet

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 pubblica.

• Endpoint dei servizi cloud pubblici e privati: il tuo account deve essere abilitato per VRF e per l'utilizzo degli endpoint dei servizi. La comunicazione tra i nodi di lavoro e il master avviene sia sulla rete privata, tramite l'endpoint del servizio cloud privato, sia sulla rete pubblica, tramite l'endpoint del servizio cloud pubblico. Il master è accessibile pubblicamente agli utenti autorizzati del cluster tramite l'endpoint del servizio cloud pubblico.
• Endpoint del servizio pubblico: se non si desidera o non è possibile abilitare il VRF per il proprio account, i nodi di lavoro e gli utenti autorizzati del cluster possono connettersi automaticamente al master di Kubernetes tramite la rete pubblica, utilizzando l'endpoint del servizio cloud pubblico.

Comunicazione dei lavoratori ad altri servizi o reti con carichi di lavoro connessi a Internet

I nodi di lavoro possono comunicare in modo automatico e sicuro con altri servizi IBM Cloud che supportano endpoint di servizi cloud privati attraverso la rete privata dell'infrastruttura IBM Cloud. Se un servizio di IBM Cloud non supporta gli endpoint dei servizi cloud privati, i worker possono comunicare in modo sicuro con i servizi tramite la rete pubblica. Puoi bloccare le interfacce pubbliche o private dei nodi di lavoro utilizzando le politiche di rete Calico per l'isolamento della rete pubblica o della rete privata. Potresti dover consentire l'accesso agli indirizzi IP pubblici e privati dei servizi che vuoi utilizzare in queste politiche di isolamento Calico.

Se i nodi worker devono accedere a servizi in reti private al di fuori dell'account IBM Cloud, vedere Impostazione della connettività di rete privata

Comunicazione esterna con le app in esecuzione sui nodi di lavoro con carichi di lavoro esposti a Internet

Per esporre un'applicazione nel tuo cluster a Internet, puoi creare un servizio NLB (network load balancer) o ALB (application load balancer) Ingress pubblico. Puoi migliorare la sicurezza del tuo cluster creando un pool di nodi di lavoro etichettati come nodi edge. I pod per i servizi di rete pubblica vengono distribuiti sui nodi edge in modo che i carichi di lavoro del traffico esterno siano isolati solo a pochi nodi di lavoro nel cluster. Puoi controllare ulteriormente il traffico pubblico verso i servizi di rete che espongono le tue applicazioni creando delle politiche pre-DNAT Calico, come le politiche di allowlist e blocklist.

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

Comunicazione tra i nodi di lavoro, tra i nodi di lavoro e tra i nodi di lavoro e tra utenti e nodi di lavoro con un'appliance gateway

Se i nodi di lavoro sono configurati esclusivamente su una VLAN privata e non si desidera o non è possibile abilitare il VRF per il proprio account, è necessario configurare un dispositivo gateway per garantire la connettività di rete tra i nodi di lavoro e il master tramite la rete pubblica. Ad esempio, è possibile scegliere di impostare una Virtual Router Appliance.

Puoi configurare la tua applicazione gateway con politiche di rete personalizzate per fornire la sicurezza di rete dedicata per il tuo cluster e per rilevare e risolvere intrusioni di rete. Quando configuri un firewall sulla rete pubblica, devi aprire le porte e gli indirizzi IP privati richiesti per ogni regione in modo che il master e i nodi di lavoro possano comunicare. Se configuri questo firewall anche per la rete privata, devi aprire anche le porte e gli indirizzi IP privati necessari per consentire le comunicazioni tra i nodi di lavoro e permettere al tuo cluster di accedere alle risorse dell'infrastruttura sulla rete privata. Devi inoltre abilitare lo spanning della VLAN per il tuo account in modo che le sottoreti possano essere instradate sulla stessa VLAN e su tutte le VLAN.

Comunicazione del nodo di lavoro con altri servizi o reti con un dispositivo gateway

Per collegare in modo sicuro i nodi worker e le app a una rete on-premise o a servizi esterni a IBM Cloud, vedere Impostazione della connettività di rete privata

I tuoi nodi di lavoro possono comunicare in modo sicuro con altri servizi IBM Cloud e servizi pubblici esterni a IBM Cloud tramite la tua applicazione gateway. Puoi configurare il tuo firewall per consentire l'accesso agli indirizzi IP pubblici e privati dei soli servizi che vuoi utilizzare

Comunicazione esterna con le applicazioni in esecuzione sui nodi di lavoro con un'appliance gateway

Per fornire l'accesso privato a un'applicazione nel tuo cluster, puoi creare un NLB (network load balancer) o un ALB (application load balancer) Ingress privato per esporre l'applicazione solo alla rete privata. Se hai bisogno di fornire un accesso pubblico limitato a un'applicazione nel tuo cluster, puoi creare un NLB o un ALB pubblico per esporre la tua applicazione. Poiché tutto il traffico passa attraverso il firewall della tua applicazione gateway, puoi controllare il traffico pubblico e privato verso i servizi di rete che espongono le tue applicazioni aprendo le porte e gli indirizzi IP del servizio nel tuo firewall per consentire il traffico in entrata verso questi servizi.

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

Comunicazione da nodo di lavoro a nodo di lavoro per cluster privati

Per ottenere questa configurazione, crei un cluster connettendo i nodi di lavoro solo a una VLAN privata. Per garantire la connettività tra il nodo master e i nodi worker del cluster sulla rete privata esclusivamente tramite l'endpoint del servizio cloud privato, è necessario che l'account sia abilitato alla funzione VRF e all'utilizzo degli endpoint di servizio. Poiché il tuo cluster è visibile a qualsiasi risorsa sulla rete privata quando VRF è abilitato, puoi isolare il tuo cluster da altri sistemi sulla rete privata applicando le politiche di rete privata Calico.

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. È possibile creare il cluster senza utilizzare le sottoreti fornite d IBM, specificando l'opzione --no-subnet. Dopo aver creato il cluster, puoi aggiungere sottoreti personalizzate al tuo cluster. 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 ks cluster create al momento della creazione del cluster.

Comunicazione da nodo di lavoro a master e da utente a master per cluster privati

È possibile accedere al master di Kubernetes tramite l'endpoint del servizio cloud privato se gli utenti autorizzati del cluster si trovano nella rete privata IBM Cloud o sono connessi alla rete privata, ad esempio tramite una connessione VPN classica o IBM Cloud Direct Link. Tuttavia, la comunicazione con il master di Kubernetes tramite l'endpoint del servizio cloud privato deve passare attraverso l'intervallo di indirizzi IP 166.X.X.X, che non è instradabile da una connessione VPN classica né tramite IBM Cloud Direct Link. È possibile rendere accessibile l'endpoint del servizio cloud privato del master agli utenti del cluster utilizzando un bilanciatore di carico di rete privata (NLB). La rete privata NLB espone l'endpoint del servizio cloud privato del master come un intervallo di indirizzi IP interno 10.X.X.X a cui gli utenti possono accedere tramite VPN o connessione IBM Cloud Direct Link. Se si abilita solo l'endpoint del servizio cloud privato, è possibile utilizzare la dashboard di Kubernetes oppure abilitare temporaneamente l'endpoint del servizio cloud pubblico per creare l'NLB privato.

Comunicazione del lavoratore ad altri servizi o reti per cluster privati

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, attraverso la rete privata dell'infrastruttura IBM Cloud. Ad esempio, gli ambienti hardware dedicati per tutte le istanze del piano standard di IBM Cloudant supportano gli endpoint dei servizi cloud privati. Se un servizio di IBM Cloud non supporta gli endpoint dei servizi cloud privati, il cluster non potrà accedere a tale servizio.

Comunicazione esterna con le applicazioni in esecuzione sui nodi di lavoro dei cluster privati

Per fornire l'accesso privato a un'applicazione nel tuo cluster, puoi creare un NLB (network load balancer) o un ALB (application load balancer) Ingress privato. Questi servizi di rete Kubernetes espongono la tua applicazione solo alla rete privata in modo che qualsiasi sistema in loco con una connessione alla sottorete su cui si trova l'IP NLB possa accedere all'applicazione.

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