Load balancing in Kubernetes: le 5 opzioni tecniche, con esempi pratici

Che cos'è il load balancing in Kubernetes?

Il load balancing in Kubernetes è il processo automatizzato di distribuzione del traffico di rete su più Pod, con l'obiettivo di garantire alta disponibilità, scalabilità e prestazioni ottimali. Opera su due livelli principali: la gestione interna al cluster e l'esposizione esterna verso gli utenti.

Astraendo la complessità del routing e della distribuzione delle richieste, Kubernetes consente agli sviluppatori di distribuire applicazioni scalabili senza dover gestire manualmente la ripartizione del traffico. Questa automazione è essenziale per assicurare alta disponibilità, tolleranza ai guasti e prestazioni nei moderni ambienti containerizzati.

Le opzioni tecniche per implementare il load balancing in Kubernetes:

• ClusterIP (interno): utilizza un IP virtuale per distribuire il traffico tra i Pod all'interno del cluster, ed è l'opzione predefinita per la comunicazione interna tra servizi.
• NodePort: espone un Service su una porta statica su ogni nodo del cluster, consentendo ai client esterni di accedere alle applicazioni tramite <NodeIP>:<NodePort>.
• LoadBalancer: si integra con i load balancer del cloud o dell'infrastruttura per fornire un indirizzo IP esterno che distribuisce il traffico tra i nodi del cluster e i Pod di backend.
• Ingress: offre routing HTTP/HTTPS a livello 7, permettendo a più Service di condividere un unico endpoint esterno con regole di routing basate su host e percorso.
• Gateway API: utilizza risorse dedicate di tipo Gateway e Route per una gestione del traffico avanzata e basata su policy, con supporto per più protocolli e separazione tra team.

Questo articolo fa parte di una serie dedicata allo scheduling in Kubernetes.

Perché il load balancing è necessario in Kubernetes

Gli ambienti Kubernetes sono dinamici. I pod possono essere creati, terminati, ripianificati o scalati in qualsiasi momento in base alla domanda applicativa o alle condizioni del cluster. Senza load balancing, il traffico potrebbe continuare a fluire verso pod sovraccarichi o non disponibili, causando risposte lente, richieste fallite o downtime.

Il load balancing aiuta Kubernetes a mantenere prestazioni e disponibilità applicative costanti. Distribuisce le richieste tra i pod integri e reindirizza il traffico in caso di guasti. In questo modo le applicazioni continuano a servire gli utenti durante crash dei pod, rolling update o cambiamenti infrastrutturali.

I motivi principali per cui il load balancing è necessario in Kubernetes:

• Evitare il sovraccarico di traffico su un singolo pod o nodo
• Supportare lo scaling orizzontale distribuendo le richieste tra le repliche
• Mantenere l'alta disponibilità durante i guasti di pod o nodi
• Consentire deployment e rolling update senza downtime
• Migliorare i tempi di risposta e l'affidabilità delle applicazioni
• Semplificare il routing del traffico in ambienti container dinamici
• Permettere ai servizi di scalare automaticamente al variare del traffico

Poiché i container sono effimeri e i workloads cambiano di continuo, il load balancing automatizzato è un requisito fondamentale per un funzionamento stabile di Kubernetes.

5 modi per implementare il load balancing in Kubernetes

1. ClusterIP (interno)

ClusterIP è il tipo di Service predefinito di Kubernetes. Crea un indirizzo IP virtuale raggiungibile solo dall'interno del cluster, il che lo rende adatto alla comunicazione tra servizi interni come workloads di front-end, API e database. I client esterni non possono accedere direttamente a un servizio ClusterIP, il che aiuta a isolare i servizi di backend dalle reti pubbliche.

Quando una richiesta viene inviata all'indirizzo ClusterIP, kube-proxy intercetta il traffico e lo inoltra a uno dei Pod integri dietro il Service. Le regole di routing vengono aggiornate automaticamente quando i Pod vengono aggiunti, rimossi o sostituiti, garantendo la distribuzione delle richieste tra le repliche disponibili senza che le applicazioni debbano tenere traccia degli indirizzi IP dei Pod.

La decisione di bilanciamento si basa tipicamente su iptables, IPVS o implementazioni di rete basate su eBPF, a seconda della configurazione del cluster. Le applicazioni comunicano con un endpoint di Service stabile mentre Kubernetes gestisce le variazioni dei Pod sottostanti: per questo ClusterIP è la base della maggior parte della comunicazione interna tra servizi.

2. NodePort

Un Service di tipo NodePort espone un'applicazione su una porta statica su ogni nodo del cluster Kubernetes. I client possono accedere all'applicazione inviando richieste a <NodeIP>:<NodePort>, consentendo al traffico esterno di raggiungere i workloads senza bisogno di un load balancer cloud dedicato.

Quando il traffico arriva a un nodo, kube-proxy instrada la richiesta verso uno dei Pod selezionati dal Service, anche se quel Pod è in esecuzione su un nodo diverso. Kubernetes continua a bilanciare le richieste tra i Pod integri al variare del numero di repliche, mentre la NodePort rimane invariata.

Poiché ogni nodo è in ascolto sulla stessa porta, gli utenti possono connettersi a qualsiasi nodo del cluster e raggiungere l'applicazione. NodePort è utilizzato comunemente in ambienti di sviluppo, in cluster on-premises o come base per servizi di livello superiore come LoadBalancer, anche se esporre le applicazioni direttamente tramite NodePort è meno comune in produzione.

3. LoadBalancer

Un Service di tipo LoadBalancer si basa su NodePort e integra Kubernetes con un load balancer esterno fornito da una piattaforma cloud o da un'infrastruttura supportata. Effettua il provisioning di un indirizzo IP pubblico o privato che i client utilizzano per accedere all'applicazione senza connettersi direttamente ai singoli nodi del cluster.

Il load balancer esterno distribuisce le connessioni in ingresso tra i nodi del cluster. Le richieste vengono poi inoltrate tramite il corrispondente Service NodePort, dove kube-proxy seleziona un Pod di backend integro. Si ottiene così un load balancing sia a livello di infrastruttura, tra i nodi, sia a livello di Kubernetes, tra i Pod.

La maggior parte dei servizi Kubernetes gestiti effettua automaticamente il provisioning di load balancer cloud-native di provider come AWS, Azure o Google Cloud alla creazione di questo tipo di Service. Gli health check assicurano che il traffico venga inviato solo ai nodi integri, mentre Kubernetes aggiorna costantemente gli endpoint di backend quando i Pod scalano o vengono sostituiti.

4. Ingress

Ingress fornisce routing a livello 7 (HTTP/HTTPS) per più applicazioni attraverso un unico punto di ingresso. Invece di esporre ogni Service con un proprio indirizzo IP esterno, una risorsa Ingress definisce regole di routing basate su hostname, percorsi URL o altri attributi HTTP. Un Ingress controller, come Traefik, implementa queste regole.

Quando un client invia una richiesta HTTP o HTTPS, l'Ingress controller valuta le regole di routing e inoltra la richiesta al Service Kubernetes appropriato. Il Service distribuisce poi il traffico tra i suoi Pod di backend. Questo approccio semplifica l'esposizione delle applicazioni e supporta funzionalità come terminazione TLS, redirect, autenticazione e riscrittura delle richieste.

Poiché più Service possono condividere lo stesso endpoint esterno, Ingress riduce il numero di indirizzi IP pubblici e di load balancer necessari. È utilizzato comunemente per esporre applicazioni web, API e microservizi, offrendo al contempo una gestione centralizzata del traffico HTTP e HTTPS.

5. Gateway API

Gateway API è uno standard di rete più recente di Kubernetes che offre un modo più flessibile ed estensibile di gestire il traffico applicativo. Separa la configurazione dell'infrastruttura dal routing applicativo, consentendo ai team di piattaforma di gestire i gateway mentre i team applicativi definiscono come i loro servizi ricevono il traffico.

Il traffico entra prima in un Gateway, che rappresenta il punto di ingresso di rete. Le risorse di routing, come HTTPRoute, specificano come le richieste devono essere abbinate e inoltrate ai Service Kubernetes. Una volta che una richiesta raggiunge il Service selezionato, Kubernetes la distribuisce tra i Pod disponibili utilizzando i suoi meccanismi standard di load balancing.

Rispetto a Ingress, Gateway API offre un controllo più granulare su policy di routing, traffic splitting e ambienti multi-tenant. Supporta inoltre più protocolli oltre a HTTP, tra cui TCP e gRPC, risultando più adatto a requisiti di rete complessi e a deployment Kubernetes su larga scala.

LoadBalancer vs. Ingress vs. API Gateway in Kubernetes

La tabella seguente riassume le differenze tra queste opzioni:

Casi d'uso del load balancing in Kubernetes

Load balancing interno tra servizi

Il load balancing interno tra servizi distribuisce il traffico tra le applicazioni in esecuzione all'interno dello stesso cluster Kubernetes. Consente ai servizi di comunicare tramite endpoint stabili mentre Kubernetes instrada automaticamente le richieste verso i pod disponibili. Questo approccio aiuta a mantenere prestazioni e disponibilità quando i workloads scalano o i pod vengono sostituiti.

Tecnologie rilevanti: Kubernetes Service (ClusterIP), kube-proxy, networking basato su eBPF, service mesh, service discovery basata su DNS.

Load balancing esterno

Il load balancing esterno gestisce il traffico che entra nel cluster da utenti, applicazioni o sistemi esterni. Fornisce un punto di ingresso pubblico e distribuisce le richieste in arrivo tra i servizi di backend integri. In questo modo le applicazioni possono gestire volumi di traffico più elevati rimanendo disponibili durante guasti, interventi di manutenzione o operazioni di scaling.

Tecnologie rilevanti: Service di tipo LoadBalancer, load balancer di livello 4, Ingress, Gateway API, terminazione TLS.

Gestione del traffico north-south

La gestione del traffico north-south riguarda il traffico tra i client esterni e i workloads in esecuzione all'interno del cluster. È utilizzata comunemente per applicazioni rivolte al pubblico, API e integrazioni con partner. Oltre al load balancing, include spesso routing, applicazione di policy di sicurezza, filtraggio del traffico e crittografia per controllare come le richieste esterne accedono ai servizi interni.

Tecnologie rilevanti: Ingress, Gateway API, routing di livello 7, terminazione TLS, policy di autenticazione e autorizzazione, integrazione con web application firewall.

Gestione del traffico east-west

La gestione del traffico east-west si concentra sulla comunicazione tra servizi all'interno del cluster o tra ambienti Kubernetes connessi. Nelle architetture a microservizi le applicazioni si scambiano richieste internamente con grande frequenza, rendendo una distribuzione efficiente del traffico critica per prestazioni e affidabilità. Questo tipo di load balancing supporta anche osservabilità, policy di sicurezza e controllo del traffico tra i servizi.

Tecnologie rilevanti: Kubernetes Service, kube-proxy, service mesh, networking basato su eBPF, mTLS, policy di traffico, service discovery.

Load balancing multi-cluster e globale

Il load balancing multi-cluster e globale distribuisce il traffico su più cluster Kubernetes situati in regioni, zone di disponibilità, cloud provider o data center diversi. Migliora la resilienza evitando che un singolo cluster diventi un punto di guasto e può ridurre la latenza indirizzando gli utenti verso la posizione più appropriata. È utilizzato comunemente per disaster recovery, applicazioni globali e deployment su larga scala.

Tecnologie rilevanti: Gateway API, load balancing globale, routing del traffico basato su DNS, networking multi-cluster, service mesh, failover del traffico, geo-routing.

Esempi di load balancing in Kubernetes

Gli esempi di questa sezione sono adattati dalla documentazione di Kubernetes.

Esempio di Service Kubernetes

Il seguente Deployment crea tre repliche di un'applicazione NGINX. Ogni Pod è etichettato con app: nginx, il che consente a un Service Kubernetes di selezionare i Pod e inviare loro il traffico.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10

Questo Deployment mantiene in esecuzione tre Pod NGINX. Se un Pod viene eliminato o va in errore, il ReplicaSet del Deployment ne crea uno sostitutivo. La readiness probe aiuta Kubernetes a determinare quando ciascun Pod è pronto a ricevere traffico tramite un Service.

Esempio di Service ClusterIP

Il seguente Service ClusterIP espone il Deployment NGINX all'interno del cluster. Il Service seleziona i Pod con l'etichetta app: nginx e inoltra il traffico dalla porta 80 del Service alla porta 80 dei Pod selezionati.

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Questo Service è raggiungibile dall'interno del cluster. Gli altri Pod possono raggiungerlo utilizzando il nome del Service nginx-clusterip, a condizione che il DNS del cluster sia disponibile.

Esempio di Service LoadBalancer

Il seguente Service espone gli stessi Pod NGINX verso l'esterno utilizzando un cloud provider o un altro ambiente che supporti load balancer esterni.

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Quando questo Service viene creato in un ambiente supportato, Kubernetes effettua il provisioning o configura un load balancer esterno e registra l'indirizzo esterno nello stato del Service. Il traffico inviato all'indirizzo esterno viene inoltrato al Service e quindi ai Pod di backend corrispondenti.

Esempio di Ingress

Il seguente Ingress instrada il traffico HTTP per example.com verso il Service interno nginx-clusterip.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-clusterip
                port:
                  number: 80

Questo Ingress definisce regole di routing HTTP, ma funziona solo se nel cluster è in esecuzione un Ingress controller. È l'Ingress controller a implementare il comportamento di routing e a inoltrare le richieste corrispondenti al Service di backend.

Esempio di API Gateway

L'esempio seguente utilizza la Gateway API di Kubernetes per instradare il traffico HTTP attraverso un Gateway verso il Service interno nginx-clusterip. Gateway API è una famiglia di API di rete di Kubernetes per il provisioning dinamico dell'infrastruttura e il routing avanzato del traffico; le risorse HTTPRoute possono abbinare le richieste HTTP e inoltrarle ai Service Kubernetes.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: api.example.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-api-route
spec:
  parentRefs:
    - name: nginx-gateway
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: nginx-clusterip
          port: 80

In questo esempio, il Gateway rappresenta il punto di ingresso dell'API gateway, mentre la risorsa HTTPRoute definisce come devono essere instradate le richieste HTTP. Le richieste inviate a api.example.com/api vengono accettate dal listener del Gateway, abbinate dalla route e inoltrate al Service nginx-clusterip. Il Service distribuisce quindi il traffico tra i Pod NGINX corrispondenti.

Nota: questo esempio utilizza NGINX Gateway Fabric come implementazione della gateway class, che è distinta dal controller Ingress NGINX mantenuto dalla community.

Questo approccio è simile a Ingress, ma Gateway API offre un modello più espressivo e orientato ai ruoli. I team infrastrutturali possono gestire le risorse Gateway, mentre i team applicativi possono gestire le risorse di routing come HTTPRoute. Ciò lo rende utile per i pattern di API gateway in cui i team hanno bisogno di routing basato su hostname, routing basato su percorso, controllo delle policy di traffico e una separazione più netta tra configurazione della piattaforma e routing applicativo.