Descrizione del bilanciamento del carico per le applicazioni tramite rilevamento dei servizi Kubernetes

Il rilevamento dei servizi Kubernetes fornisce alle applicazioni una connessione di rete attraverso servizi di rete e un proxy Kubernetes locale.

A tutti i pod che vengono distribuiti in un nodo di lavoro viene assegnato un indirizzo IP privato nell'intervallo 172.30.0.0/16 e vengono instradati solo tra i nodi di lavoro. Per evitare conflitti, non utilizzare questo intervallo IP su qualsiasi nodo che comunica con i tuoi nodi di lavoro. I nodi di lavoro e i pod possono comunicare in modo protetto sulla rete privata utilizzando indirizzi IP privati. Tuttavia, quando si verifica un arresto anomalo di un pod o quando occorre creare nuovamente un nodo di lavoro, viene assegnato un nuovo indirizzo IP privato.

Invece di cercare di tenere traccia di indirizzi IP privati mutevoli per applicazioni che devono essere ad alta disponibilità, puoi utilizzare le funzioni di rilevamento dei servizi Kubernetes integrate per esporre le applicazioni come servizi. Un servizio Kubernetes raggruppa un insieme di pod e fornisce una connessione di rete a questi pod. Il servizio seleziona i pod di destinazione a cui instrada il traffico tramite etichette.

Un servizio fornisce la connettività tra i pod delle tue applicazioni e altri servizi del cluster, senza esporre l'effettivo indirizzo IP privato di ciascun pod. Ai servizi viene assegnato un indirizzo IP interno al cluster, il clusterIP, accessibile solo all'interno del cluster. Questo indirizzo IP è collegato al servizio per tutta la sua durata e non viene modificato finché esiste il servizio. Ai servizi viene assegnato un IP da uno dei 65.000 IP nell'intervallo 172.21.0.0/16.

Per evitare conflitti, non utilizzare questo intervallo IP su qualsiasi nodo che comunica con i tuoi nodi di lavoro. Viene creata anche una voce di ricerca DNS per il servizio e viene memorizzata nel componente kube-dns del cluster. La voce DNS contiene il nome del servizio, lo spazio dei nomi in cui è stato creato il servizio e il link all'indirizzo IP in cluster assegnato.

Se si intende connettere il cluster a reti locali tramite IBM Cloud o un servizio VPN, potrebbero verificarsi conflitti di sottorete con l'intervallo predefinito 172.30.0.0/16 per i pod e l'intervallo 172.21.0.0/16 per i servizi. È possibile evitare conflitti tra sottoreti durante la creazione di un cluster 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 ".

Per fornire un bilanciamento di base del carico di tutto il traffico di rete di TCP e UDP per i servizi, un proxy di rete locale Kubernetes, kube-proxy, viene eseguito come demone su ogni nodo worker nello spazio dei nomi kube-system. kube-proxy utilizza le regole Iptables, una caratteristica del kernel Linux, per indirizzare le richieste al pod dietro un servizio in modo uguale, indipendentemente dagli indirizzi IP dei pod all'interno del cluster e dal nodo worker su cui sono distribuiti.

Ad esempio, le applicazioni del cluster possono accedere a un pod sottostante un servizio cluster utilizzando l'indirizzo IP in cluster del servizio o inviando una richiesta a nome del servizio. Quando utilizzi il nome del servizio, kube-proxy ricerca il nome nel provider DNS del cluster e instrada la richiesta all'indirizzo IP in cluster del servizio.

Se si utilizza un servizio che fornisce sia un indirizzo IP del cluster interno che un indirizzo IP esterno, i client esterni al cluster possono inviare richieste all'indirizzo IP pubblico o privato esterno del servizio. kube-proxy inoltra le richieste all'indirizzo IP nel cluster del servizio e bilancia il carico tra i pod dell'applicazione dietro il servizio.

Descrizione dei tipi di servizio Kubernetes

Kubernetes supporta quattro tipi fondamentali di servizi di rete: ClusterIP, NodePort, LoadBalancer, e Ingress. I servizi ClusterIP rendono le applicazioni accessibili internamente per consentire la comunicazione solo tra i pod del cluster. NodePort i servizi LoadBalancer e Ingress rendono le applicazioni accessibili esternamente da Internet o da una rete privata.

La seguente tabella confronta le funzioni di ciascun tipo di servizio di rete.

* Un certificato SSL per il bilanciamento del carico HTTPS è fornito dai comandi ibmcloud ks nlb-dns. Nei cluster classici, questi comandi sono supportati solo per gli NLB pubblici.

NodePort

Quando si rendono accessibili le app con un NodePort servizio, al servizio viene assegnato un NodePort compreso nell'intervallo 30000 - 32767 e un indirizzo IP interno del cluster. Per accedere al servizio dall'esterno del cluster, occorre utilizzare l'indirizzo IP pubblico o privato di un qualsiasi nodo di lavoro e l' NodePort, nel formato <IP_address>:<nodeport>. Tuttavia, gli indirizzi IP pubblici e privati del nodo di rete non sono permanenti. Quando un nodo di lavoro viene rimosso o ricreato, vengono assegnati al nodo di lavoro un nuovo indirizzo IP pubblico e uno nuovo privato.

Le NodePort sono ideali per testare l'accesso pubblico o privato o fornire l'accesso solo per un breve periodo di tempo. Nota: poiché i nodi di lavoro nei cluster VPC non dispongono di un indirizzo IP pubblico, è possibile accedere a un'applicazione tramite un' NodePort a solo se si è connessi alla propria rete VPC privata, ad esempio tramite una connessione VPN.

LoadBalancer

Il tipo di servizio LoadBalancer viene implementato in modo diverso a seconda del fornitore dell'infrastruttura del tuo cluster.

Servizi LoadBalancer in cluster Classic

Infrastrutture classiche

NLB(Network load balancer). Ogni cluster standard viene fornito con quattro indirizzi IP pubblici portatili e quattro indirizzi IP privati portatili che puoi utilizzare per creare un NLB (network load balancer) TCP/UDP di livello 4 per la tua applicazione. Puoi personalizzare il tuo NLB esponendo una qualsiasi porta richiesta dalla tua applicazione. Gli indirizzi IP pubblici e privati portabili assegnati all'NLB sono permanenti e non cambiano quando un nodo di lavoro viene ricreato nel cluster. Puoi creare un dominio secondario per la tua applicazione che registra gli indirizzi IP dell'NLB pubblici con una voce DNS. Puoi anche abilitare monitoraggi del controllo dell'integrità sugli IP dell'NLB per ciascun dominio secondario.

Servizi LoadBalancer nei cluster VPC

Cloud privato virtuale

Load Balancer per VPC. Quando crei un servizio LoadBalancer Kubernetes per un'applicazione nel tuo cluster, un programma di bilanciamento del carico VPC di livello 7 viene creato automaticamente nel tuo VPC fuori dal tuo 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 impostazione predefinita, il programma di bilanciamento del carico viene creato anche con un nome host che puoi utilizzare per accedere alla tua applicazione.

Ingress

Rendere accessibili più applicazioni in un cluster configurando il routing tramite il bilanciatore di carico delle applicazioni (ALB) Ingress. L'ALB usa un punto di ingresso pubblico o privato protetto e univoco, un dominio secondario Ingress, per instradare le richieste in entrata alle tue applicazioni. Puoi usare un dominio secondario per esporre più applicazioni nel tuo cluster come servizi. Ingress è composto da tre componenti:

• La risorsa Ingress definisce le regole su come instradare e bilanciare il carico delle richieste in entrata per un'applicazione.
• L'ALB ascolta le richieste di servizio HTTP, HTTPS o TCP in entrata. Inoltra le richieste tra i pod delle applicazioni in base alle regole che hai definito nella risorsa Ingress.
• L'MZLB (multizone load balancer) per i cluster classici o il programma di bilanciamento del carico VPC per i cluster VPC gestisce tutte le richieste in entrata alle tue applicazioni e bilancia il carico delle richieste tra gli ALB nelle diverse zone. Abilita anche i controlli dell'integrità per gli indirizzi IP Ingress pubblici.

Pianificazione del bilanciamento del carico esterno pubblico

Esponi pubblicamente un'applicazione nel tuo cluster su Internet.

Nei cluster classici, puoi connettere i nodi di lavoro a una VLAN pubblica. La VLAN pubblica determina l'indirizzo IP pubblico che viene assegnato a ciascun nodo di lavoro, che fornisce a ciascun nodo di lavoro un'interfaccia di rete pubblica. I servizi di rete pubblica si collegano a questa interfaccia di rete pubblica fornendo alla tua applicazione un indirizzo IP pubblico e, facoltativamente, un URL pubblico.

Nei cluster VPC, i tuoi nodi di lavoro sono connessi solo alle sottoreti VPC private. Tuttavia, quando crei i servizi di rete pubblici, viene creato automaticamente un programma di bilanciamento del carico VPC. Il programma di bilanciamento del carico VPC può instradare le richieste pubbliche alla tua applicazione fornendo alla tua applicazione un URL pubblico. Quando un'applicazione è esposta pubblicamente, chiunque abbia l'URL pubblico può inviare una richiesta alla tua applicazione.

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. Per questo motivo, esponi meno applicazioni possibile. Esponi un'applicazione al pubblico solo quando la tua applicazione è pronta ad accettare il traffico da utenti o client web esterni.

L'interfaccia di rete pubblica per i nodi di rete è protetta dalle impostazioni della politica di rete Calico predefinite configurate su ogni nodo di lavoro durante la creazione del cluster. Per impostazione predefinita, tutto il traffico di rete in uscita è consentito per tutti i nodi di lavoro. Il traffico di rete in entrata è bloccato, fatta eccezione per alcune porte. Queste porte sono aperte in modo che IBM possa monitorare il traffico di rete e installare automaticamente gli aggiornamenti di sicurezza per il master Kubernetes e per poter stabilire le connessioni ai servizi NodePort, LoadBalancer e Ingress. Per ulteriori informazioni su queste politiche, incluso su come modificarle, vedi Politiche di rete.

Scelta di un modello di distribuzione per i cluster classici

Per rendere un'app accessibile pubblicamente su Internet in un cluster classico, scegli un modello di distribuzione con bilanciamento del carico che utilizzi servizi pubblici di tipo " NodePort, ", " LoadBalancer, " o "Ingress". La seguente tabella descrive ogni possibile modello di distribuzione, i motivi per cui potresti utilizzarlo e come configurarlo. Per le informazioni di base sui servizi di rete utilizzati da questi modelli di distribuzione, vedi Descrizione dei tipi di servizio Kubernetes.

Scelta di un modello di distribuzione per i cluster VPC

Per rendere un'app pubblicamente accessibile su Internet in un cluster VPC, scegliere un modello di distribuzione con bilanciamento del carico che utilizzi i servizi pubblici LoadBalancer o Ingress. La seguente tabella descrive ogni possibile modello di distribuzione, i motivi per cui potresti utilizzarlo e come configurarlo. Per le informazioni di base sui servizi di rete utilizzati da questi modelli di distribuzione, vedi Descrizione dei tipi di servizio Kubernetes.

Pianificazione del bilanciamento del carico esterno privato

Esponi privatamente un'applicazione del tuo cluster solo sulla rete privata.

Quando distribuisci un'applicazione in un cluster Kubernetes in IBM Cloud Kubernetes Service, potresti voler rendere l'applicazione accessibile solo agli utenti e ai servizi che si trovano sulla stessa rete privata del tuo 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.

Ad esempio, poni di aver creato un programma di bilanciamento privato per la tua applicazione. A questo programma di bilanciamento del carico privato possono accedere:

• Qualsiasi pod dello stesso cluster.
• Qualsiasi pod in qualsiasi cluster dello stesso account IBM Cloud.
• Se non sei nell'account IBM Cloud ma ancora dietro il firewall aziendale, qualsiasi sistema tramite una connessione VPN alla sottorete su cui si trova l'IP del programma di bilanciamento del carico.
• Se sei in un account IBM Cloud differente, qualsiasi sistema tramite una connessione VPN alla sottorete su cui si trova l'IP del programma di bilanciamento del carico.
• In un account classico, se hai lo spanning della VLAN o VRF abilitati, qualsiasi sistema connesso a una qualsiasi delle VLAN private nello stesso account IBM Cloud.
• Nei cluster VPC:
  • Se si autorizza il traffico tra le sottoreti della VPC, qualsiasi sistema all’interno della stessa VPC.
  • Se si autorizza il traffico tra VPC, qualsiasi sistema che abbia accesso alla VPC in cui si trova il cluster.