Questa pagina fornisce una panoramica generale di Ingress per Application Load Balancer esterni e del suo funzionamento. Google Kubernetes Engine (GKE) fornisce un controller Ingress integrato e gestito chiamato GKE Ingress. Questo controller implementa le risorse Ingress come bilanciatori del carico Google Cloud per i carichi di lavoro HTTP(S) in GKE.
Panoramica
In GKE, un oggetto Ingress definisce le regole per il routing del traffico HTTP(S) alle applicazioni in esecuzione in un cluster. Un oggetto Ingress è associato a uno o più oggetti di servizio, ciascuno dei quali è associato a un insieme di pod. Per scoprire di più su come Ingress espone le applicazioni utilizzando i servizi, consulta Panoramica del networking dei servizi.
Quando crei un oggetto Ingress, il controller GKE Ingress crea un bilanciatore del carico HTTP(S) di Google Cloud e lo configura in base alle informazioni contenute nella risorsa Ingress e ai servizi associati.
Per utilizzare Ingress, il componente aggiuntivo per il bilanciamento del carico HTTP deve essere abilitato. Il bilanciamento del carico HTTP nei cluster GKE è abilitato per impostazione predefinita; non devi disabilitarlo.
In entrata per il traffico esterno e interno
Le risorse GKE Ingress sono di due tipi:
In entrata per Application Load Balancer esterni esegue il deployment dell'Application Load Balancer classico. Il deployment di questo bilanciatore del carico rivolto a internet viene eseguito a livello globale sulla rete perimetrale di Google come pool gestito e scalabile di risorse di bilanciamento del carico. Scopri come configurare e utilizzare Ingress per bilanciatori del carico delle applicazioni esterni.
In entrata per i bilanciatori del carico delle applicazioni interni esegue il deployment dell'Application Load Balancer interno. Questi bilanciatori del carico delle applicazioni interni utilizzano sistemi proxy Envoy all'esterno 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.
Comportamento del controller GKE Ingress
Per i cluster che eseguono GKE versione 1.18 e successive, a seconda che il controller GKE Ingress elabora o meno un Ingress dipende dal valore dell'annotazione kubernetes.io/ingress.class
:
Valore kubernetes. |
Valore ingressClassName |
Comportamento del controller GKE Ingress |
---|---|---|
Non impostata | Non impostata | Elabora il manifest Ingress e crea un Application Load Balancer esterno. |
Non impostata | Qualsiasi valore | Non esegue alcuna azione. 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 Application Load Balancer esterno. |
gce-internal |
Qualsiasi valore. Questo campo viene ignorato. | Elabora il manifest Ingress e crea un Application Load Balancer interno. |
Imposta un valore diverso da gce o gce-internal |
Qualsiasi valore | Non esegue alcuna azione. Il manifest Ingress potrebbe essere elaborato da un controller Ingress di terze parti se ne è stato eseguito il deployment. |
Per i cluster che eseguono versioni GKE precedenti, il controller GKE elabora qualsiasi Ingress che non ha l'annotazione kubernetes.io/ingress.class
o ha l'annotazione con il valore gce
o gce-internal
.
Ritiro dell'annotazione kubernetes.io/ingress.class
Anche se l'annotazione kubernetes.io/ingress.class
è ritirata in Kubernetes, GKE continua a utilizzarla.
Non puoi utilizzare il campo ingressClassName
per specificare un valore GKE in entrata. Devi utilizzare l'annotazione kubernetes.io/ingress.class
.
Funzionalità degli Application Load Balancer esterni
Un bilanciatore del carico delle applicazioni esterno, configurato da Ingress, include le seguenti funzionalità:
- Configurazione flessibile per i Servizi. Un Ingress definisce il modo in cui il traffico raggiunge i tuoi servizi e come viene instradato alla tua applicazione. Inoltre, una risorsa Ingress può fornire un singolo indirizzo IP per più servizi nel cluster.
- Integrazione con i servizi di rete Google Cloud
- Supporto di più certificati TLS. Un Ingress può specificare l'uso di più certificati TLS per la terminazione delle richieste.
Per un elenco completo, consulta la sezione Configurazione in entrata.
Bilanciamento del carico nativo del container
Il bilanciamento del carico nativo del container è la pratica di bilanciamento del carico direttamente negli endpoint dei pod in GKE utilizzando i gruppi di endpoint di rete (NEG).
Quando utilizzi i gruppi di istanze, i bilanciatori del carico di Compute Engine inviano il traffico agli IP delle VM come backend. Durante l'esecuzione dei container sulle VM, in cui i container condividono la stessa interfaccia host, vengono introdotte alcune limitazioni:
- Prevede due hop di bilanciamento del carico: uno dal bilanciatore del carico alla VM
NodePort
e un altro tramite il routing kube-proxy all'IP del pod (che potrebbe risiedere su una VM diversa). - Gli hop aggiuntivi aggiungono latenza e rendono più complesso il percorso di traffico.
- Il bilanciatore del carico di Compute Engine non ha visibilità diretta sui pod, con il risultato di un bilanciamento del traffico non ottimale.
- Gli eventi ambientali, come la perdita di VM o pod, hanno più probabilità di causare una perdita di traffico intermittente a causa del doppio hop del traffico.
Con i NEG, il carico viene bilanciato dal bilanciatore del carico direttamente all'IP del pod, invece di attraversare l'IP della VM e il networking di kube-proxy. Inoltre, le gate di idoneità dei pod sono implementati per determinare l'integrità dei pod dal punto di vista del bilanciatore del carico e non solo dei probe di integrità nel cluster Kubernetes. Ciò migliora la stabilità complessiva del traffico rendendo l'infrastruttura del bilanciatore del carico a conoscenza di eventi del ciclo di vita come l'avvio dei pod, la perdita di pod o la perdita di VM. Queste funzionalità risolvono le limitazioni di cui sopra e si traducono in un networking più stabile e dalle prestazioni più elevate.
Il bilanciamento del carico nativo del container è abilitato per impostazione predefinita per i servizi quando tutte le seguenti condizioni sono vere:
- Per i servizi creati nei cluster GKE 1.17.6-gke.7 e versioni successive
- Utilizzo di cluster nativi di VPC
- Non utilizza un VPC condiviso
- Non utilizzo del criterio di rete GKE
In queste condizioni, i servizi verranno annotati automaticamente con cloud.google.com/neg: '{"ingress": true}'
, che indica che è necessario creare un NEG per eseguire il mirroring degli IP dei pod all'interno del servizio. Il NEG è ciò che consente ai bilanciatori del carico di Compute Engine di comunicare direttamente con i pod. Tieni presente che i servizi esistenti creati prima di GKE 1.17.6-gke.7 non verranno automaticamente annotati dal controller di servizio.
Per GKE 1.17.6-gke.7 e versioni precedenti, dove l'annotazione NEG è automatica, è possibile disabilitare i NEG e forzare il bilanciatore del carico esterno di Compute Engine a utilizzare un gruppo di istanze come backend, se necessario. A questo scopo, aggiungi esplicitamente i servizi cloud.google.com/neg: '{"ingress": false}'
. Non è possibile disabilitare i NEG con Ingress per i bilanciatori del carico delle applicazioni interni.
Per i cluster in cui i NEG non sono predefiniti, è comunque vivamente consigliato utilizzare il bilanciamento del carico nativo del container, ma deve essere abilitato esplicitamente in base al servizio. L'annotazione deve essere applicata ai servizi nel seguente modo:
kind: Service
...
annotations:
cloud.google.com/neg: '{"ingress": true}'
...
VPC condiviso
Le risorse in entrata e MultiClusterIngress sono supportate nel VPC condiviso, ma richiedono una preparazione aggiuntiva.
Il controller Ingress viene eseguito sul piano di controllo GKE ed effettua chiamate API a Google Cloud utilizzando l'account di servizio GKE del progetto del cluster. Per impostazione predefinita, quando un cluster che si trova in un progetto di servizio VPC condiviso utilizza una rete VPC condivisa, il controller in entrata non può utilizzare l'account di servizio GKE del progetto di servizio per creare e aggiornare le regole firewall di autorizzazione in entrata nel progetto host.
Puoi concedere all'account di servizio GKE del progetto di servizio le autorizzazioni per creare e gestire le regole firewall VPC nel progetto host. Se concedi queste autorizzazioni, GKE crea regole firewall di autorizzazione in entrata per:
Proxy e sistemi di controllo di integrità Google Front End (GFE) utilizzati da Application Load Balancer esterni per Ingress esterno. Per ulteriori informazioni, consulta la Panoramica del bilanciatore del carico delle applicazioni esterno.
Sistemi di controllo di integrità per bilanciatori del carico delle applicazioni interni utilizzati da Ingress interno.
Esegui manualmente il provisioning delle regole firewall dal progetto host
Se i criteri di sicurezza consentono la gestione del firewall solo dal progetto host, puoi eseguire il provisioning di queste regole firewall manualmente. Durante il deployment di Ingress in un VPC condiviso, l'evento di risorse Ingress fornisce la regola firewall specifica che devi aggiungere per fornire l'accesso.
Per eseguire il provisioning manuale di una regola:
Visualizza l'evento di risorse Ingress:
kubectl describe ingress INGRESS_NAME
Sostituisci INGRESS_NAME con il nome del tuo file Ingress.
Dovresti vedere un output simile al seguente esempio:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 9m34s (x237 over 38h) loadbalancer-controller Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`
La regola firewall obbligatoria suggerita viene visualizzata nella colonna
Message
.Copia e applica le regole firewall suggerite dal progetto host. L'applicazione della regola consente di accedere ai pod dal bilanciatore del carico e dai controlli di integrità di Google Cloud.
Fornitura dell'autorizzazione del controller GKE Ingress per gestire le regole firewall del progetto host
Se vuoi che un cluster GKE in un progetto di servizio crei e gestisca le risorse firewall nel progetto host, all'account di servizio GKE del progetto di servizio devono essere concesse le autorizzazioni IAM appropriate utilizzando una delle seguenti strategie:
Concedi all'account di servizio GKE del progetto di servizio il ruolo Amministratore sicurezza Compute al progetto host. L'esempio seguente illustra questa strategia.
Per un approccio più granulare, crea un ruolo IAM personalizzato che includa solo le seguenti autorizzazioni:
compute.networks.updatePolicy
,compute.firewalls.list
,compute.firewalls.get
,compute.firewalls.create
,compute.firewalls.update
ecompute.firewalls.delete
. Concedi all'account di servizio GKE del progetto di servizio quel ruolo personalizzato al progetto host.
Se hai cluster in più progetti di servizio, devi scegliere una delle strategie e ripeterla per l'account di servizio GKE di ogni progetto di servizio.
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
--member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
--role=roles/compute.securityAdmin
Sostituisci quanto segue:
HOST_PROJECT_ID
: l'ID progetto del progetto host VPC condiviso.SERVICE_PROJECT_NUMBER
: il numero di progetto del progetto di servizio che contiene il cluster.
Più servizi di backend
Ogni bilanciatore del carico delle applicazioni esterno o Application Load Balancer interno utilizza una singola mappa URL, che fa riferimento a uno o più servizi di backend. Un servizio di backend corrisponde a ogni servizio a cui fa riferimento l'oggetto Ingress.
Ad esempio, puoi configurare il bilanciatore del carico in modo che instrada le richieste a servizi di backend diversi in base al percorso dell'URL. Le richieste inviate a your-store.example potrebbero essere indirizzate a un servizio di backend che mostra articoli a prezzo intero, mentre le richieste inviate a your-store.example/discount potrebbero essere indirizzate a un servizio di backend che mostra articoli scontati.
Puoi anche configurare il bilanciatore del carico in modo che instrada le richieste in base al nome host. Le richieste inviate a your-store.example potrebbero essere inviate a un servizio di backend, mentre quelle inviate a your-experimental-store.example potrebbero essere inviate a un altro servizio di backend.
In un cluster GKE, crei e configuri un bilanciatore del carico HTTP(S) mediante la creazione di un oggetto Kubernetes Ingress. Un oggetto Ingress deve essere associato a uno o più oggetti Service, ciascuno dei quali è associato a un insieme di pod.
Di seguito è riportato un manifest per una risorsa Ingress denominata my-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
Quando crei la risorsa Ingress, il controller Ingress GKE crea e configura un bilanciatore del carico delle applicazioni esterno o un bilanciatore del carico delle applicazioni interno in base alle informazioni contenute nella risorsa Ingress e ai servizi associati. Inoltre, al bilanciatore del carico viene assegnato un indirizzo IP stabile che puoi associare a un nome di dominio.
Nell'esempio precedente, supponiamo di aver associato l'indirizzo IP del bilanciatore del carico al nome di dominio your-store.example. Quando un client invia una richiesta a your-store.example, la richiesta viene instradata a un servizio Kubernetes denominato my-products
sulla porta 60000. E quando un client invia una richiesta a
your-store.example/discounted, la richiesta viene instradata a un servizio Kubernetes
denominato my-discounted-products
sulla porta 80.
L'unico carattere jolly supportato per il campo path
di una risorsa Ingress è il carattere *
. Il carattere *
deve seguire una barra (/
) e
deve essere l'ultimo carattere del pattern. Ad esempio, /*
, /foo/*
e
/foo/bar/*
sono pattern validi, al contrario di *
, /foo/bar*
e /foo/*/bar
.
Un pattern più specifico ha la precedenza su un pattern meno specifico. Se
hai sia /foo/*
che /foo/bar/*
, allora /foo/bar/bat
viene considerato come corrispondenza
/foo/bar/*
.
Per ulteriori informazioni sulle limitazioni dei percorsi e sulla corrispondenza dei pattern, consulta la documentazione di URL Maps.
Il file manifest del servizio my-products
potrebbe avere il seguente aspetto:
apiVersion: v1 kind: Service metadata: name: my-products spec: type: NodePort selector: app: products department: sales ports: - protocol: TCP port: 60000 targetPort: 50000
Nel manifest del servizio, devi utilizzare type: NodePort
, a meno che non utilizzi il bilanciamento del carico nativo del container.
Se utilizzi il bilanciamento del carico nativo del container, utilizza type: ClusterIP
.
Nel manifest del servizio, il campo selector
indica che qualsiasi pod con sia l'etichetta app: products
sia l'etichetta department: sales
fa parte del servizio.
Quando una richiesta arriva al servizio sulla porta 60000, viene instradata a uno dei pod membri sulla porta TCP 50000.
Ogni pod membro deve disporre di un container in ascolto sulla porta TCP 50.000.
Il file manifest del servizio my-discounted-products
potrebbe avere il seguente aspetto:
apiVersion: v1 kind: Service metadata: name: my-discounted-products spec: type: NodePort selector: app: discounted-products department: sales ports: - protocol: TCP port: 80 targetPort: 8080
Nel manifest del servizio, il campo selector
indica che qualsiasi pod con etichetta app: discounted-products
e department: sales
fa parte del servizio.
Quando una richiesta arriva al servizio sulla porta 80, viene instradata a uno dei pod membri sulla porta TCP 8080.
Ogni pod membro deve disporre di un container in ascolto sulla porta TCP 8080.
Backend predefinito
Puoi specificare un backend predefinito per la tua risorsa Ingress fornendo un campo spec.defaultBackend
nel manifest Ingress. Questa operazione gestirà tutte le richieste che non corrispondono
ai percorsi definiti nel campo rules
. Ad esempio, nel seguente Ingress, tutte le richieste che non corrispondono a /discounted
vengono inviate a un servizio denominato my-products
sulla porta 60001.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
defaultBackend:
service:
name: my-products
port:
number: 60001
rules:
- http:
paths:
- path: /discounted
pathType: ImplementationSpecific
backend:
service:
name: my-discounted-products
port:
number: 80
Se non specifichi un backend predefinito, GKE fornisce un backend predefinito che restituisce l'errore 404. Viene creato come servizio NodePort default-http-backend
nel cluster nello spazio dei nomi kube-system
.
La risposta HTTP 404 è simile alla seguente:
response 404 (backend NotFound), service rules for the path non-existent
Per configurare GKE Ingress con un backend predefinito del cliente, consulta GKE Ingress con backend predefinito personalizzato.
Ingress nelle mappature delle 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 di cui viene eseguito il deployment nel cluster. La mappatura delle risorse 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 Ends 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 matcher percorso singolo.
Il matcher percorso ha due regole percorso, una per
/*
e un'altra per/discounted
. Ogni regola del percorso è mappata a un servizio di backend univoco. - NEG che contengono un elenco di indirizzi IP dei pod di ciascun servizio come endpoint.
Questi vengono creati a seguito dei Servizi
my-discounted-products
emy-products
.
Opzioni per fornire certificati SSL
Puoi fornire certificati SSL a un bilanciatore del carico HTTP(S) utilizzando i seguenti metodi:
- Certificati gestiti da Google
- I certificati SSL gestiti da Google vengono sottoposti a provisioning, deployment, rinnovati e gestiti per i tuoi domini. I certificati gestiti non supportano i domini con caratteri jolly.
- Certificati autogestiti condivisi con Google Cloud
- Puoi eseguire il provisioning del tuo certificato SSL e creare una risorsa di certificato nel tuo progetto Google Cloud. Puoi quindi elencare la risorsa di certificato in un'annotazione su una risorsa Ingress per creare un bilanciatore del carico HTTP(S) che utilizzi il certificato. Per ulteriori informazioni, consulta le istruzioni per i certificati precondivisi.
- Certificati autogestiti come risorse secret
- Puoi eseguire il provisioning del tuo certificato SSL e creare un secret per conservarlo. Puoi quindi fare riferimento al secret in una specifica Ingress per creare un bilanciatore del carico HTTP(S) che utilizzi il certificato. Per saperne di più, consulta le istruzioni per l'utilizzo dei certificati nei secret.
Controlli di integrità
Quando esponi uno o più servizi tramite una risorsa Ingress utilizzando il controller Ingress predefinito, GKE crea un Application Load Balancer classico o un Application Load Balancer interno. Entrambi questi bilanciatori del carico supportano più servizi di backend su una singola mappa URL. Ciascuno dei servizi di backend corrisponde a un servizio Kubernetes e ogni servizio di backend deve fare riferimento a un controllo di integrità di Google Cloud. Questo controllo di integrità è diverso da un probe di attività o di idoneità Kubernetes, perché viene implementato al di fuori del cluster.
GKE utilizza la seguente procedura per creare un controllo di integrità per ciascun servizio di backend corrispondente a un servizio Kubernetes:
Se il servizio fa riferimento a un CRD
BackendConfig
con informazionihealthCheck
, GKE la utilizza per creare il controllo di integrità. Sia il controller GKE Enterprise che il controller GKE Ingress supportano la creazione di controlli di integrità in questo modo.Se il Servizio non fa riferimento a una CRD
BackendConfig
:GKE può dedurre alcuni o tutti i parametri per un controllo di integrità se i pod di pubblicazione utilizzano un modello di pod con un container il cui probe di idoneità ha attributi che possono essere interpretati come parametri di controllo di integrità. Consulta Parametri di un probe di idoneità per i dettagli dell'implementazione e i parametri predefiniti e dedotti per un elenco di attributi che possono essere utilizzati per creare parametri per il controllo di integrità. Solo il controller GKE Ingress supporta la deduzione dei parametri da un probe di idoneità.
Se il modello di pod per i pod di gestione del servizio non ha un container con un probe di idoneità i cui attributi possono essere interpretati come parametri per il controllo di integrità, vengono utilizzati i valori predefiniti per creare il controllo di integrità. Sia il controller GKE Enterprise che il controller GKE Ingress possono creare un controllo di integrità utilizzando solo i valori predefiniti.
Parametri predefiniti e dedotti
I seguenti parametri vengono utilizzati se non specifichi i parametri di controllo di integrità per il servizio corrispondente utilizzando una CRD BackendConfig
.
Parametro del controllo di integrità | Valore predefinito | Valore deducibile |
---|---|---|
Protocollo | HTTP | se presente nell'annotazione Servizio cloud.google.com/app-protocols
|
Percorso richiesta | / |
se presente nel pod di pubblicazione spec :containers[].readinessProbe.httpGet.path
|
Intestazione richiesta host | Host: backend-ip-address |
se presente nel pod di pubblicazione spec :containers[].readinessProbe.httpGet.httpHeaders
|
Risposta prevista | HTTP 200 (OK) | HTTP 200 (OK) non può essere modificato |
Intervallo di controllo |
|
se presente nel pod di pubblicazione spec :
|
Controlla il timeout | 5 secondi | se presente nel pod di pubblicazione spec :containers[].readinessProbe.timeoutSeconds |
Soglia stato integro | 1 | 1 non può essere modificato |
Soglia di stato non integro |
|
uguale a quello predefinito:
|
Specifiche della porta |
|
I probe di controllo di integrità vengono inviati al numero di porta specificato da
spec.containers[].readinessProbe.httpGet.port , a condizione che
si verifichino anche tutte le seguenti condizioni:
|
Indirizzo IP di destinazione |
|
uguale a quello predefinito:
|
Parametri di un probe di idoneità
Quando GKE crea il controllo di integrità per il servizio di backend del servizio, GKE può copiare determinati parametri dal probe di idoneità di un container utilizzato dai pod di gestione di quel servizio. Questa opzione è supportata solo dal controller GKE Ingress.
Gli attributi del probe di idoneità supportati che possono essere interpretati come parametri di controllo di integrità sono elencati insieme ai valori predefiniti in Parametri predefiniti e dedotti. I valori predefiniti vengono utilizzati per qualsiasi attributo non specificato nel probe di idoneità o se non specifichi un probe di idoneità.
Se i pod di gestione per il tuo servizio contengono più container o se utilizzi il controller Ingress di GKE Enterprise, devi utilizzare una CRD BackendConfig
per definire i parametri del controllo di integrità. Per maggiori informazioni, consulta Quando utilizzare
una CRD BackendConfig
.
Quando utilizzare invece BackendConfig
CRD
Anziché fare affidamento sui parametri dei probe di idoneità dei pod, devi definire esplicitamente i parametri di controllo di integrità per un servizio di backend creando un CRD BackendConfig
per il servizio in queste situazioni:
- Se utilizzi GKE Enterprise: il controller GKE Enterprise Ingress non supporta l'ottenimento dei parametri per il controllo di integrità dai probe di idoneità dei pod di gestione. Può creare controlli di integrità solo utilizzando parametri
impliciti o come definiti in un
BackendConfig
CRD.
Se nei pod di gestione sono presenti più container: GKE non offre un modo per selezionare il probe di idoneità di un container specifico da cui dedurre i parametri del controllo di integrità. Poiché ogni container può avere il proprio probe di idoneità e un probe di idoneità non è un parametro obbligatorio per un container, devi definire il controllo di integrità per il servizio di backend corrispondente facendo riferimento a una CRD
BackendConfig
sul servizio corrispondente.Se hai bisogno di controllare la porta utilizzata per i controlli di integrità del bilanciatore del carico: GKE utilizza il
containers[].readinessProbe.httpGet.port
del probe di idoneità solo per il controllo di integrità del servizio di backend quando questa porta corrisponde alla porta del servizio a cui viene fatto riferimento nel serviziospec.rules[].http.paths[].backend.servicePort
in entrata.
Parametri di un CRD BackendConfig
Puoi specificare i parametri per il controllo di integrità del servizio di backend utilizzando il parametro healthCheck
di una CRD BackendConfig
a cui fa riferimento il servizio corrispondente. Questo ti offre maggiore flessibilità e controllo sui controlli di integrità per un bilanciatore del carico delle applicazioni classico o un bilanciatore del carico delle applicazioni interno creato da una risorsa Ingress. Consulta la pagina relativa alla configurazione in entrata per la compatibilità delle versioni di GKE.
In questo esempio di CRD BackendConfig
definisce il protocollo (tipo), un percorso di richiesta, una porta e un intervallo di controllo nel relativo attributo spec.healthCheck
:
apiVersion: cloud.google.com/v1 kind: BackendConfig metadata: name: http-hc-config spec: healthCheck: checkIntervalSec: 15 port: 15020 type: HTTPS requestPath: /healthz
Per configurare tutti i campi disponibili durante la configurazione di un controllo di integrità BackendConfig
, utilizza l'esempio di configurazione del controllo di integrità personalizzata.
Per configurare GKE Ingress con un controllo di integrità HTTP personalizzato, consulta GKE Ingress con controllo di integrità HTTP personalizzato.
Utilizzo di più certificati TLS
Supponiamo che tu voglia che un bilanciatore del carico HTTP(S) pubblichi contenuti da due nomi host: your-store.example e your-experimental-store.example. Inoltre, vuoi che il bilanciatore del carico utilizzi un certificato per your-store.example e un altro certificato per your-experimental-store.example.
Per farlo, specifica più certificati in un manifest Ingress. Il bilanciatore del carico sceglie un certificato se il nome comune (CN) nel certificato corrisponde al nome host utilizzato nella richiesta. Per informazioni dettagliate su come configurare più certificati, consulta Utilizzo di più certificati SSL nel bilanciamento del carico HTTPS con Ingress.
Confronto tra il servizio Kubernetes e il servizio di backend Google Cloud
Un servizio Kubernetes e un servizio di backend Google Cloud sono cose diverse. Esiste una forte relazione tra i due aspetti, ma non necessariamente il rapporto uno a uno. Il controller Ingress GKE crea un servizio di backend Google Cloud per ogni coppia (service.name
, service.port
) in un manifest Ingress. Pertanto, è possibile che un oggetto del servizio Kubernetes sia correlato a più servizi di backend di Google Cloud.
Limitazioni
Nei cluster che utilizzano versioni precedenti alla 1.16, la lunghezza totale dello spazio dei nomi e del nome di una risorsa Ingress non deve superare i 40 caratteri. Se non segui queste linee guida, il controller GKE Ingress potrebbe funzionare in modo anomalo. Per ulteriori informazioni, consulta questa pagina Problema di GitHub sui nomi lunghi.
Nei cluster che utilizzano NEG, la data e l'ora di riconciliazione del traffico in entrata potrebbero essere influenzate dal numero di accessi. Ad esempio, un cluster con 20 Ingress, ciascuno contenente 20 backend NEG distinti, potrebbe comportare una latenza superiore a 30 minuti per la riconciliazione di una modifica del traffico in entrata. Questo riguarda soprattutto i cluster a livello di regione a causa dell'aumento del numero di NEG necessario.
Si applicano quote per le mappe URL.
Si applicano quote per le risorse di Compute Engine.
Se non utilizzi NEG con il controller in entrata di GKE, i cluster GKE hanno un limite di 1000 nodi. Se viene eseguito il deployment dei servizi con NEG, non è previsto alcun limite di nodi GKE. Tutti i servizi non NEG esposti tramite Ingress non funzionano correttamente nei cluster con più di 1000 nodi.
Affinché il controller GKE Ingress utilizzi
readinessProbes
come controlli di integrità, è necessario che esistano i pod per una risorsa Ingress al momento della creazione dell'oggetto Ingress. Se le repliche vengono scalate a 0, viene applicato il controllo di integrità predefinito. Per ulteriori informazioni, leggi questo commento su GitHub relativo ai controlli di integrità.Le modifiche al valore
readinessProbe
di un pod non influiscono sulla risorsa Ingress dopo la creazione.Un bilanciatore del carico delle applicazioni esterno termina il protocollo 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 controllare l'area geografica in cui termina il protocollo TLS, devi utilizzare un controller in entrata personalizzato esposto tramite un servizio GKE di tipo
LoadBalancer
e terminare il protocollo TLS sui backend che si trovano nelle regioni appropriate alle tue esigenze.La combinazione di più risorse Ingress in un singolo bilanciatore del carico Google Cloud non è supportata.
Devi disattivare il protocollo TLS reciproco nella tua applicazione perché non è supportato per i bilanciatori del carico delle applicazioni esterni.
Cluster esterni basati su route e Ingress
Se utilizzi cluster basati su route con Ingress esterno, il controller GKE Ingress non può utilizzare il bilanciamento del carico nativo del container utilizzando GCE_VM_IP_PORT
gruppi di endpoint di rete (NEG). Il controller Ingress utilizza invece backend di gruppi di istanze non gestiti che includono tutti i nodi in tutti i pool di nodi. Se questi gruppi di istanze non gestite vengono utilizzati anche dai servizi LoadBalancer
, possono causare problemi relativi alla limitazione dei gruppi di istanze con bilanciamento del carico.
Alcuni oggetti Ingress esterni meno recenti creati in cluster nativi VPC potrebbero utilizzare backend di gruppi di istanze sui servizi di backend di ogni bilanciatore del carico delle applicazioni esterno che creano. Non è pertinente per la risorsa Ingress interna perché le risorse Ingress interne utilizzano sempre GCE_VM_IP_PORT
NEG e richiedono cluster nativi di VPC.
Per scoprire come risolvere gli errori 502 relativi a un traffico in entrata esterno, consulta L'ingresso esterno genera errori HTTP 502.
Dettagli di implementazione
- Il controller Ingress esegue controlli periodici delle autorizzazioni dell'account di servizio recuperando una risorsa di test dal tuo progetto Google Cloud. Vedrai questo come
un
GET
delBackendService
globale (inesistente) con il nomek8s-ingress-svc-acct-permission-check-probe
. Poiché questa risorsa in genere non dovrebbe esistere, la richiestaGET
restituirà "not found". Si tratta di un comportamento previsto: il controller sta controllando che la chiamata API non sia stata rifiutata a causa di problemi di autorizzazione. Se crei un servizio BackendService con lo stesso nome, l'elementoGET
avrà esito positivo anziché restituire "not found".
Modelli per la configurazione Ingress
- In GKE Networking Recipes, puoi trovare i modelli forniti da GKE su molti utilizzi comuni di Ingress nella sezione Ingress.
Passaggi successivi
- Scopri di più sulle formule di networking GKE
- Scopri di più sul bilanciamento del carico in Google Cloud.
- Leggi una panoramica del networking in GKE.
- Scopri come configurare Ingress per bilanciatori del carico delle applicazioni interni.
- Scopri come configurare Ingress per bilanciatori del carico delle applicazioni esterni.