Questa pagina fornisce una panoramica generale su quale risorsa Ingress per i bilanciatori del carico delle applicazioni esterni e come funziona. Google Kubernetes Engine (GKE) offre un servizio Ingress integrato e gestito chiamato GKE Ingress. Questo controller implementa Ingress come bilanciatori del carico Google Cloud per i carichi di lavoro HTTP(S) con GKE.
Panoramica
In GKE, viene eseguita Oggetto Ingress definisce le regole per instradare il traffico HTTP(S) alle applicazioni in esecuzione in un cluster. Un oggetto Ingress è associato a uno o più Oggetti di servizio, ognuno dei quali è associati a un insieme di pod. Per scoprire di più sull'esposizione di Ingress che utilizzano i servizi, vedere Panoramica della rete di servizi.
Quando crei un oggetto Ingress, Controller Ingress GKE crea un bilanciatore del carico HTTP(S) di Google Cloud e lo configura in base alle informazioni nel traffico in entrata e ai suoi Servizi.
Per utilizzare Ingress, devi avere abilitato il componente aggiuntivo per il bilanciamento del carico HTTP. Nei cluster GKE il bilanciamento del carico HTTP è abilitato per impostazione predefinita. tu non deve disabilitarlo.
In entrata per traffico esterno e interno
Le risorse GKE Ingress sono di due tipi:
In entrata per bilanciatori del carico delle applicazioni esterni esegue il deployment del bilanciatore del carico delle applicazioni classico. Questo bilanciatore del carico per internet è stato distribuito a livello globale attraverso il perimetro di Google di rete 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 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.
Comportamento del controller GKE Ingress
Per i cluster che eseguono GKE versione 1.18 e successive, indipendentemente dal fatto che
che il controller GKE Ingress elabora un Ingress dipende
valore dell'annotazione kubernetes.io/ingress.class
:
kubernetes. valore |
ingressClassName valore |
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 effettua alcuna azione. Il manifest Ingress può essere elaborato da un un controller Ingress di terze parti, se ne è stato eseguito uno. |
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 oppure
gce-internal |
Qualsiasi valore | Non effettua alcuna azione. Il manifest Ingress può essere elaborato da un un controller Ingress di terze parti, se ne è stato eseguito uno. |
Per i cluster che eseguono versioni GKE precedenti,
il controller elabora qualsiasi risorsa Ingress senza l'annotazione
kubernetes.io/ingress.class
o contiene l'annotazione con il valore
gce
o gce-internal
.
Ritiro dell'annotazione kubernetes.io/ingress.class
Anche se l'annotazione kubernetes.io/ingress.class
è
ritirato in Kubernetes, GKE continua a utilizzare questo
annotazione.
Non puoi utilizzare il campo ingressClassName
per specificare un cluster GKE
In entrata. Devi utilizzare l'annotazione kubernetes.io/ingress.class
.
Caratteristiche dei bilanciatori del carico delle applicazioni esterni
Un bilanciatore del carico delle applicazioni esterno, configurato da Ingress, include quanto segue caratteristiche:
- Configurazione flessibile per i servizi. Una risorsa Ingress definisce il modo in cui il traffico raggiunge i tuoi servizi e come il traffico viene instradato alla tua applicazione. Inoltre, una risorsa Ingress può fornire un singolo indirizzo IP per più servizi nel tuo cluster.
- Integrazione con i servizi di rete di Google Cloud
- Supporto di più certificati TLS. Una risorsa Ingress può specificare l'uso di più certificati TLS per la terminazione delle richieste.
Per un elenco completo, vedi Configurazione in entrata.
Bilanciamento del carico nativo del container
Bilanciamento del carico nativo del container è la pratica del bilanciamento del carico direttamente nel pod endpoint in GKE Gruppi di endpoint di rete (NEG).
Quando si utilizzano i gruppi di istanze, i bilanciatori del carico di Compute Engine inviano il traffico IP delle VM come backend. Durante l'esecuzione dei container sulle VM, in cui i container condividono la stessa interfaccia host, ciò introduce alcune limitazioni:
- Richiede due hop di bilanciamento del carico: uno dal bilanciatore del carico
La VM
NodePort
e un altro hop attraverso il routing kube-proxy all'IP del pod (che possono trovarsi su una VM diversa). - Gli hop aggiuntivi aggiungono latenza e rendono più complesso il percorso del traffico.
- Il bilanciatore del carico di Compute Engine non ha visibilità diretta sui pod, in un bilanciamento del traffico non ottimale.
- È più probabile che si verifichino eventi ambientali come la perdita di VM o pod perdita di traffico intermittente dovuta al doppio hop di traffico.
Con i NEG, il carico viene bilanciato direttamente dal bilanciatore del carico l'IP del pod invece di attraversare l'IP della VM e il networking kube-proxy. Inoltre, gateway di idoneità dei pod per determinare l'integrità dei pod dal punto di vista e non solo i probe di integrità nel cluster di Kubernetes. Questo migliora la stabilità complessiva del traffico rendendo l'infrastruttura del bilanciatore del carico degli eventi del ciclo di vita, come l'avvio dei pod, la perdita di pod o la perdita di VM. Questi risolvere i limiti di cui sopra e migliorare le prestazioni una rete stabile.
Il bilanciamento del carico nativo del container è abilitato per impostazione predefinita per i servizi quando tutte le istanze 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
- Mancato utilizzo di un VPC condiviso
- Non utilizza il 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 annotati automaticamente dal controller del servizio.
Per GKE 1.17.6-gke.7 e versioni precedenti, in cui 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. Per farlo, puoi annotare esplicitamente i servizi con cloud.google.com/neg: '{"ingress": false}'
. Non è possibile disabilitare i NEG con Ingress per gli Application Load Balancer interni.
Per i cluster in cui i NEG non sono il valore predefinito, è comunque fortemente di utilizzare il bilanciamento del carico nativo del container, ma deve essere esplicitamente per singolo servizio. L'annotazione deve essere applicata ai Servizi nel seguente modo:
kind: Service
...
annotations:
cloud.google.com/neg: '{"ingress": true}'
...
VPC condiviso
Le risorse Ingress e MultiClusterIngress sono supportate in VPC condiviso, ma richiedono dei dati.
Il controller Ingress viene eseguito sul piano di controllo GKE e restituisce Chiamate API a Google Cloud tramite il servizio GKE del progetto del cluster. Per impostazione predefinita, quando un cluster si trova un progetto di servizio del VPC condiviso utilizza una rete VPC condivisa, Il controller Ingress non può utilizzare il servizio GKE del progetto di servizio per creare e aggiornare le regole firewall di autorizzazione in entrata nel progetto host.
Puoi concedere le autorizzazioni dell'account di servizio GKE del progetto di servizio per creare e gestire le regole firewall VPC nel progetto host. Concedendo queste autorizzazioni, GKE crea regole firewall di autorizzazione in entrata per quanto segue:
Proxy Google Front End (GFE) e sistemi di controllo di integrità utilizzati Application Load Balancer esterni per Ingress esterno. Per ulteriori informazioni, consulta 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 quindi eseguire il provisioning manuale di queste regole firewall. Quando esegui il deployment di Ingress è un VPC condiviso, l'evento risorsa Ingress fornisce la regola firewall specifica che aggiungere gli elementi necessari per fornire l'accesso.
Per eseguire manualmente il provisioning di una regola:
Visualizza l'evento di risorsa Ingress:
kubectl describe ingress INGRESS_NAME
Sostituisci INGRESS_NAME con il nome del tuo Ingress.
Dovresti vedere un output simile all'esempio seguente:
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. Applicazione in corso la regola fornisce l'accesso ai pod dal bilanciatore del carico Controlli di integrità di Google Cloud.
Fornire l'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 per gestire le risorse firewall nel progetto host, All'account di servizio GKE deve essere concesso Autorizzazioni IAM utilizzando una delle seguenti strategie:
Concedi all'account di servizio GKE del progetto di servizio Ruolo Amministratore sicurezza Compute al progetto host. L'esempio seguente illustra questa strategia.
Per un approccio più dettagliato, creare un ruolo IAM personalizzato che include solo le seguenti autorizzazioni:
compute.networks.updatePolicy
,compute.firewalls.list
,compute.firewalls.get
,compute.firewalls.create
compute.firewalls.update
ecompute.firewalls.delete
. Concedi il servizio dell'account di servizio GKE del progetto quel ruolo personalizzato progetto.
Se disponi di cluster in più progetti di servizio, devi scegliere uno dei e ripeterlo per il 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
: il valore ID progetto del Progetto host VPC condiviso.SERVICE_PROJECT_NUMBER
: il valore numero progetto del progetto di servizio che contiene il cluster.
Più servizi di backend
Ogni bilanciatore del carico delle applicazioni esterno o bilanciatore del carico delle applicazioni interno utilizza un mappa URL singolo, che fa riferimento a uno o più servizi di backend. Un backend corrisponde a ogni servizio a cui fa riferimento l'oggetto Ingress.
Ad esempio, puoi configurare il bilanciatore del carico per instradare le richieste a diverse di backend in base al percorso dell'URL. Richieste inviate a your-store.example potrebbe essere instradato a un servizio di backend che mostra richieste e articoli a prezzo intero inviato a your-store.example/discounted potrebbe essere instradato a un servizio di backend mostra articoli scontati.
Puoi anche configurare il bilanciatore del carico per instradare le richieste in base dell'host. Le richieste inviate a your-store.example potrebbero andare a un servizio di backend, e le richieste inviate a your-experimental-store.example potrebbero essere indirizzate a un altro di servizio di backend.
In un cluster GKE, crei e configuri un bilanciatore del carico HTTP(S) creando un oggetto Kubernetes Ingress. È necessario associare un oggetto Ingress a uno o più oggetti di servizio, ognuno dei quali è associato a un un insieme di pod.
Ecco un manifest per una risorsa Ingress chiamata 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 una risorsa Ingress, il controller GKE Ingress crea e configura un bilanciatore del carico delle applicazioni esterno o un bilanciatore del carico delle applicazioni interno in base alle informazioni nella risorsa Ingress e nei 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 che tu abbia associato l'indirizzo IP del bilanciatore del carico
con il 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
your-store.example/discounted, la richiesta viene instradata a un servizio Kubernetes
denominata 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 uno meno specifico. Se
hanno sia /foo/*
che /foo/bar/*
, viene utilizzato /foo/bar/bat
per trovare la corrispondenza
/foo/bar/*
.
Per ulteriori informazioni sulle limitazioni dei percorsi e sulla corrispondenza dei pattern, consulta documentazione di Maps URL.
Il file manifest per il servizio my-products
potrebbe essere simile al seguente:
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 usare type: NodePort
, a meno che non usi
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 qualsiasi pod con
L'etichetta app: products
e l'etichetta department: sales
sono membri di questa
assistenza.
Quando una richiesta arriva al servizio sulla porta 60000, viene instradata a uno dei sulla porta TCP 50000.
Ogni pod membro deve avere un container in ascolto sulla porta TCP 50000.
Il file manifest per il servizio my-discounted-products
potrebbe essere simile al seguente:
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 qualsiasi pod con
L'etichetta app: discounted-products
e l'etichetta department: sales
sono membri
di questo Servizio.
Quando una richiesta arriva al servizio sulla porta 80, viene instradata a uno dei sulla porta TCP 8080.
Ogni pod membro deve avere un container in ascolto sulla porta TCP 8080.
Backend predefinito
Puoi specificare un backend predefinito per la tua risorsa Ingress fornendo un spec.defaultBackend
nel tuo manifest Ingress. che gestirà le richieste che non corrispondono
i percorsi definiti nel campo rules
. Ad esempio, nel seguente Ingress, qualsiasi
le richieste che non corrispondono a /discounted
vengono inviate a un servizio denominato my-products
su
la 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'istanza
backend predefinito che restituisce l'errore 404. Questo viene creato come default-http-backend
Servizio NodePort sul 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 di Compute Engine e lo gestisce delle risorse del bilanciatore del carico in base alle risorse Ingress di cui viene eseguito il deployment in un cluster Kubernetes. La mappatura delle risorse Compute Engine dipende dalla struttura la risorsa Ingress.
Il seguente manifest descrive una risorsa 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 quanto segue 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à dei bilanciatori 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 di percorso.
Il matcher di percorso ha due regole di percorso, una per
/*
e un'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 ciascun servizio come endpoint.
Questi vengono creati a seguito degli
my-discounted-products
e Servizi dimy-products
.
Opzioni per fornire certificati SSL
Puoi fornire certificati SSL a un bilanciatore del carico HTTP(S) utilizzando quanto segue metodo:
- Certificati gestiti da Google
- I certificati SSL gestiti da Google sono di cui è stato eseguito il provisioning, il rinnovo e la gestione per i tuoi domini. I certificati gestiti non supportare 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 le risorse di certificato in un'annotazione su una risorsa Ingress per creare un bilanciatore del carico HTTP(S) che utilizzi certificato. Consulta le istruzioni per i contenuti certificati per maggiori informazioni.
- Certificati autogestiti come risorse secret
- Puoi eseguire il provisioning del tuo certificato SSL e creare una Segreto per trattenerla. Puoi quindi fare riferimento al secret in una specifica Ingress per creare un bilanciatore del carico HTTP(S) che utilizza certificato. Per saperne di più, consulta le istruzioni su come utilizzare i certificati nei secret informazioni.
Controlli di integrità
Quando esponi uno o più servizi tramite una risorsa Ingress utilizzando il valore predefinito un controller Ingress, GKE crea Application Load Balancer classico o bilanciatore del carico delle applicazioni interno. Entrambe le opzioni i bilanciatori del carico supportano più backend servizi su un singolo URL mappa. 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é il controllo di integrità è implementato al di fuori del cluster.
GKE utilizza la seguente procedura per creare un controllo di integrità ogni servizio di backend corrispondente a un servizio Kubernetes:
Se il servizio fa riferimento a un CRD
BackendConfig
conhealthCheck
, GKE le usa per creare l'integrità verifica. Sia il controller Ingress GKE Enterprise che Il controller GKE Ingress supporta la creazione di controlli di integrità in questo modo.Se il servizio non fa riferimento a un CRD
BackendConfig
:GKE può dedurre alcuni o tutti i parametri per un'integrità verificare se i pod di pubblicazione usano un modello di pod con un container Il probe di idoneità ha attributi che possono essere interpretati come controllo di integrità parametri. Consulta Parametri di un probe di idoneità per dettagli dell'implementazione e Parametri predefiniti e dedotti per un elenco di attributi che possono essere usati per creare il controllo di integrità parametri. Solo il controller GKE Ingress supporta e l'inferenza dei parametri da un probe di idoneità.
Se il modello di pod per i pod di gestione del servizio non ha una container con un probe di idoneità i cui attributi possono essere interpretati come parametri del controllo di integrità, i valori predefiniti vengono utilizzati per creare il controllo di integrità. Entrambi i controller Ingress GKE Enterprise e il controller GKE Ingress può creare un controllo di integrità utilizzando solo i valori predefiniti.
Parametri predefiniti e dedotti
I seguenti parametri vengono usati quando non specifichi il controllo di integrità
per il servizio corrispondente utilizzando un BackendConfig
CRD.
Parametro del controllo di integrità | Valore predefinito | Valore dedotto |
---|---|---|
Protocollo | HTTP | se presente nell'annotazione del servizio cloud.google.com/app-protocols
|
Percorso richiesta | / |
se presente nell'elemento spec del pod di pubblicazione:containers[].readinessProbe.httpGet.path
|
Richiedi intestazione Host | Host: backend-ip-address |
se presente nell'elemento spec del pod di pubblicazione:containers[].readinessProbe.httpGet.httpHeaders
|
Risposta prevista | HTTP 200 (OK) | HTTP 200 (OK) non può essere modificato |
Controlla intervallo |
|
se presente nell'oggetto spec del pod di pubblicazione:
|
Controlla timeout | 5 secondi | se presente nell'elemento spec del pod di pubblicazione:containers[].readinessProbe.timeoutSeconds |
Sano soglia | 1 | 1 non può essere modificato |
Insalubre soglia |
|
uguale al valore predefinito:
|
Specifiche della porta |
|
I probe del controllo di integrità vengono inviati al numero di porta specificato
spec.containers[].readinessProbe.httpGet.port , purché tutti
delle seguenti condizioni sono vere anche:
|
Indirizzo IP di destinazione |
|
uguale al valore predefinito:
|
Parametri di un probe di idoneità
Quando GKE crea il controllo di integrità per il backend del servizio GKE può copiare parametri specifici dall'infrastruttura di un container il probe di idoneità utilizzato dai pod di gestione di quel servizio. Questa opzione è solo supportate dal controller GKE Ingress.
Attributi supportati dei probe di idoneità che possono essere interpretati come controllo di integrità sono elencati insieme ai valori predefiniti in Predefinito e dedotto parametri. I valori predefiniti vengono utilizzati per qualsiasi attributo non specificato nel probe di idoneità o se non specifichi un probe di idoneità tutti.
Se i pod di gestione per il tuo servizio contengono più container o se stai
con il controller Ingress GKE Enterprise, è necessario usare un BackendConfig
CRD per definire i parametri del controllo di integrità. Per ulteriori informazioni, vedi Quando utilizzare un
BackendConfig
CRD.
Quando utilizzare invece i CRD BackendConfig
Anziché fare affidamento sui parametri dei probe di idoneità dei pod,
definire esplicitamente i parametri del controllo di integrità per un servizio di backend creando un
BackendConfig
CRD per il Servizio nelle seguenti situazioni:
- Se utilizzi GKE Enterprise: il controller Ingress GKE Enterprise
non supporta il recupero dei parametri del controllo di integrità dal recupero
dei pod di gestione. Può creare controlli di integrità solo usando
parametri o come definito in un
BackendConfig
CRD.
Se hai più di un container nei pod di gestione: GKE non dispone di un modo per selezionare il probe di idoneità di un container specifico da cui dedurre i parametri del controllo di integrità. Poiché ogni può avere un proprio probe di idoneità e, poiché un probe di idoneità non è parametro obbligatorio per un container, devi definire il controllo di integrità al servizio di backend corrispondente facendo riferimento a un
BackendConfig
CRD sul servizio corrispondente.Se hai bisogno di controllare la porta utilizzata per l'integrità del bilanciatore del carico Controlli: GKE utilizza solo i parametri del probe di idoneità
containers[].readinessProbe.httpGet.port
per il backend di controllo di integrità del servizio quando questa porta corrisponde alla porta del servizio Servizio a cui viene fatto riferimento nel traffico in entrataspec.rules[].http.paths[].backend.servicePort
.
Parametri di un CRD BackendConfig
Puoi specificare i parametri del controllo di integrità del servizio di backend utilizzando il metodo
Parametro healthCheck
di un BackendConfig
CRD a cui viene fatto riferimento
dal Servizio corrispondente. Questo ti offre maggiore flessibilità e controllo
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 sezione In entrata
configurazione per
Compatibilità delle versioni di GKE.
In questo esempio di CRD BackendConfig
definisce il protocollo del controllo di integrità (tipo), un
percorso della 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'integrità BackendConfig
verifica, utilizza
configurazione personalizzata del controllo di integrità
esempio.
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 di volere che un bilanciatore del carico HTTP(S) fornisca contenuti da due nomi host: tuo-negozio.example e tuo-negozio-sperimentale.example. Inoltre, devi anche utilizzare un certificato per your-store.example e un altro certificato per tuo-negozio-sperimentale.example.
Puoi farlo specificando più certificati in un manifest Ingress. La 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.
Servizio Kubernetes a confronto con il servizio di backend Google Cloud
Un cluster Kubernetes
Servizio
e un
Servizio di backend Google Cloud
sono cose diverse. C'è un
una forte relazione tra i due, ma non necessariamente
uno a uno. Il controller Ingress GKE crea un backend Google Cloud
servizio per ciascuna coppia (service.name
, service.port
) in un manifest Ingress. Quindi...
è possibile che un oggetto di servizio Kubernetes sia correlato a più Google Cloud
di backend.
Limitazioni
Nei cluster che utilizzano versioni precedenti alla 1.16, la lunghezza totale lo spazio dei nomi e il nome di una risorsa Ingress non devono superare i 40 caratteri. Mancata seguire queste linee guida può far sì che il controller GKE Ingress agire in modo anomalo. Per ulteriori informazioni, consulta questo problema di GitHub sui nomi lunghi.
Nei cluster che utilizzano NEG, il tempo di riconciliazione in entrata può essere influenzato dal numero di messaggi in entrata. Ad esempio, un cluster con 20 Ingress, ognuno contenente 20 backend NEG distinti, potrebbe comportare una latenza superiore a 30 minuti per la riconciliazione di una modifica in entrata. Questo influisce in particolare sui cluster a livello di regione a causa dell'aumento del numero di NEG necessari.
Si applicano le quote per le mappe URL.
Se non utilizzi i NEG con Controller in entrata GKE i cluster GKE hanno un limite di 1000 nodi. Quando i servizi vengono di cui è stato eseguito il deployment con NEG, non è previsto alcun limite di nodi GKE. Qualsiasi non NEG I servizi esposti tramite Ingress non funzionano correttamente sui cluster superiori 1000 nodi.
Per consentire al controller GKE Ingress di utilizzare
readinessProbes
come controlli di integrità, i pod per una risorsa Ingress devono esistere a livello momento della creazione di Ingress. Se le repliche sono scalate a 0, l'integrità predefinita la casella di controllo è valida. Per ulteriori informazioni, consulta questo commento su un problema di GitHub sui controlli di integrità.Le modifiche a
readinessProbe
di un pod non influiscono su Ingress dopo che è è stato creato.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 è necessario un controllo geografico su dove viene terminato il TLS, è necessario utilizzare un controller in entrata personalizzato tramite un servizio GKE di tipo
LoadBalancer
e terminare TLS sui backend che si trovano in regioni appropriate per il tuo e alle esigenze aziendali.Combina più risorse Ingress in un singolo bilanciatore del carico Google Cloud non è supportato.
Devi disattivare il protocollo TLS reciproca sulla tua applicazione perché non supportato per i bilanciatori del carico delle applicazioni esterni.
Cluster basati su route e Ingress esterno
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). Invece, il traffico in entrata
utilizza backend di gruppi di istanze non gestite che includono tutti i nodi
pool di nodi. Se questi gruppi di istanze non gestite vengono utilizzati anche da LoadBalancer
ai servizi, questo può causare problemi relativi
Limitazione del singolo gruppo di istanze con bilanciamento del carico.
Alcuni oggetti Ingress esterni meno recenti creati in VPC nativo
potrebbero utilizzare backend di gruppi di istanze sui servizi di backend
un bilanciatore del carico delle applicazioni
esterno che creano. Non è pertinente per il traffico interno in entrata perché
le risorse in entrata interne utilizzano sempre GCE_VM_IP_PORT
NEG e richiedono
di cluster VPC nativi.
Per scoprire come risolvere gli errori 502 relativi a un traffico in entrata esterno, consulta Una risorsa Ingress esterna produce 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. Questa viene visualizzata come
un
GET
del valoreBackendService
globale (inesistente) con il nomek8s-ingress-svc-acct-permission-check-probe
. Poiché questa risorsa non dovrebbe esistono normalmente, la richiestaGET
restituirà "non trovato". Si tratta di un comportamento previsto. il controller controlla che la chiamata API non sia stata rifiutata a causa dell'autorizzazione che le applicazioni presentino problemi di prestazioni. Se crei un oggetto BackendService con lo stesso nome,GET
andrà a buon fine invece di restituire il messaggio "non trovato".
Modelli per la configurazione di Ingress
- In GKE Networking Recipes: è possibile trovare modelli forniti da GKE in molti nella sezione In entrata.
Passaggi successivi
- Scopri di più sulle formule di networking di GKE
- Scopri di più sul bilanciamento del carico in Google Cloud.
- Leggi una panoramica del networking in GKE.
- Scopri come configurare Ingress per i bilanciatori del carico delle applicazioni interni.
- Scopri come configurare Ingress per i bilanciatori del carico delle applicazioni esterni.