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 configurazioni di rete sia zonali che 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 maggiori dettagli, consulta Algoritmo di bilanciamento del carico.

Questa pagina è rivolta agli amministratori di rete del gruppo di amministratori della piattaforma o agli sviluppatori del gruppo di operatori delle applicazioni, responsabili della gestione del traffico di rete per la loro organizzazione. Per ulteriori informazioni, consulta Pubblici per la documentazione di GDC con air gap.

Architettura di bilanciamento del carico

GDC fornisce bilanciatori del carico che consentono alle applicazioni di esporre i servizi l'una all'altra. 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 di backend corrispondenti. I bilanciatori del carico sono configurati a livello di progetto.

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

  • 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 zonali.
  • Utilizza il gcloud CLI. Puoi utilizzare questa API per creare bilanciatori del carico globali o zonali.
  • 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 la CLI gdcloud per configurare il bilanciatore del carico, utilizzi un bilanciatore del carico pass-through L4:

  • L4 significa che il protocollo è TCP o UDP.
  • Pass-through significa che non esiste un proxy tra il carico di lavoro e il client.

Il bilanciatore del carico è costituito dai seguenti componenti configurabili:

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

    • Consiste di tre tuple, CIDR, porta e protocollo, per l'accesso del client.
    • Supporta i protocolli TCP e UDP.
    • Offre regole di forwarding interne ed esterne. I client possono accedere alle regole di forwarding interne dall'interno di Virtual Private Cloud (VPC). I client possono accedere alle regole di forwarding esterne dall'esterno della piattaforma GDC o dall'interno dei carichi di lavoro con il valore EgressNAT definito.
    • Le regole di forwarding si connettono a un servizio di backend. Puoi indirizzare più regole di forwarding allo stesso servizio di backend.

  • I 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 sui 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 combinata 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 il selettore a un progetto o a un cluster:

    • Un backend di progetto è un backend che non ha il campo ClusterName specificato. In questo caso, le etichette specificate si applicano 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 in quel servizio di backend.

    • Un backend del cluster è un backend con il campo ClusterName specificato. 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à: specificano i probe per determinare se un determinato endpoint del carico di lavoro 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 carichi di lavoro delle VM. I carichi di lavoro dei pod possono utilizzare il meccanismo di probe Kubernetes integrato per determinare se un endpoint specifico è integro. Per ulteriori informazioni, consulta i 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 i servizi all'esterno dell'organizzazione GDC, ad esempio altre organizzazioni all'interno o all'esterno dell'istanza GDC. Utilizza l'affinità sessione per gli ELB per assicurarti che le richieste di un client vengano sempre indirizzate allo stesso backend.

Bilanciatori del carico globali e zonali

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 costituito da due regioni con tre zone ciascuna potrebbe avere il seguente aspetto: us-virginia1-a, us-virginia1-b, us-virginia1-c e eu-ams1-a, eu-ams1-b, eu-ams1-c.

L'ambito dei bilanciatori del carico zonali è limitato alle zone specificate al momento della creazione. Ogni zona è un dominio di emergenza indipendente. Una zona gestisce l'infrastruttura, i servizi, le API e gli strumenti che utilizzano un control plane locale.

Per ulteriori informazioni sulle risorse globali e zonali 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 zonali.
  • Utilizza il gcloud CLI. Utilizza il flag --zone quando utilizzi i comandi gcloud CLI per specificare le zone per cui creare i bilanciatori del carico.
  • Utilizza il Service Kubernetes direttamente dal cluster Kubernetes.

Indirizzi IP virtuali del servizio

Gli ILB 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 tra 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 prestazioni e resilienza elevate, garantendo che il traffico venga 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 forwarding 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 di hashing (5-tuple): l'algoritmo utilizza una 5-tuple standard da l'intestazione del pacchetto per generare un hash. Questa tupla è costituita 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 forwarding: 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 vengano distribuite in modo uniforme 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 l'insieme di backend disponibili cambia.

  • Errore del backend: quando un backend non supera i controlli di integrità, viene rimosso dall'elenco delle destinazioni disponibili. Le connessioni che in precedenza erano indirizzate 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 ribilancerà il carico prendendo questo backend appena integro. Questo approccio di "interruzione minima" impedisce una riorganizzazione massiccia 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 dei backend.

  • Distribuzione uniforme indipendentemente dalla località: Maglev tratta tutti i backend nel suo pool come destinazioni uguali. Se hai backend distribuiti su zone diverse, il traffico verrà distribuito in modo uniforme tra tutti. L'algoritmo non preferisce i backend in una zona "locale" o tiene conto della latenza di rete tra le zone.
  • Garantisci 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 carichi di lavoro dei pod. HealthCheckName nella specifica BackendService è facoltativo e deve essere omesso quando si configura un bilanciatore del carico con i pod.

  • Una configurazione del bilanciatore del carico non può scegliere come target carichi di lavoro 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 forwarding per zona in cui risiede. Le regole di forwarding globali vengono conteggiate in questo limite per tutte le zone.

Limitazioni per i cluster standard

Le seguenti limitazioni si applicano 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 utilizzando una risorsa Service type=LoadBalancer deve scegliere come target gli endpoint di backend che sono pod che si trovano esclusivamente all'interno di quel singolo cluster standard. Non è supportata una singola definizione del bilanciatore del carico che tenti di distribuire il traffico ai pod in esecuzione su più cluster standard diversi o su una combinazione di cluster standard e cluster condivisi.

  • La gcloud CLI e l'API Networking Kubernetes Resource Model non sono supportati 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 viene creata una configurazione del bilanciatore del carico con ambito progetto utilizzando il comando gcloud CLI o l'API Networking Kubernetes Resource Model, verranno ignorati 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 zonali con ambito limitato a una singola zona. Il bilanciamento del carico globale non è supportato per i bilanciatori del carico dei cluster standard.

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

Passaggi successivi