GKE Ingress per i bilanciatori del carico delle applicazioni

Autopilot Standard

Questa pagina fornisce una panoramica generale di Google Kubernetes Engine (GKE) Ingress per i bilanciatori del carico delle applicazioni e spiega come il controller Ingress esegue il provisioning dei bilanciatori del carico delle applicazioni per esporre le applicazioni al traffico HTTP(S) dall'interno o dall'esterno della rete VPC.

Questa pagina funge da punto di accesso principale per comprendere il funzionamento di GKE Ingress. Per esaminare in modo più dettagliato l'architettura di rete sottostante, i pattern di routing del traffico e le implementazioni di sicurezza, consulta Informazioni sul routing e sulla sicurezza di GKE Ingress.

Questa pagina presuppone che tu conosca quanto segue:

Questa pagina è dedicata agli specialisti di networking che progettano e realizzano l'architettura di rete per la loro organizzazione e installano, configurano e supportano le apparecchiature di rete. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Panoramica

GKE fornisce un controller Ingress integrato e gestito chiamato GKE Ingress. Quando crei una risorsa Ingress in GKE, il controller configura automaticamente un bilanciatore del carico HTTPS che consente al traffico HTTP o HTTPS di raggiungere i tuoi servizi. Il controller Ingress configura il bilanciamento del carico e instrada il traffico alle applicazioni in esecuzione nel cluster in base alle regole specificate nel manifest Ingress e agli oggetti Service associati.

Un oggetto Ingress è associato a uno o più oggetti Service, che a loro volta sono associati a un insieme di pod. Per saperne di più su come Ingress espone le applicazioni utilizzando i servizi, consulta la panoramica del service networking.

Per utilizzare Ingress, devi abilitare il componente aggiuntivo per il bilanciamento del carico HTTP. I cluster GKE abilitano questo componente aggiuntivo per impostazione predefinita; non devi disattivarlo.

Differenza tra servizio Kubernetes e Google Cloud servizio di backend

L'oggetto servizio Kubernetes e l'oggetto servizio di backend Google Cloud hanno scopi simili ma distinti. Sebbene siano strettamente correlati, il rapporto non è sempre uno a uno.

Il controller GKE Ingress funge da traduttore tra questi due concetti. Quando crei una risorsa Ingress, il controller esegue il provisioning di un bilanciatore del caricoGoogle Cloud . Il controller crea quindi un servizio di backend Google Cloud dedicato per ogni combinazione univoca (service.name, service.port) a cui viene fatto riferimento nel manifest Ingress.

Ad esempio, un manifest Ingress potrebbe avere lo stesso nome del servizio Kubernetes, ma puntare a un service.port diverso per due regole host o path separate. In questo caso, il controller Ingress di GKE crea due servizi di backend separati. Pertanto, un oggetto servizio Kubernetes può essere correlato a diversi servizi di backend. Google Cloud

Ingress per il traffico esterno e interno

Esistono due tipi di risorse GKE Ingress:

Ingress per i bilanciatori del carico delle applicazioni esterni esegue il deployment del bilanciatore del carico delle applicazioni classico. Questo bilanciatore del carico accessibile da internet viene implementato a livello globale nella rete perimetrale di Google come pool gestito e scalabile di risorse di bilanciamento del carico. Scopri come configurare e utilizzare Ingress per i bilanciatori del carico delle applicazioni esterni.
Ingress per i bilanciatori del carico delle applicazioni interni esegue il deployment del bilanciatore del carico delle applicazioni interno. Questi bilanciatori del carico delle applicazioni interni sono basati su sistemi proxy Envoy al di fuori del tuo cluster GKE, ma all'interno della tua rete VPC. Scopri come configurare e utilizzare Ingress per i bilanciatori del carico delle applicazioni interni.

Importante: ogni volta che GKE crea un bilanciatore del carico delle applicazioni esterno o un bilanciatore del carico delle applicazioni interno tramite un oggetto Ingress, evita di modificare la configurazione del bilanciatore del carico utilizzando metodi esterni a GKE. Le personalizzazioni delle impostazioni per gli oggetti del bilanciatore del carico (regole di forwarding, proxy di destinazione, mappe URL, servizi di backend e controlli di integrità) vengono sovrascritte quando vengono applicate nuove modifiche alle risorse, durante le sincronizzazioni periodiche o durante gli upgrade del cluster. Se devi gestire un bilanciatore del carico delle applicazioni esterno o un bilanciatore del carico delle applicazioni interno al di fuori di GKE, utilizza il bilanciamento del carico nativo dei container per i gruppi di endpoint di rete (NEG) autonomi.

Ambiente di rete richiesto per i bilanciatori del carico delle applicazioni esterni

Il bilanciatore del carico delle applicazioni esterno è un sistema gestito e distribuito a livello globale che utilizza i proxy Google Front End (GFE) distribuiti nella rete perimetrale di Google. Questi proxy non si trovano all'interno della tua rete VPC. Quando un client invia una richiesta all'indirizzo IP esterno del bilanciatore del carico, la richiesta viene instradata utilizzando la rete anycast di Google al GFE più vicino. Il GFE termina il traffico utente (incluso TLS, se configurato) e poi lo inoltra ai pod di backend nel cluster GKE.

Affinché questo flusso funzioni, il controller GKE Ingress crea automaticamente regole firewall per consentire al traffico proveniente dai GFE e dai sistemi di controllo di integrità diGoogle Clouddi raggiungere i tuoi pod. Queste regole consentono il traffico dagli intervalli di indirizzi IP noti di Google (130.211.0.0/22 e 35.191.0.0/16).

Ecco come funziona il bilanciatore del carico delle applicazioni esterno:

Un client invia una richiesta all'indirizzo IP e alla porta della regola di forwarding del bilanciatore del carico.
La richiesta viene instradata a un proxy Google Front End (GFE) sulla rete globale di Google. Questo proxy termina la connessione di rete del client.
Il proxy GFE inoltra la richiesta all'endpoint del pod di backend appropriato nel cluster GKE, come determinato dalla mappa URL e dai servizi di backend del bilanciatore del carico.

A differenza del bilanciatore del carico delle applicazioni interno, non è necessario configurare una subnet solo proxy nella rete VPC per un bilanciatore del carico delle applicazioni esterno.

Ambiente di rete richiesto per i bilanciatori del carico delle applicazioni interni

Il bilanciatore del carico delle applicazioni interno fornisce un pool di proxy per la tua rete. I proxy valutano la destinazione di ogni richiesta HTTP(S) in base a fattori quali la mappa URL, l'affinità sessione di BackendService e la modalità di bilanciamento di ogni NEG di backend.

Un bilanciatore del carico delle applicazioni interno di una regione utilizza la subnet solo proxy per quella regione nella rete VPC per assegnare indirizzi IP interni a ogni proxy creato da Google Cloud.

Per impostazione predefinita, l'indirizzo IP assegnato alla regola di forwarding di un bilanciatore del carico proviene dall'intervallo di subnet del nodo assegnato da GKE anziché dalla subnet solo proxy. Puoi anche specificare manualmente un indirizzo IP per la regola di forwarding da qualsiasi subnet quando crei la regola.

Il seguente diagramma fornisce una panoramica del flusso di traffico per un bilanciatore del carico delle applicazioni interno, come descritto nel paragrafo precedente.

immagine

Ecco come funziona il bilanciatore del carico delle applicazioni interno:

Un client stabilisce una connessione all'indirizzo IP e alla porta della regola di forwarding del bilanciatore del carico.
Un proxy riceve e termina la connessione di rete del client.
Il proxy stabilisce una connessione all'endpoint (pod) appropriato in un NEG, come determinato dalla mappa URL e dai servizi di backend del bilanciatore del carico.

Ogni proxy è in ascolto sull'indirizzo IP e sulla porta specificati dalla regola di forwarding del bilanciatore del carico corrispondente. L'indirizzo IP di origine di ogni pacchetto inviato da un proxy a un endpoint è l'indirizzo IP interno assegnato a quel proxy dalla subnet solo proxy.

Comportamento del controller GKE Ingress

Se il controller Ingress di GKE elabora o meno un Ingress dipende dal valore dell'annotazione kubernetes.io/ingress.class:

Valore `kubernetes.io/ingress.class`	Valore `ingressClassName`	Comportamento del controller GKE Ingress
Non impostato	Non impostato	Elabora il manifest Ingress e crea un bilanciatore del carico delle applicazioni esterno.
Non impostato	Qualsiasi valore	Non intraprende alcuna azione. Il manifest Ingress può essere elaborato da un controller Ingress di terze parti, se ne è stato eseguito il deployment.
`gce`	Qualsiasi valore. Questo campo viene ignorato.	Elabora il manifest Ingress e crea un bilanciatore del carico delle applicazioni esterno.
`gce-internal`	Qualsiasi valore. Questo campo viene ignorato.	Elabora il manifest Ingress e crea un bilanciatore del carico delle applicazioni interno.
Imposta un valore diverso da `gce` o `gce-internal`	Qualsiasi valore	Non intraprende alcuna azione. Il manifest Ingress può essere elaborato da un controller Ingress di terze parti, se ne è stato eseguito il deployment.

`kubernetes.io/ingress.class` ritiro delle annotazioni

Sebbene l'annotazione kubernetes.io/ingress.class sia deprecata in Kubernetes, GKE continua a utilizzarla. Devi utilizzare questa annotazione per identificare la classe Ingress.

Quando applichi la configurazione, potresti visualizzare un avviso di ritiro. Questo avviso indica che l'annotazione è deprecata e ti invita a utilizzare il campo ingressClassName. Puoi ignorare l'avviso perché GKE Ingress continua a fare affidamento esclusivamente sull'annotazione kubernetes.io/ingress.class.

Mapping delle risorse di Compute Engine in entrata

Il controller Ingress di GKE esegue il deployment e la gestione delle risorse del bilanciatore del carico di Compute Engine in base alle risorse Ingress di cui è stato eseguito il deployment nel cluster. Il mapping delle risorse di Compute Engine dipende dalla struttura della risorsa Ingress.

Il seguente manifest descrive un Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Questo manifest Ingress indica a GKE di creare le seguenti risorse Compute Engine:

Una regola di forwarding e un indirizzo IP.
Regole firewall di Compute Engine che consentono il traffico per i controlli di integrità del bilanciamento del carico e il traffico delle applicazioni proveniente da Google Front End o dai proxy Envoy.
Un proxy HTTP di destinazione e un proxy HTTPS di destinazione, se hai configurato TLS.
Una mappa URL con una singola regola host che fa riferimento a un singolo matcher percorso. Il matcher percorso ha due regole percorso, una per /* e l'altra per /discounted. Ogni regola di percorso viene mappata a un servizio di backend univoco.
NEG che contengono un elenco di indirizzi IP dei pod di ogni servizio come endpoint. Questi vengono creati in seguito ai servizi my-discounted-products e my-products.

Metodi di bilanciamento del carico

GKE supporta il bilanciamento del carico nativo del container e i gruppi di istanze.

Bilanciamento del carico nativo del container

Il bilanciamento del carico nativo del container è la pratica di bilanciare il carico direttamente sugli endpoint dei pod in GKE. Il bilanciamento del carico nativo del container utilizza gruppi di endpoint di rete (NEG) di tipo GCE_VM_IP_PORT, in cui gli endpoint sono gli indirizzi IP dei pod.

Il bilanciamento del carico nativo del container viene sempre utilizzato per GKE Ingress interno ed è facoltativo per Ingress esterno. Il controller Ingress crea il bilanciatore del carico, inclusi l'indirizzo IP virtuale, le regole di forwarding, i controlli di integrità e le regole firewall.

Il bilanciamento del carico nativo del container supporta l'affinità di sessione basata sui pod.

GKE abilita automaticamente il bilanciamento del carico nativo del container quando sono soddisfatte tutte le seguenti condizioni:

Il cluster è nativo di VPC.
Il cluster non utilizza una rete VPC condiviso.
Il cluster non utilizza la policy di rete GKE.
Il cluster ha il componente aggiuntivo HttpLoadBalancing abilitato. I cluster GKE hanno l'addon HttpLoadBalancing abilitato per impostazione predefinita; non devi disabilitarlo.

Quando GKE abilita il bilanciamento del carico nativo del container, i servizi vengono annotati automaticamente con cloud.google.com/neg: '{"ingress": true}'. Questa annotazione attiva la creazione di un NEG che rispecchia gli IP dei pod, consentendo ai bilanciatori del carico di Compute Engine di comunicare direttamente con i pod.

Per i cluster in cui i NEG non sono l'impostazione predefinita, è comunque fortemente consigliato utilizzare il bilanciamento del carico nativo del container, ma deve essere attivato esplicitamente per ogni servizio.

Per una maggiore flessibilità, puoi anche creare NEG autonomi. In questo caso, sei responsabile della creazione e della gestione di tutti gli aspetti del bilanciatore del carico.

Vantaggi

Utilizzando i NEG, il bilanciamento del carico nativo del container offre una rete più stabile e con prestazioni migliori:

Prestazioni di rete migliorate: senza il bilanciamento del carico nativo del container, il traffico viene indirizzato ai gruppi di istanze di nodi e poi si basa sulle regole iptables configurate da kube-proxy per il routing al pod di destinazione. Con il bilanciamento del carico nativo del container, il traffico viene bilanciato del carico direttamente sui pod, evitando la necessità di instradare tramite l'IP della VM e il networking kube-proxy sul nodo. Questo flusso elimina gli hop di rete aggiuntivi e migliora la latenza e la velocità effettiva.

Controlli di integrità avanzati: i cancelli di preparazione dei pod vengono implementati per determinare l'integrità dei pod dal punto di vista del bilanciatore del carico, anziché basarsi esclusivamente sui probe di integrità nel cluster. Questa funzionalità critica consente al bilanciatore del carico di rilevare gli eventi del ciclo di vita dei pod (avvio, perdita e così via) e migliora la stabilità del traffico. Per scoprire di più su come vengono utilizzati i gate di prontezza dei pod per determinare l'integrità dei pod, consulta Prontezza dei pod.

Maggiore visibilità: con il bilanciamento del carico nativo del container, hai visibilità sulla latenza dall'Application Load Balancer direttamente a ogni pod. Poiché la latenza non viene più aggregata a livello di IP del nodo, la risoluzione dei problemi dei servizi a livello di NEG diventa più semplice.

Supporto di Cloud Service Mesh: il modello dei dati NEG è necessario per utilizzare Cloud Service Mesh, il control plane del traffico completamente gestito di Google Cloudper mesh di servizi.

Limitazioni dei bilanciatori del carico nativi del container

I bilanciatori del carico nativi del container tramite Ingress su GKE presentano le seguenti limitazioni:

I bilanciatori del carico nativi del container non supportano i bilanciatori del carico di rete passthrough esterni.
Non devi modificare o aggiornare manualmente la configurazione del bilanciatore del carico delle applicazioni creato da GKE. Tutte le modifiche apportate vengono sovrascritte da GKE.

Prezzi dei bilanciatori del carico nativi del container

Ti viene addebitato il costo del bilanciatore del carico delle applicazioni di cui viene eseguito il provisioning da Ingress che crei in questa guida. Per informazioni sui prezzi del bilanciatore del carico, consulta la sezione Bilanciamento del carico e regole di forwarding nella pagina dei prezzi di VPC.

Gruppi di istanze

Quando utilizzi i gruppi di istanze, i bilanciatori del carico Compute Engine inviano il traffico agli indirizzi IP delle VM come backend. Quando esegui container sulle VM, in cui i container condividono la stessa interfaccia host, si verificano le seguenti limitazioni:

Comporta due hop di bilanciamento del carico: un hop dal bilanciatore del carico alla VM NodePort e un altro hop tramite il routing kube-proxy agli indirizzi IP dei pod (che potrebbero risiedere su una VM diversa).
Gli hop aggiuntivi aumentano la latenza e rendono il percorso del traffico più complesso.
Il bilanciatore del carico Compute Engine non ha visibilità diretta sui pod, il che comporta un bilanciamento del traffico non ottimale.
Eventi ambientali come la perdita di VM o pod hanno maggiori probabilità di causare perdita di traffico intermittente a causa del doppio hop del traffico.

Ingress esterno e cluster basati su route

Se utilizzi cluster basati su route con Ingress esterno, il controller Ingress GKE non può utilizzare il bilanciamento del carico nativo del container utilizzando i gruppi di endpoint di rete (NEG) GCE_VM_IP_PORT. Il controller Ingress utilizza invece backend di gruppi di istanze non gestite che includono tutti i nodi in tutti i node pool. Se questi gruppi di istanze non gestite vengono utilizzati anche da LoadBalancer Services, possono causare problemi relativi alla limitazione di un singolo gruppo di istanze con bilanciamento del carico.

Alcuni oggetti Ingress esterni precedenti creati in cluster nativi del VPC potrebbero utilizzare backend di gruppi di istanze nei servizi di backend di ogni bilanciatore del carico delle applicazioni esterno creato. Questo non è pertinente a Ingress interno perché le risorse Ingress interno utilizzano sempre i NEG GCE_VM_IP_PORT e richiedono cluster VPC nativi.

Per scoprire come risolvere gli errori 502 con Ingress esterno, vedi Ingress esterno genera errori HTTP 502.

Limitazioni del controller GKE Ingress

GKE Ingress non supporta i certificati gestiti da Gestore certificati. Per utilizzare i certificati gestiti da Certificate Manager, utilizza l'API Gateway.
Nei cluster che utilizzano i NEG, il tempo di riconciliazione dell'ingresso può essere influenzato dal numero di ingressi. Ad esempio, un cluster con 20 ingressi, ognuno contenente 20 backend NEG distinti, potrebbe comportare una latenza superiore a 30 minuti per la riconciliazione di una modifica dell'ingresso. Ciò influisce in particolare sui cluster regionali a causa del maggior numero di NEG necessari.
Si applicano le quote per le mappe URL.
Si applicano le quote per le risorse Compute Engine.
Se non utilizzi i NEG con il controller in entrata GKE,i cluster GKE hanno un limite di 1000 nodi. Quando i servizi vengono implementati con i NEG, non esiste un limite per i nodi GKE. I servizi non NEG esposti tramite Ingress non funzionano correttamente sui cluster con più di 1000 nodi.
Affinché il controller Ingress di GKE utilizzi readinessProbes come controlli di integrità, i pod per un Ingress devono esistere al momento della creazione di Ingress. Se le repliche vengono scalate a 0, viene applicato il controllo di integrità predefinito. Per saperne di più, consulta questo commento al problema di GitHub sui controlli di integrità.
Le modifiche apportate al readinessProbe di un pod non influiscono sull'ingresso dopo la creazione.
Un bilanciatore del carico delle applicazioni esterno termina TLS in località distribuite a livello globale, per ridurre al minimo la latenza tra i client e il bilanciatore del carico. Se hai bisogno di un controllo geografico sul punto in cui viene terminato TLS, devi utilizzare un controller Ingress personalizzato esposto tramite un servizio GKE di tipo LoadBalancer e terminare TLS sui backend che si trovano in regioni adatte alle tue esigenze.
La combinazione di più risorse Ingress in un unico bilanciatore del carico Google Cloud non è supportata.
Devi disattivare mutual TLS sulla tua applicazione perché non è supportato per i bilanciatori del carico delle applicazioni esterni.
Ingress può esporre solo le porte HTTP 80 e 443 per il frontend.