Gestisci i bilanciatori del carico

Questa pagina di panoramica spiega come configurare i bilanciatori del carico interni ed esterni in Google Distributed Cloud (GDC) air-gapped per le configurazioni di rete zonali e globali.

Il bilanciamento del carico per GDC garantisce una distribuzione efficiente del traffico tra i carichi di lavoro di backend, migliorando la disponibilità e le prestazioni delle applicazioni. L'algoritmo utilizzato per distribuire il traffico è Maglev. Per ulteriori dettagli, consulta Algoritmo di bilanciamento del carico.

Questa pagina è destinata agli amministratori di rete del gruppo di amministratori della piattaforma o agli sviluppatori del gruppo di operatori delle applicazioni, che sono responsabili della gestione del traffico di rete per la loro organizzazione. Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC air-gapped.

Architettura di bilanciamento del carico

GDC fornisce bilanciatori del carico che consentono alle applicazioni di esporre i servizi l'uno all'altro. I bilanciatori del carico allocano un indirizzo IP virtuale (VIP) stabile che bilancia il traffico su un insieme di carichi di lavoro di backend. I bilanciatori del carico in GDC eseguono il bilanciamento del carico di livello 4 (L4), il che significa che mappano un insieme di porte TCP o UDP frontend configurate alle porte backend corrispondenti. I bilanciatori del carico sono configurati a livello di progetto.

I bilanciatori del carico sono configurati per i seguenti tipi di workload:

  • Carichi di lavoro in esecuzione sulle VM.
  • Carichi di lavoro containerizzati all'interno del cluster Kubernetes.

Esistono tre modi per configurare i bilanciatori del carico in GDC:

  • Utilizza l'API Networking Kubernetes Resource Model (KRM). Puoi utilizzare questa API per creare bilanciatori del carico globali o di zona.
  • Utilizza gcloud CLI. Puoi utilizzare questa API per creare bilanciatori del carico globali o di zona.
  • Utilizza il servizio Kubernetes direttamente dal cluster Kubernetes. Questo metodo crea solo bilanciatori del carico zonali.

Componenti del bilanciatore del carico

Quando utilizzi l'API KRM o gcloud CLI per configurare il bilanciatore del carico, utilizzi un bilanciatore del carico pass-through L4:

  • L4 indica che il protocollo è TCP o UDP.
  • Passthrough significa che non esiste un proxy tra il workload e il client.

Il bilanciatore del carico è costituito dai seguenti componenti configurabili:

  • Regole di forwarding: specificano il traffico inoltrato e a quale servizio di backend. Le regole di forwarding hanno le seguenti specifiche:

    • È composto da tre tuple, CIDR, porta e protocollo, a cui il client deve accedere.
    • Supporta i protocolli TCP e UDP.
    • Offre regole di forwarding interne ed esterne. I client possono accedere alle regole di forwarding interno dall'interno di Virtual Private Cloud (VPC). I client possono accedere alle regole di forwarding esterno dall'esterno della piattaforma GDC o dall'interno tramite i workload che hanno definito il valore EgressNAT.
    • Le regole di forwarding si connettono a un servizio di backend. Puoi indirizzare più regole di forwarding allo stesso servizio di backend.

  • Servizi di backend: sono l'hub di bilanciamento del carico che collega regole di forwarding, controlli di integrità e backend. Un servizio di backend fa riferimento a un oggetto di backend che identifica i carichi di lavoro a cui il bilanciatore del carico inoltra il traffico. Esistono limitazioni ai backend a cui un singolo servizio di backend può fare riferimento:

    • Una risorsa di backend zonale per zona.
    • Una risorsa di backend del cluster per cluster. Non può essere combinato con i backend del progetto.

  • Backend: un oggetto zonale che specifica gli endpoint che fungono da backend per i servizi di backend creati. Le risorse di backend devono essere limitate a una zona. Seleziona gli endpoint utilizzando le etichette. Limita l'ambito del selettore a un progetto o un cluster:

    • Un backend di progetto è un backend in cui non è specificato il campo ClusterName. In questo caso, le etichette specificate vengono applicate a tutti i carichi di lavoro nel progetto specifico, nel VPC specifico di una zona. Le etichette vengono applicate ai carichi di lavoro di VM e pod in più cluster. Quando un servizio di backend utilizza un backend di progetto, non puoi fare riferimento a un altro backend per quella zona nel servizio di backend.

    • Un backend cluster è un backend in cui è specificato il campo ClusterName. In questo caso, le etichette specificate si applicano a tutti i carichi di lavoro nel cluster denominato nel progetto specificato. Puoi specificare al massimo un backend per zona per cluster in un singolo servizio di backend.

  • Controlli di integrità: specifica i probe per determinare se un determinato endpoint del workload nel backend è integro. L'endpoint non integro viene rimosso dal bilanciatore del carico finché non torna integro. I controlli di integrità sono applicabili solo ai workload delle VM. I carichi di lavoro dei pod possono utilizzare il meccanismo di probe Kubernetes integrato per determinare se un endpoint specifico è integro. Per saperne di più, consulta la sezione Controlli di integrità.

Quando utilizzi il servizio Kubernetes direttamente dal cluster utente Kubernetes, utilizzi l'oggetto Service anziché i componenti elencati in precedenza. Puoi scegliere come target solo i carichi di lavoro nel cluster in cui viene creato l'oggetto Service.

Bilanciamento del carico esterno e interno

Le applicazioni GDC hanno accesso ai seguenti tipi di servizi di rete:

  • Bilanciatore del carico interno (ILB): consente di esporre un servizio ad altri cluster all'interno dell'organizzazione.
  • Bilanciatore del carico esterno (ELB): alloca un indirizzo IP virtuale (VIP) da un intervallo instradabile da carichi di lavoro esterni ed espone servizi al di fuori dell'organizzazione GDC, ad esempio altre organizzazioni all'interno o all'esterno dell'istanza GDC. Utilizza l'affinità sessione per i bilanciatori del carico elastici per assicurarti che le richieste di un client vengano instradate in modo coerente allo stesso backend.

Bilanciatori del carico globali e a livello di zona

Puoi creare bilanciatori del carico globali o zonali. L'ambito dei bilanciatori del carico globali si estende a un universo GDC. Ogni universo GDC può essere costituito da più zone GDC organizzate in regioni interconnesse e che condividono un control plane. Ad esempio, un universo composto da due regioni con tre zone ciascuna potrebbe essere simile a: us-virginia1-a, us-virginia1-b, us-virginia1-c e eu-ams1-a, eu-ams1-b, eu-ams1-c.

Lo scope dei bilanciatori del carico zonali è limitato alle zone specificate al momento della creazione. Ogni zona è un dominio di ripristino di emergenza indipendente. Una zona gestisce infrastruttura, servizi, API e strumenti che utilizzano un control plane locale.

Per saperne di più sulle risorse globali e di zona in un universo GDC, consulta Panoramica multizona.

Puoi creare bilanciatori del carico globali utilizzando i seguenti metodi:

Puoi creare bilanciatori del carico zonali utilizzando i seguenti metodi:

  • Utilizza l'API Networking Kubernetes Resource Model (KRM). Utilizza la versione dell'API networking.gdc.goog per creare risorse a livello di zona.
  • Utilizza gcloud CLI. Utilizza il flag --zone quando utilizzi i comandi gcloud CLI per specificare le zone in cui creare i bilanciatori del carico.
  • Utilizza Service Kubernetes direttamente dal cluster Kubernetes.

Indirizzi IP virtuali del servizio

I bilanciatori del carico interni allocano indirizzi VIP interni solo all'organizzazione. Questi indirizzi VIP non sono raggiungibili dall'esterno dell'organizzazione, pertanto puoi utilizzarli solo per esporre i servizi ad altre applicazioni all'interno di un'organizzazione. Questi indirizzi IP potrebbero sovrapporsi tra le organizzazioni nella stessa istanza.

D'altra parte, gli ELB allocano indirizzi VIP raggiungibili esternamente dall'esterno dell'organizzazione. Per questo motivo, gli indirizzi VIP ELB devono essere univoci in tutte le organizzazioni. In genere, sono disponibili meno indirizzi VIP ELB per l'utilizzo da parte dell'organizzazione.

Algoritmo di bilanciamento del carico

Il nostro bilanciatore del carico utilizza Maglev, un algoritmo di hashing coerente, per distribuire il traffico in entrata alle destinazioni di backend. Questo algoritmo è progettato per alte prestazioni e resilienza, garantendo che il traffico sia distribuito in modo uniforme e prevedibile, massimizzando al contempo la località dei dati nei backend.

Come funziona Maglev: il meccanismo di hashing

Maglev prende decisioni di inoltro eseguendo l'hashing delle proprietà di ogni pacchetto in entrata. In questo modo, tutti i pacchetti per una determinata connessione vengono inviati in modo coerente allo stesso backend per massimizzare la località dei dati.

  • Input hashing (5-tuple): l'algoritmo utilizza una 5-tuple standard dall'intestazione del pacchetto per generare un hash. Questa tupla è composta da:
    1. Indirizzo IP di origine
    2. Porta di origine
    3. Indirizzo IP di destinazione
    4. Porta di destinazione
    5. Protocollo (ad es. TCP, UDP)
  • Decisione di inoltro: il risultato di questo hash mappa in modo deterministico la connessione a uno dei backend integri nel pool di bilanciamento del carico. Per la durata della connessione, tutti i pacchetti verranno inoltrati allo stesso backend.
  • Entropia per il bilanciamento: utilizzando tutti e cinque gli elementi della tupla, Maglev genera entropia sufficiente per garantire che le diverse connessioni siano distribuite uniformemente su tutti i backend disponibili.

Gestione dell'integrità e degli errori del backend

Maglev è progettato per essere resiliente e ridurre al minimo le interruzioni quando cambia l'insieme di backend disponibili.

  • Errore di backend: quando un backend non supera i controlli di integrità, viene rimosso dall'elenco dei target disponibili. Le connessioni precedentemente instradate al backend non riuscito vengono terminate. Le nuove connessioni verranno ridistribuite automaticamente tra i backend integri rimanenti in base all'algoritmo di hashing. È importante sottolineare che le connessioni ad altri backend integri non vengono interessate o reindirizzate.
  • Recupero del backend: quando il backend non integro torna integro e viene aggiunto di nuovo al pool, la natura coerente dell'hash garantisce che questo backend venga aggiunto al pool con interruzioni minime e il bilanciatore del carico ribilancia il carico prendendo in considerazione questo backend appena integro. Questo approccio di "interruzione minima" impedisce un rimescolamento massiccio di tutte le connessioni esistenti, che altrimenti potrebbe sovraccaricare le cache o lo stato delle applicazioni.

Comportamento nei deployment multizona

È fondamentale capire che Maglev è indipendente dalla topologia. Distribuisce il traffico in base al risultato matematico dell'hash, senza considerare la posizione fisica o il percorso di rete ai backend.

  • Distribuzione uniforme indipendentemente dalla località: Maglev considera tutti i backend del pool come target uguali. Se hai backend distribuiti in zone diverse, il traffico verrà distribuito uniformemente tra tutti. L'algoritmo non preferisce i backend in una zona "locale" o non tiene conto della latenza di rete tra le zone.
  • Assicurati che la capacità di interconnessione multizona:poiché i backend possono estendersi su più zone, è essenziale che l'amministratore di rete si assicuri che l'interconnessione multizona abbia una capacità di rete sufficiente per gestire il traffico tra zone tra i nodi del bilanciatore del carico e i backend.

Limitazioni

  • La risorsa BackendService non deve essere configurata con una risorsa HealthCheck per i workload dei pod. HealthCheckName nella specifica BackendService è facoltativo e deve essere omesso quando configuri un bilanciatore del carico con i pod.

  • Una configurazione del bilanciatore del carico non può avere come target workload misti che coinvolgono pod e VM. Pertanto, i backend misti che coinvolgono pod e VM in una risorsa BackendService non sono consentiti.

  • Una risorsa personalizzata del bilanciatore del carico globale, ad esempio ForwardingRuleExternal, ForwardingRuleInternal, BackendService o HealthCheck, non deve avere lo stesso nome di queste risorse personalizzate del bilanciatore del carico zonale.

  • Un'organizzazione può definire un massimo di 500 regole di inoltro per zona in cui si trova. Le regole di forwarding globali vengono conteggiate ai fini di questo limite per tutte le zone.

Limitazioni per i cluster standard

Si applicano le seguenti limitazioni al bilanciamento del carico per i cluster standard:

Ambito di un singolo cluster

  • Ambito di un singolo cluster:qualsiasi bilanciatore del carico (ILB o ELB) di cui è stato eseguito il provisioning per un cluster standard che utilizza una risorsa Service type=LoadBalancer deve avere come target endpoint di backend che sono pod situati esclusivamente all'interno di quel singolo cluster standard. Non è supportata una singola definizione di bilanciatore del carico che tenti di distribuire il traffico ai pod in esecuzione su più cluster standard diversi o su un mix di cluster standard e cluster condivisi.

  • gcloud CLI e l'API Networking Kubernetes Resource Model non sono supportate per i cluster standard. Utilizza la risorsa Service Kubernetes standard con type=LoadBalancer e le annotazioni associate per gestire il bilanciamento del carico per i cluster standard.

  • I bilanciatori del carico con ambito progetto ignorano i cluster standard. Se una configurazione del bilanciatore del carico con ambito progetto viene creata utilizzando il comando gcloud CLI o l'API Networking Kubernetes Resource Model, ignorerà tutti i cluster standard nel progetto.

  • Il bilanciamento del carico globale non è supportato. Le risorse ILB ed ELB di cui è stato eseguito il provisioning per i cluster standard sono risorse di zona con ambito limitato a una singola zona. Il bilanciamento del carico globale non è supportato per i bilanciatori del carico del cluster standard.

  • Connettività ILB tra zone non supportata. La connettività da un pod cluster standard a un bilanciamento del carico interno globale o a un bilanciamento del carico interno zonale in una zona diversa non è supportata.

Passaggi successivi