Un gruppo di endpoint di rete (NEG) è un oggetto di configurazione che specifica un gruppo di endpoint o servizi di backend. I NEG di zona sono risorse a livello di zona che rappresentano raccolte di indirizzi IP o combinazioni di indirizzi IP/porta per le risorse Google Cloud all'interno di una singola subnet.
I NEG sono utili perché consentono di creare raggruppamenti logici di indirizzi IP e porte che rappresentano servizi software anziché intere VM. Gli indirizzi IP per i microservizi (in esecuzione nelle VM Google Cloud) gestiti da altri orchestratori come Apache Mesos o Cloud Foundry possono essere endpoint.
Per informazioni sugli altri tipi di NEG, consulta:
- Panoramica dei gruppi di endpoint di rete
- Panoramica dei gruppi di endpoint di rete Internet
- Panoramica dei gruppi di endpoint di rete serverless
Esistono due tipi di NEG di zona, a seconda del tipo di endpoint di rete che costituiscono il NEG. Ciascuno dei due tipi di NEG di zona supporta diversi casi d'uso e tipi di bilanciatore del carico.
- NEG GCE_VM_IP_PORT. Supportati come backend per bilanciatori del carico External HTTP(S), HTTP(S) interno, TCP e SSL proxy.
- NEG CE_VM_IP. Supportati come backend per bilanciatori del carico TCP/UDP interni.
Non puoi utilizzare NEG a livello di zona come backend con bilanciamento del carico di rete.
NEG GCE_VM_IP
Questi NEG di zona contengono uno o più endpoint di rete interni che si risolvono in un indirizzo IP principale di una VM di Compute Engine. Non puoi specificare una porta con questo tipo di NEG a livello di zona.
Questi endpoint possono essere utilizzati solo come backend nei servizi di backend per i bilanciatori del carico TCP/UDP interni.
Con i NEG GCE_VM_IP
puoi collegare solo endpoint che appartengono a un indirizzo IP interno principale di una VM nella rete VPC di NEG. È possibile aggiungere a un NEG gli indirizzi IP interni principali di qualsiasi NIC di una VM multi-NIC, purché il NEG utilizzi la stessa rete VPC del NIC.
NEG GCE_VM_IP_PORT
Questi NEG di zona contengono uno o più endpoint di rete interni che si riferiscono a un indirizzo IP interno principale di una VM o a un indirizzo IP in uno dei suoi intervalli IP alias. Ad esempio, GKE utilizza NEG di questo tipo, i cui endpoint sono un indirizzo IP dell'intervallo IP alias del nodo più una porta, ovvero un indirizzo del pod e una porta container. Ogni endpoint di rete viene specificato utilizzando una combinazione di indirizzo IP e porta.
Questi NEG possono essere utilizzati come backend nei servizi di backend per i bilanciatori del carico HTTP(S) esterni, HTTP(S) interni e proxy SSL. Non puoi utilizzare endpoint GCE_VM_IP_PORT
con bilanciatori del carico TCP/UDP interni o bilanciatori del carico di rete. Poiché questi backend NEG di zona
consentono di specificare gli indirizzi IP e le porte, puoi distribuire
il traffico in modo granulare tra le applicazioni o i container in esecuzione
all'interno delle istanze VM.
Per creare un endpoint di rete GCE_VM_IP_PORT
univoco per un container o un'applicazione in esecuzione in una VM, devi utilizzare l'indirizzo IP principale della VM o un IP secondario assegnato alla VM tramite la funzionalità indirizzo IP alias. Il software in esecuzione nel container o l'applicazione in esecuzione nella VM deve essere configurata per l'associazione all'indirizzo IP utilizzato dall'endpoint di rete.
I NEG di GCE_VM_IP_PORT
sono particolarmente utili per GKE.
Per informazioni sull'utilizzo dei NEG di zona con GKE, consulta la sezione
Utilizzo del bilanciamento del carico nativo del container.
Relazioni con gli endpoint
Quando crei un NEG, selezioni una zona, una rete e una subnet. Ogni indirizzo IP di endpoint deve trovarsi nella stessa subnet del NEG di zona.
Se la rete selezionata è una rete in modalità automatica, puoi omettere la subnet. Tuttavia, una subnet è ancora associata al NEG di zona. Se specifichi una rete in modalità automatica ma non specifichi una subnet durante la creazione di un NEG di zona, la subnet utilizzata è la subnet creata automaticamente nell'area geografica contenente la zona selezionata per il NEG di zona.
Il tipo di NEG di zona creato viene specificato al momento della creazione del NEG (GCE_VM_IP
o GCE_VM_IP_PORT
). Determina il tipo di endpoint supportato dal NEG.
Per i NEG di zona GCE_VM_IP
e GCE_VM_IP_PORT
:
Devi specificare il nome di ciascun endpoint VM.
Ogni VM dell'endpoint deve trovarsi nella stessa zona del NEG.
Ogni endpoint nel NEG deve essere una combinazione di indirizzo IP e porta univoca. È possibile fare riferimento a più combinazioni NEG di porte e indirizzi IP univoci.
Ogni VM di endpoint deve avere un'interfaccia di rete (NIC) nella stessa rete VPC del NEG. Gli indirizzi IP degli endpoint devono essere associati alla stessa subnet specificata nel NEG.
Ogni NEG supporta fino al numero massimo di endpoint per NEG. Gli endpoint possono essere distribuiti tra un numero elevato di VM uniche o tutte situate su una VM.
Per i NEG GCE_VM_IP_PORT
, quando aggiungi un endpoint puoi scegliere di specificare
un indirizzo IP e una porta, solo un indirizzo IP o nessuno dei due:
Se specifichi un indirizzo IP e una porta, l'indirizzo IP può essere l'indirizzo IP principale principale della VM NIC o l'IP alias del NIC. Il trasferimento è la tua scelta.
Se specifichi solo un indirizzo IP, l'indirizzo IP può essere l'indirizzo IP interno principale della VM NIC o un IP alias del NIC. La porta utilizzata è quella predefinita di NEG's.
Se ometti entrambi, Google Cloud seleziona l'indirizzo IP interno principale del NIC e utilizza la porta predefinita del NEG.
Bilanciamento del carico con NEG di zona
I NEG di zona possono essere utilizzati come backend per i servizi di backend in un bilanciatore del carico.
Quando utilizzi un NEG di zona come backend per un servizio di backend, tutti gli altri backend in quel servizio di backend devono essere anche NEG di zona dello stesso tipo (tutti GCE_VM_IP
o GCE_VM_IP_PORT
). Non puoi utilizzare i gruppi di istanze e i NEG di zona come backend nello stesso servizio di backend.
Puoi aggiungere lo stesso endpoint di rete a più di un NEG di zona. Puoi utilizzare lo stesso NEG di zona di un backend per più di un servizio di backend.
GCE_VM_IP_PORT
Il NEG di zona può utilizzare RATE
modalità di bilanciamento o CONNECTION
modalità di bilanciamento, a seconda del servizio di backend' I bilanciatori del carico supportati richiedono di definire una funzionalità di destinazione.
I NEG di zona GCE_VM_IP
devono utilizzare la modalità di bilanciamento del CONNECTION
e non puoi definire una capacità target perché i bilanciatori del carico TCP/UDP interni non supportano l'impostazione della capacità di destinazione.
Non puoi utilizzare una modalità di bilanciamento di UTILIZATION
per i backend NEG di zona.
Bilanciamento del carico TCP/UDP interno
I NEG di zona con endpoint GCE_VM_IP
possono essere utilizzati come backend per i servizi di backend solo per i bilanciatori del carico TCP/UDP interni.
I casi d'uso principali per i NEG con endpoint GCE_VM_IP
sono:
Gestione semplificata delle VM per i bilanciatori del carico TCP/UDP interni
Come per i gruppi di istanze, puoi utilizzare lo stesso NEG di un backend per più bilanciatori del carico TCP/UDP interni. A differenza dei gruppi di istanze, un endpoint VM può essere membro di più NEG e ciascuno di questi NEG può essere utilizzato come backend per uno o più bilanciatori del carico TCP/UDP interni.
Impostazione secondaria GKE
GKE utilizza i NEG di zona GCP_VM_IP
e l'impostazione secondaria per migliorare
la scalabilità dei bilanciatori del carico TCP/UDP interni nel modo seguente:
Senza impostazione secondaria, GKE crea un gruppo di istanze non gestite per zona, costituito dai nodi del cluster di tutti i pool di nodi in quella zona. Questi gruppi di istanze a livello di zona vengono utilizzati come backend per uno o più servizi LoadBalancer interni (e per le risorse Ingress esterne che non utilizzano i NEG stessi).
Con l'impostazione secondaria, GKE crea GCE_VM_IP
NEG di zona per ogni servizio LoadBalancer interno. Lo stesso endpoint può essere membro di più di un NEG di zona. A differenza dei gruppi di istanze, Google Cloud può bilanciare il carico su più NEG di zona che contengono lo stesso endpoint.
L'impostazione secondaria consente di distribuire il traffico in modo più efficiente ai servizi interni di LoadBalancer in cluster con più di 250 nodi. Ad esempio, un cluster GKE a 300 nodi potrebbe avere un servizio LoadBalancer interno con 25 nodi in un NEG, perché esistono 25 pod che gestiscono quel servizio. Non tutti i 300 nodi devono essere aggiunti a un backend di gruppo di istanze per questo servizio.
Tieni presente che rimangono valide le quote per NEG, regole di forwarding, servizi di backend e altre risorse di networking di Google Cloud.
Bilanciamento del carico HTTP(S), HTTP(S) interno, proxy TCP e SSL
I NEG di zona con endpoint GCE_VM_IP_PORT
possono essere utilizzati come backend per i servizi di backend nei seguenti tipi di bilanciatori del carico: HTTP(S) esterno, HTTP(S) interno, proxy TCP e bilanciamento del carico del proxy SSL.
Il caso d'uso principale per i NEG di zona a livello di NEG GCE_VM_IP_PORT
è il bilanciamento del carico nativo del container, che ti consente di distribuire il traffico direttamente nei container in esecuzione sulle VM, ad esempio negli indirizzi IP dei pod nei cluster GKE.
L'esempio seguente mostra come i bilanciatori del carico distribuiscono il traffico tra i microservizi in esecuzione nei container sulle tue VM. Le VM sono configurate per utilizzare gli intervalli IP alias dalle rispettive subnet, in quanto tali indirizzi sono gli indirizzi utilizzati dai container.
Le seguenti illustrazioni mostrano i componenti di configurazione per i bilanciatori del carico HTTP(S), i bilanciatori del carico proxy TCP/SSL e i bilanciatori del carico HTTP(S) interni in cui i NEG di zona sono i backend:
Ogni bilanciatore del carico HTTP(S), livello proxy e proxy TCP di livello Premium ha una propria regola di forwarding esterno globale per indirizzare il traffico all'oggetto proxy di destinazione appropriato.
Ogni bilanciatore del carico HTTP(S) del livello standard, del proxy SSL e del proxy TCP dispone di una regola di forwarding esterno a livello di area geografica per indirizzare il traffico all'oggetto proxy di destinazione appropriato.
Ogni bilanciatore del carico HTTP(S) interno dispone di una regola di forwarding interno gestito a livello di area geografica per indirizzare il traffico all'oggetto proxy di destinazione appropriato.
Per i proxy HTTP(S) di destinazione, il servizio di backend utilizzato viene determinato controllando il nome e il percorso dell'host della richiesta nella mappa URL. I bilanciatori del carico HTTP(S) esterno e interno possono avere più servizi di backend a cui fa riferimento la mappa URL.
Per i proxy TCP o SSL target, è possibile definire un solo servizio di backend.
Il servizio di backend indirizza il traffico ai suoi NEG a livello di zona di backend. Per ogni richiesta, il bilanciatore del carico sceglie un endpoint di rete da uno dei NEG di zona e invia il traffico lì.
Caso d'uso: bilanciamento del carico nativo del container
Il bilanciamento del carico nativo del container consente ai bilanciatori del carico di scegliere come target direttamente i pod e di prendere decisioni sulla distribuzione del carico a livello di pod anziché di VM. Esistono due modi per configurare il bilanciamento del carico nativo del container: utilizzare NEG gestiti da Ingress GKE o NEG autonomi.
In entrata di Kubernetes con NEG (consigliato)
Quando vengono utilizzati NEG con Ingress, il controller Ingress facilita la creazione di tutti gli aspetti del bilanciatore del carico di livello 7. Ciò include la creazione di indirizzi IP virtuali, regole di forwarding, controlli di integrità, regole del firewall e altro ancora. Per informazioni su come configurare questa funzionalità, consulta Bilanciamento del carico nativo del container tramite Ingress.
Ingress è il metodo consigliato per l'uso dei NEG per il bilanciamento del carico nativo del container, in quanto dispone di molte funzionalità che semplificano la gestione dei NEG. I NEG autonomi possono essere utilizzati se i NEG gestiti da Ingress non gestiscono il tuo caso d'uso.
Per istruzioni su come configurare un bilanciatore del carico tramite Ingress, consulta Bilanciamento del carico nativo del container tramite Ingress.
NEG NEG autonomi
Quando il deployment dei NEG di zona viene eseguito con bilanciatori del carico di cui non è stato eseguito il provisioning da parte di GKE Ingress, vengono considerati NEG autonomi. Il deployment dei NEG di zona autonomi viene eseguito e gestito tramite il controller NEG, mentre le regole di forwarding, i controlli di integrità e altri componenti del bilanciamento del carico vengono implementati manualmente.
Per esempi sull'utilizzo di NEG di zona autonomi con GKE, consulta:
- Collega un bilanciatore del carico HTTP(S) esterno a NEG di zona autonomi
- Collega un bilanciatore del carico HTTP(S) interno a NEG di zona autonomi
Limitazioni
- Non puoi utilizzare i NEG di zona con le reti precedenti.
- Un servizio di backend che utilizza i NEG come backend non può utilizzare i gruppi di istanze anche come backend.
Limitazioni per il NEG di zona GCE_VM_IP
:
- I NEG di zona con endpoint
GCE_VM_IP
sono supportati solo con bilanciatori del carico TCP/UDP interni. - La proprietà
default-port
non è supportata per i NEG di zonaGCE_VM_IP
. - Non puoi utilizzare Google Cloud Console per creare o gestire i NEG
GCE_VM_IP
. Utilizzagcloud
o l'API REST.
Quote
- Per informazioni sulle quote NEG, ad esempio NEG per progetto, NEG per servizio di backend ed endpoint per NEG, consulta la pagina delle quote di bilanciamento del carico.
Risolvere i problemi
Il traffico non raggiunge gli endpoint
Dopo la configurazione del servizio, in genere i nuovi endpoint diventano raggiungibili dopo essere stati associati al NEG di zona, a condizione che rispondano ai controlli di integrità.
Se il traffico non riesce a raggiungere gli endpoint, causando un codice di errore 502 per HTTP(s) o connessioni rifiutate per i bilanciatori del carico TCP/SSL, verifica quanto segue:
- Verifica che le regole firewall consentano il traffico TCP in entrata verso i tuoi endpoint dai seguenti intervalli:
130.211.0.0/22
e35.191.0.0/16
. - Verifica l'integrità degli endpoint utilizzando
gcloud
, come mostrato di seguito, o chiamando l'APIgetHealth
sulla risorsa di servizio di backend o l'APIlistEndpoints
sul NEG di zona con il parametroshowHealth
impostato suSHOW
. Il seguente comandogcloud
mostra informazioni sull'integrità in base all'endpoint di rete:
gcloud compute network-endpoint-groups list-network-endpoints NAME \ --zone=ZONE
Passaggi successivi
- Per informazioni sulla configurazione dei NEG di zona, consulta Configurazione dei gruppi di endpoint di rete di zona nel bilanciamento del carico.
- Per informazioni sull'utilizzo dei gruppi di endpoint di rete a livello di zona in Google Kubernetes Engine, consulta Utilizzo del bilanciamento del carico nativo del container.