Panoramica dei gruppi di endpoint di rete a livello di zona

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:

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.

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 RATEmodalità di bilanciamento o CONNECTIONmodalità 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.

Bilanciatori del carico TCP/UDP interni con NEG di zona 'GCE_VM_IP' sovrapposti
Bilanciatori del carico TCP/UDP interni con NEG di zona sovrapposti

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.

Bilanciamento del carico: gruppi di endpoint di rete di zona con container (fai clic per ingrandire)
Bilanciamento del carico dei gruppi di endpoint di rete con container (fai clic per ingrandire)

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ì.

Gruppi di endpoint di rete a livello di zona nel bilanciamento del carico (fai clic per ingrandire)
Gruppi di endpoint di rete zoologici nel bilanciamento del carico (clic per ingrandire)

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:

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 zona GCE_VM_IP.
  • Non puoi utilizzare Google Cloud Console per creare o gestire i NEG GCE_VM_IP. Utilizza gcloud o l'API REST.

Quote

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 e 35.191.0.0/16.
  • Verifica l'integrità degli endpoint utilizzando gcloud, come mostrato di seguito, o chiamando l'API getHealth sulla risorsa di servizio di backend o l'API listEndpoints sul NEG di zona con il parametro showHealth impostato su SHOW. Il seguente comando gcloud mostra informazioni sull'integrità in base all'endpoint di rete:
gcloud compute network-endpoint-groups list-network-endpoints NAME \
    --zone=ZONE

Passaggi successivi