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 workload di backend, migliorando la disponibilità e le prestazioni delle applicazioni.
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 ulteriori informazioni, 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 zonali.
- Utilizza 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 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 il servizio di backend a cui viene inoltrato. 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 carichi di lavoro con 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.
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 di zona 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 del progetto è un backend in cui non è specificato il campo
ClusterName
. In questo caso, le etichette specificate vengono applicate a tutti i workload 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 in stato non integro viene rimosso dal bilanciatore del carico finché non torna in stato integro. I controlli di integrità si applicano 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.
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 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 gli ELB per garantire che le richieste di un client vengano indirizzate 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 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 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:
- Utilizza l'API Networking Kubernetes Resource Model (KRM). Utilizza la versione dell'API
networking.global.gdc.goog
per creare risorse globali. - Utilizza gcloud CLI.
Utilizza il flag
--global
quando utilizzi i comandi gcloud CLI per specificare un ambito globale.
Puoi creare bilanciatori del carico a livello di zona utilizzando i seguenti metodi:
- Utilizza l'API Networking Kubernetes Resource Model (KRM). Utilizza la versione
networking.gdc.goog
dell'API 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 il servizio 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 servizi ad altre applicazioni all'interno di un'organizzazione. Questi indirizzi IP possono 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.
Limitazioni
La risorsa
BackendService
non deve essere configurata con una risorsaHealthCheck
per i workload dei pod. Tieni presente cheHealthCheckName
nella specificaBackendService
è 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 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 (
ForwardingRuleExternal
,ForwardingRuleInternal
,BackendService
oHealthCheck
) non deve avere lo stesso nome di queste risorse personalizzate del bilanciatore del carico zonale.Passaggi successivi