IBM Cloud Docs
Classico: informazioni sugli NLB (network load balancer)

Classico: informazioni sugli NLB (network load balancer)

I bilanciatori di carico di rete possono essere creati solo nei cluster classici. Per bilanciare il carico nei cluster VPC, vedi Esposizione di applicazioni con i programmi di bilanciamento del carico per VPC.

Quando crei un cluster standard, IBM Cloud® Kubernetes Service esegue automaticamente il provisioning di una sottorete pubblica portatile e di una sottorete privata portatile.

  • La sottorete pubblica portatile fornisce 5 indirizzi IP utilizzabili. 1 indirizzo IP pubblico portatile viene utilizzato dall'ALB Ingress pubblico predefinito. I restanti 4 indirizzi IP pubblici portatili possono essere usati per esporre singole applicazioni su Internet creando servizi NLB (network load balancer).
  • La sottorete privata portatile fornisce 5 indirizzi IP utilizzabili. 1 indirizzo IP privato portatile viene utilizzato dal Ingress ALB privato predefinito. I restanti 4 indirizzi IP privati portatili possono essere usati per esporre le singole applicazioni su una rete privata creando servizi NLB (network load balancer) privati.

Per rendere accessibile un'applicazione tramite un indirizzo IP sia pubblico che privato portatile, devi creare un NLB pubblico e un NLB privato. Gli indirizzi IP pubblici e privati portatili sono IP fluttuanti statici e non cambiano quando un nodo di lavoro viene rimosso. Se il nodo di lavoro su cui si trova l'indirizzo IP NLB viene rimosso, un demone Keepalive che monitora costantemente l'IP sposta automaticamente l'IP su un altro nodo di lavoro. Puoi assegnare qualsiasi porta al tuo NLB. Il servizio NLB funge da punto di ingresso esterno per le richieste in entrata per l'applicazione. Per accedere all'NLB da Internet, è possibile utilizzare l'indirizzo IP pubblico dell'NLB e la porta assegnata nel formato <IP_address>:<port>. È anche possibile creare delle voci DNS per gli NLB registrando gli indirizzi IP NLB con i domini secondari.

Quando esponi un'applicazione con un servizio NLB, la tua applicazione viene automaticamente resa disponibile anche sulle NodePort del servizio. Le NodePort sono accessibili su ogni indirizzo IP pubblico e privato di ogni nodo di lavoro all'interno del cluster. Per bloccare il traffico alle NodePort mentre stai usando un NLB, vedi Controllo del traffico in entrata nei servizi NLB (network load balancer) o NodePort.

Sebbene il protocollo SCTP Kubernetes sia generalmente disponibile nella release della comunità Kubernetes, la creazione dei programmi di bilanciamento del carico che utilizzano questo protocollo non è supportata nei cluster IBM Cloud Kubernetes Service.

Confronto del bilanciamento del carico di base e DSR negli NLB versione 1.0 e 2.0

Quando crei un NLB, puoi scegliere un NLB versione 1.0, che esegue un bilanciamento del carico di base, oppure un NLB versione 2.0, che esegue un bilanciamento del carico DSR (direct server return).

In che cosa sono simili le versioni 1.0 e 2.0 NLB?
Gli NLB versione 1.0 e 2.0 sono entrambi programmi di bilanciamento del carico di livello 4 che esistono nello spazio del kernel Linux. Entrambe le versioni vengono eseguite all'interno del cluster e utilizzano le risorse del nodo di lavoro. Pertanto, la capacità disponibile degli NLB è sempre dedicata al tuo cluster. Inoltre, entrambe le versioni di NLB non interrompono la connessione. Al contrario, inoltrano le connessioni a un pod dell'applicazione.
In che cosa differiscono le versioni NLB ( 1.0 ) e NLB ( 2.0 )?
Quando un client invia una richiesta alla tua applicazione, l'NLB instrada i pacchetti della richiesta all'indirizzo IP del nodo di lavoro in cui è presente un pod dell'applicazione. Gli NLB versione 1.0 utilizzano la NAT (Network Address Translation) per riscrivere l'indirizzo IP di origine del pacchetto della richiesta sull'IP del nodo di lavoro in cui è presente un pod del programma di bilanciamento del carico. Quando il nodo di lavoro restituisce il pacchetto di risposta dell'applicazione, utilizza l'IP del nodo di lavoro in cui è presente l'NLB. L'NLB deve quindi inviare il pacchetto di risposta al client. Per evitare che l'indirizzo IP venga riscritto, puoi abilitare la conservazione dell'IP di origine. Tuttavia, la conservazione dell'IP di origine richiede che i pod del programma di bilanciamento del carico e i pod dell'applicazione vengano eseguiti sullo stesso nodo di lavoro in modo che la richiesta non debba essere inoltrata a un altro nodo di lavoro. Devi aggiungere l'affinità e le tolleranze del nodo ai pod dell'applicazione. Per ulteriori informazioni sul bilanciamento del carico di base con gli NLB versione 1.0, vedi Componenti e architettura di un NLB 1.0.

A differenza degli NLB versione 1.0, gli NLB versione 2.0 non utilizzano NAT durante l'inoltro delle richieste ai pod dell'applicazione su altri nodi di lavoro. Quando un NLB 2.0 instrada una richiesta del client, utilizza l'IPIP (IP over IP) per incapsulare il pacchetto della richiesta originale in un altro pacchetto. Questo pacchetto IPIP di incapsulamento ha un IP di origine del nodo di lavoro in cui si trova il pod del programma di bilanciamento del carico, che consente al pacchetto di richiesta originale di conservare l'IP del client come proprio indirizzo IP di origine. Il nodo di lavoro utilizza quindi il DSR (direct server return) per inviare il pacchetto di risposta dell'applicazione all'IP del client. Il pacchetto di risposta ignora l'NLB e viene inviato direttamente al client, riducendo la quantità di traffico che deve essere gestita dall'NLB. Per ulteriori informazioni sul bilanciamento del carico DSR con i NLB versione 2.0, vedere Componenti e architettura di un NLB 2.0.

Componenti e architettura di un NLB 1.0

L'NLB (network load balancer) TCP/UDP 1.0 utilizza Iptables, una funzione del kernel Linux, per bilanciare il carico delle richieste tra i pod di un'applicazione.

Flusso del traffico in un cluster a zona singola

Il seguente diagramma mostra in che modo un NLB 1.0 indirizza le comunicazioni da Internet a un'applicazione in un cluster a zona singola.

Esponi una applicazione in un cluster a zona singola utilizzando un NLB 1.0.
Expose an app in a single-zone cluster by using an NLB 1.0

  1. Una richiesta alla tua applicazione usa l'indirizzo IP pubblico del tuo NLB e la porta assegnata sul nodo di lavoro. Tieni presente che se crei un dominio secondario DNS per il tuo NLB, gli utenti possono invece accedere alla tua applicazione tramite il dominio secondario dell'NLB. Un servizio di sistema DNS risolve il dominio secondario nell'indirizzo IP pubblico portatile dell'NLB.

  2. L'NLB riceve la richiesta e la inoltra all'indirizzo IP privato del pod dell'applicazione sulla rete privata. L'indirizzo IP di origine del pacchetto di richieste viene modificato con l'indirizzo IP pubblico del nodo di lavoro su cui viene eseguito il pod NLB. Se nel cluster vengono distribuite più istanze dell'applicazione, il servizio NLB instrada le richieste tra i pod dell'applicazione.

  3. Quando l'applicazione restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo di lavoro in cui è presente l'NLB che ha inoltrato la richiesta client. L'NLB invia poi il pacchetto di risposta al client.

Flusso del traffico in un cluster multizona

Il seguente diagramma mostra in che modo un NLB (Network load balancer) 1.0 indirizza le comunicazioni da Internet a un'applicazione in un cluster multizona.

Utilizzare un NLB 1.0 per il bilanciamento del carico delle applicazioni in un
multizona*Utilizzare un NLB 1.0 per il bilanciamento del carico delle applicazioni in un cluster

  1. Una richiesta alla tua applicazione utilizza il dominio secondario DNS per i tuoi NLB. Puoi anche accedere all'NLB in ogni zona utilizzando la sua porta e il suo indirizzo IP pubblico sul nodo di lavoro. Tieni presente che, per impostazione predefinita, ciascun NLB 1.0 è configurato solo in una zona. Per ottenere l'alta disponibilità, devi distribuire un NLB 1.0 in ciascuna zona in cui hai istanze dell'applicazione.

  2. Un servizio di sistema DNS risolve il dominio secondario nell'indirizzo IP pubblico portatile di uno degli NLB e nella sua porta assegnata sul nodo di lavoro. Le richieste vengono gestite dagli NLB in varie zone in un ciclo round-robin.

  3. L'NLB riceve la richiesta e la inoltra all'indirizzo IP privato del pod dell'applicazione sulla rete privata. L'indirizzo IP di origine del pacchetto di richieste viene modificato con l'indirizzo IP pubblico del nodo di lavoro su cui viene eseguito il pod NLB. Ciascun NLB instrada le richieste alle istanze dell'applicazione nella propria zona e a quelle nelle altre zone. Inoltre, se vengono distribuite più istanze dell'applicazione in una zona, l'NLB instrada le richieste tra i pod dell'applicazione nella zona.

  4. Quando l'applicazione restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo di lavoro in cui è presente l'NLB che ha inoltrato la richiesta client. L'NLB invia poi il pacchetto di risposta al client.

Componenti e architettura di un NLB 2.0

L'NLB 2.0 è un programma di bilanciamento del carico di livello 4 che utilizza l'IPVS (IP Virtual Server) del kernel Linux. L'NLB 2.0 supporta TCP e UDP, viene eseguito per più nodi di lavoro e utilizza il tunneling IPIP (IP over IP) per distribuire il traffico che arriva a un singolo indirizzo IP dell'NLB tra quei nodi di lavoro.

Flusso del traffico in un cluster a zona singola

Il seguente diagramma mostra in che modo un NLB 2.0 indirizza le comunicazioni da Internet a un'applicazione in un cluster a zona singola.

Esporre un'applicazione in IBM Cloud Kubernetes Service utilizzando una versione 2.0
Esporre un'applicazione in IBM Cloud Kubernetes Service utilizzando una versione 2.0

  1. Una richiesta client alla tua applicazione usa l'indirizzo IP pubblico del tuo NLB e la porta assegnata sul nodo di lavoro. In questo esempio, l'NLB ha l'indirizzo IP virtuale 169.61.23.130 e viene eseguito sul nodo di lavoro che ha l'indirizzo IP privato 10.73.13.25. Tieni presente che se crei un dominio secondario DNS per il tuo NLB, gli utenti possono invece accedere alla tua applicazione tramite il dominio secondario dell'NLB. Un servizio di sistema DNS risolve il dominio secondario nell'indirizzo IP pubblico portatile dell'NLB.

  2. L'NLB incapsula il pacchetto della richiesta del client (etichettato come "CR" nell'immagine) all'interno di un pacchetto IPIP (etichettato come "IPIP"). Il pacchetto di richiesta del client mantiene l'IP del client come proprio indirizzo IP di origine. Il pacchetto di incapsulamento IPIP utilizza l'IP 10.73.14.25 del nodo di lavoro come proprio indirizzo IP di origine.

  3. L'NLB instrada il pacchetto IPIP a un nodo di lavoro su cui si trova un pod dell'applicazione e che ha l'indirizzo IP privato 10.73.13.26. Se nel cluster vengono distribuite più istanze dell'applicazione, l'NLB instrada le richieste tra i nodi di lavoro in cui sono distribuiti i pod dell'applicazione.

  4. Il nodo di lavoro 10.73.14.26 decomprime il pacchetto di incapsulamento IPIP e quindi decomprime il pacchetto di richiesta del client. Il pacchetto di richiesta del client viene inoltrato al pod dell'applicazione su quel nodo di lavoro.

  5. Il nodo di lavoro 10.73.14.26 utilizza quindi l'indirizzo IP di origine dal pacchetto di richiesta originale, l'IP del client, per restituire il pacchetto di risposta del pod dell'applicazione direttamente al client.

Flusso del traffico in un cluster multizona

Il seguente diagramma mostra in che modo gli NLB versione 2.0 indirizzano in ciascuna zona il traffico da Internet a un'applicazione in un cluster multizona.

Expose an app in IBM Cloud Kubernetes Service by using an NLB 2.0
Expose an app in IBM Cloud Kubernetes Service by using an NLB 2.0

  1. Una richiesta alla tua applicazione utilizza il dominio secondario DNS per i tuoi NLB. Puoi anche accedere all'NLB in ogni zona utilizzando la sua porta e il suo indirizzo IP pubblico sul nodo di lavoro. Tieni presente che, per impostazione predefinita, ciascun NLB 2.0 è configurato solo in una zona. Per ottenere l'alta disponibilità, devi distribuire un NLB 2.0 in ciascuna zona in cui hai istanze dell'applicazione.

  2. Un servizio di sistema DNS risolve il dominio secondario nell'indirizzo IP pubblico portatile di uno degli NLB e nella sua porta assegnata sul nodo di lavoro. In questo esempio, l'NLB ha l'indirizzo IP virtuale 169.61.23.130 e viene eseguito sul nodo di lavoro che ha l'indirizzo IP privato 10.73.13.25. Le richieste vengono gestite dagli NLB in varie zone in un ciclo round-robin.

  3. L'NLB incapsula il pacchetto della richiesta del client (etichettato come "CR" nell'immagine) all'interno di un pacchetto IPIP (etichettato come "IPIP"). Il pacchetto di richiesta del client mantiene l'IP del client come proprio indirizzo IP di origine. Il pacchetto di incapsulamento IPIP utilizza l'IP 10.73.14.25 del nodo di lavoro come proprio indirizzo IP di origine.

  4. L'NLB instrada il pacchetto IPIP a un nodo di lavoro su cui si trova un pod dell'applicazione e che ha l'indirizzo IP privato 10.73.13.26. Tieni presente che ciascun NLB instrada le richieste alle istanze dell'applicazione nella propria zona e a quelle nelle altre zone. Inoltre, se vengono distribuite più istanze dell'applicazione in una zona, l'NLB instrada le richieste tra i pod dell'applicazione nella zona.

  5. Il nodo di lavoro 10.73.14.26 decomprime il pacchetto di incapsulamento IPIP e quindi decomprime il pacchetto di richiesta del client. Il pacchetto di richiesta del client viene inoltrato al pod dell'applicazione su quel nodo di lavoro.

  6. Il nodo di lavoro 10.73.14.26 utilizza quindi l'indirizzo IP di origine dal pacchetto di richiesta originale, l'IP del client, per restituire il pacchetto di risposta del pod dell'applicazione direttamente al client.