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 è il 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 le seguenti informazioni:

Questa pagina è rivolta agli specialisti di Networking che progettano e realizzano l'architettura di rete per la propria organizzazione e installano, configurano e supportano le apparecchiature di rete. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, 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 bilanciatore del carico e instrada il traffico alle applicazioni in esecuzione nel cluster in base alle regole specificate nel manifest Ingress e negli 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 Panoramica del networking dei servizi.

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

Differenza tra il servizio Kubernetes e il servizio di backend Google Cloud

L'oggetto Service Kubernetes e l'oggetto Google Cloud servizio di backend hanno scopi simili ma distinti Sebbene siano strettamente correlati, la relazione 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 Google Cloud bilanciatore del carico. Il controller crea quindi un servizio di backend dedicato Google Cloud per ogni combinazione univoca (service.name, service.port) a cui viene fatto riferimento nel Ingress manifest.

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

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 con accesso a internet viene sottoposto a deployment 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 cluster GKE, ma all'interno della 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 invece il bilanciamento del carico nativo del 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) sottoposti a deployment nella rete perimetrale di Google. Questi proxy non si trovano all'interno della 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 Google Cloud's sistemi di controllo di integrità di raggiungere i tuoi pod. Queste regole consentono il traffico proveniente 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 del servizio di backend e la modalità di bilanciamento di ogni NEG di backend.

Il 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 GKE Ingress elabora o meno un Ingress dipende dal valore dell'annotazione kubernetes.io/ingress.class:

Valore di `kubernetes.io/ingress.class`	Valore di `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 interviene. Il manifest Ingress potrebbe 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.
Impostato su un valore diverso da `gce` o `gce-internal`	Qualsiasi valore	Non interviene. Il manifest Ingress potrebbe essere elaborato da un controller Ingress di terze parti, se ne è stato eseguito il deployment.

Deprecazione dell'annotazione `kubernetes.io/ingress.class`

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

Quando applichi la configurazione, potresti visualizzare un avviso di deprecazione. 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 di Ingress alle risorse di Compute Engine

Il controller GKE Ingress esegue il deployment e gestisce le risorse del bilanciatore del carico di Compute Engine in base alle risorse Ingress sottoposte a 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 di 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 bilanciatore del carico e il traffico delle applicazioni da Google Front End o 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 un'altra per /discounted. Ogni regola percorso esegue il mapping 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 i 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 vengono 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 il componente aggiuntivo 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 vivamente consigliato di utilizzare il bilanciamento del carico nativo del container, ma deve essere abilitato in modo esplicito 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 un networking più efficiente e stabile:

Prestazioni di rete migliorate: senza il bilanciamento del carico nativo del container, il traffico viene indirizzato ai gruppi di istanze dei 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 direttamente sui pod, evitando la necessità di eseguire il routing 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à migliorati: I gate 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à in-cluster. Questa funzionalità fondamentale consente al bilanciatore del carico di conoscere gli eventi del ciclo di vita dei pod (avvio, perdita e così via) e migliora la stabilità del traffico. Per saperne di più su come vengono utilizzati i gate di preparazione dei pod per determinare l'integrità dei pod, consulta Preparazione dei pod.

Maggiore visibilità: con il bilanciamento del carico nativo del container, hai visibilità sulla latenza dal bilanciatore del carico delle applicazioni 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 per Cloud Service Mesh: il modello dei dati NEG è necessario per utilizzare Cloud Service Mesh, Google Cloudil piano di controllo del traffico completamente gestito per il 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. Le modifiche apportate vengono sovrascritte da GKE.

Prezzi dei bilanciatori del carico nativi del container

Ti vengono addebitati i costi per il bilanciatore del carico delle applicazioni di cui è stato eseguito il provisioning da Ingress creato in questa guida. Per informazioni sui prezzi del bilanciatore del carico, consulta Bilanciamento del carico e regole di forwarding nella pagina dei prezzi di Cloud Load Balancing.

Gruppi di istanze

Quando utilizzi i gruppi di istanze, i bilanciatori del carico di 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:

Si verificano due hop di bilanciamento del carico: un hop dal bilanciatore del carico al NodePort della VM 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 più complesso il percorso del traffico.
Il bilanciatore del carico di Compute Engine non ha visibilità diretta sui pod, il che comporta un bilanciamento del traffico non ottimale.
Gli eventi ambientali come la perdita di VM o pod hanno maggiori probabilità di causare una perdita di traffico intermittente a causa del doppio hop di traffico.

Ingress esterno e cluster basati su route

Se utilizzi cluster basati su route con Ingress esterno, il controller GKE Ingress 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 i backend dei gruppi di istanze non gestite che includono tutti i nodi in tutti i pool di nodi. Se questi gruppi di istanze non gestite vengono utilizzati anche dai LoadBalancer servizi, possono verificarsi problemi relativi alla limitazione di un singolo gruppo di istanze con bilanciamento del carico.

Alcuni oggetti Ingress esterni precedenti creati in cluster nativi di VPC potrebbero utilizzare i backend dei 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 interne utilizzano sempre i NEG GCE_VM_IP_PORT e richiedono cluster nativi di VPC.

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

Limitazioni del controller GKE Ingress

GKE Ingress non supporta i certificati gestiti da Certificate Manager. Per utilizzare i certificati gestiti da Certificate Manager, utilizza l'API Gateway.
Nei cluster che utilizzano i NEG, il tempo di riconciliazione di Ingress può essere influenzato dal numero di Ingress. Ad esempio, un cluster con 20 Ingress, ognuno contenente 20 backend NEG distinti, può comportare una latenza di oltre 30 minuti per la riconciliazione di una modifica di Ingress. 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 di Compute Engine.
Se non utilizzi i NEG con il controller Ingress GKE allora i cluster GKE hanno un limite di 1000 nodi. Quando i servizi vengono sottoposti a deployment con i NEG, non esiste un limite di nodi GKE. Tutti i servizi non NEG esposti tramite Ingress non funzionano correttamente sui cluster con più di 1000 nodi.
Affinché il controller GKE Ingress utilizzi i 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 a readinessProbe di un pod non influiscono su Ingress dopo la sua 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 sulla terminazione di TLS, devi utilizzare un controller Ingress personalizzato esposto tramite un servizio GKE di tipo LoadBalancer invece, e terminare TLS sui backend che si trovano nelle regioni appropriate alle tue esigenze.
La combinazione di più risorse Ingress in un singolo Google Cloud bilanciatore del carico 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.