GKE Ingress per i bilanciatori del carico delle applicazioni

Questa pagina fornisce una panoramica generale di che cos'è Ingress per i bilanciatori del carico delle applicazioni esterni e di come funziona. 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.

Questa pagina è rivolta agli esperti di networking che progettano e progettano la rete per la propria organizzazione e installano, configurano e supportano le apparecchiature di rete. Per approfondire i ruoli comuni e le attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

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 Service, ciascuno associato a un insieme di pod. Per scoprire di più su come Ingress espone le applicazioni che utilizzano i servizi, consulta la panoramica della rete di servizi.

Quando crei un oggetto Ingress, il controller Ingress di GKE crea un bilanciatore del carico HTTP(S) di Google Cloud e lo configura in base alle informazioni di Ingress e dei servizi associati.

Per utilizzare Ingress, devi aver attivato il componente aggiuntivo per il bilanciamento del carico HTTP. Il bilanciamento del carico HTTP è abilitato per impostazione predefinita nei cluster GKE. Non devi disattivarlo.

Ingress per il traffico esterno e interno

Le risorse GKE Ingress sono di due tipi:

Comportamento del controller GKE Ingress

Per i cluster che eseguono GKE 1.18 e versioni successive, il fatto che il controller Ingress GKE elabori 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 di Ingress e crea un bilanciatore del carico delle applicazioni esterno.
Non impostato Qualsiasi valore Non interviene. Il manifest di 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 di Ingress e crea un bilanciatore del carico delle applicazioni esterno.
gce-internal Qualsiasi valore. Questo campo viene ignorato. Elabora il manifest di 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 di 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 abbia l'annotazione kubernetes.io/ingress.class o che abbia l'annotazione con il valore gce o gce-internal.

Ritiro delle annotazioni kubernetes.io/ingress.class

Sebbene l'annotazione kubernetes.io/ingress.class sia stata ritirata in Kubernetes, GKE continua a utilizzarla.

Non puoi utilizzare il campo ingressClassName per specificare un Ingress GKE. Devi utilizzare l'annotazione kubernetes.io/ingress.class.

Funzionalità dei bilanciatori del carico delle applicazioni esterni

Un bilanciatore del carico delle applicazioni esterno, configurato da Ingress, include le seguenti funzionalità:

  • Configurazione flessibile per i servizi. Un Ingress definisce in che modo il traffico raggiunge i tuoi servizi e come viene indirizzato alla tua applicazione. Inoltre, un Ingress può fornire un unico 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'utilizzo di più certificati TLS per la terminazione delle richieste.

Per un elenco completo, consulta Configurazione di Ingress.

Bilanciamento del carico nativo del container

Il bilanciamento del carico nativo del container è la pratica del bilanciamento del carico direttamente agli 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 VM come backend. L'esecuzione di container su VM, in cui i container condividono la stessa interfaccia host, introduce alcune limitazioni:

  • Sono previsti due hop di bilanciamento del carico: un hop dal bilanciatore del carico alla VM NodePort e un altro hop tramite il routing di kube-proxy all'IP del pod (che può risiedere su una VM diversa).
  • Gli hop aggiuntivi aumentano la latenza e rendono il percorso del traffico più complesso.
  • Il bilanciatore del carico di 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 una perdita intermittente del traffico a causa del doppio hop del traffico.

Con i NEG, il traffico viene bilanciato dal bilanciatore del carico direttamente all'IP del pod anziché attraversare l'IP della VM e la rete kube-proxy. Inoltre, vengono implementati i cancelli di idoneità dei pod per determinare l'integrità dei pod dal punto di vista del bilanciatore del carico e non solo dei probe di integrità in-cluster di Kubernetes. In questo modo, viene migliorata la stabilità complessiva del traffico rendendo l'infrastruttura del bilanciatore del carico consapevole degli eventi del ciclo di vita come l'avvio del pod, la perdita del pod o la perdita della VM. Queste funzionalità risolvono le limitazioni sopra indicate e consentono una rete più performante e stabile.

Il bilanciamento del carico nativo del container è abilitato per impostazione predefinita per i servizi se vengono soddisfatte tutte le seguenti condizioni:

  • Per i servizi creati nei cluster GKE 1.17.6-gke.7 e versioni successive
  • Utilizzo di cluster nativi di VPC
  • Non utilizzare un VPC condiviso
  • Non utilizzare i criteri di rete di GKE

In queste condizioni, i servizi verranno annotati automaticamente con cloud.google.com/neg: '{"ingress": true}' per indicare che deve essere creato un NEG per eseguire il mirroring degli IP dei pod all'interno del servizio. Il NEG 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 dei servizi.

Per GKE 1.17.6-gke.7 e versioni precedenti, in cui l'annotazione NEG è automatica, è possibile disattivare i NEG e forzare il bilanciatore del carico esterno di Compute Engine a utilizzare un gruppo di istanze come backend, se necessario. Questo può essere fatto annotando esplicitamente i servizi con cloud.google.com/neg: '{"ingress": false}'. Non è possibile disattivare i NEG con Ingress per i bilanciatori del carico delle applicazioni interni.

Per i cluster in cui i gruppi di istanze elastiche non sono predefiniti, è comunque vivamente consigliato utilizzare il bilanciamento del carico nativo dei container, ma deve essere attivato 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 Ingress e MultiClusterIngress sono supportate in 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 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 di ingress non può utilizzare l'account 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 del firewall VPC nel progetto host. Con la concessione di queste autorizzazioni, GKE crea regole firewall di autorizzazione in entrata per quanto segue:

Esegui il provisioning manuale delle regole del firewall dal progetto host

Se i tuoi criteri di sicurezza consentono la gestione del firewall solo dal progetto host, puoi eseguire il provisioning di queste regole firewall manualmente. Quando esegui il deployment di Ingress in un VPC condiviso, l'evento della risorsa Ingress fornisce la regola firewall specifica che devi aggiungere per fornire l'accesso.

Per eseguire il provisioning manuale di una regola:

  1. Visualizza l'evento della risorsa Ingress:

    kubectl describe ingress INGRESS_NAME

    Sostituisci INGRESS_NAME con il nome dell'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 richiesta suggerita viene visualizzata nella colonna Message.

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

Fornire all'autorizzazione del controller GKE Ingress l'autorizzazione per gestire le regole firewall del progetto host

Se vuoi che un cluster GKE in un progetto di servizio crei e gestisca le risorse della 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 della sicurezza di Compute al progetto host. L'esempio seguente dimostra 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, compute.firewalls.delete e compute.subnetworks.list. Concedi al progetto di account di servizio GKE questo ruolo personalizzato al progetto host.

Se hai cluster in più di un progetto di servizio, devi scegliere una delle strategie e ripeterla per ogni account di servizio GKE del 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:

Più servizi di backend

Ogni bilanciatore del carico delle applicazioni esterno o 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'Ingress.

Ad esempio, puoi configurare il bilanciatore del carico in modo da instradare le richieste a diversi servizi di backend a seconda del percorso dell'URL. Le richieste inviate a tuo-negozio.example potrebbero essere inoltrate a un servizio di backend che mostra gli articoli a prezzo pieno, mentre le richieste inviate a tuo-negozio.example/scontato potrebbero essere inoltrate a un servizio di backend che mostra gli articoli scontati.

Puoi anche configurare il bilanciatore del carico in modo da instradare le richieste in base al nome host. Le richieste inviate a tuo-negozio.example potrebbero andare a un servizio di backend, mentre quelle inviate a tuo-negozio-sperimentale.example potrebbero andare a un altro servizio di backend.

In un cluster GKE, crei e configuri un bilanciatore del carico HTTP(S) creando un oggetto Kubernetes Ingress. Un oggetto Ingress deve essere associato a uno o più oggetti Service, ciascuno associato a un insieme di pod.

Se vuoi configurare GKE Ingress con più backend per lo stesso host, devi avere una singola regola con un singolo host e più percorsi. In caso contrario, il controller di ingress GKE esegue il provisioning di un solo servizio di backend

Ecco un manifest per un Ingress chiamato my-ingress:

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

Quando crei l'elemento Ingress, il controller Ingress di GKE crea e configura un bilanciatore del carico delle applicazioni esterno o interno in base alle informazioni in 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 al nome di dominio tuo-negozio.example. Quando un client invia una richiesta al tuo negozio, la richiesta viene indirizzata a un servizio Kubernetes denominato my-products sulla porta 60000. Quando un client invia una richiesta a your-store.example/discounted, la richiesta viene inoltrata a un servizio Kubernetes nominato my-discounted-products sulla porta 80.

L'unico carattere jolly supportato per il campo path di un 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, ma *, /foo/bar* e /foo/*/bar non lo sono.

Un pattern più specifico ha la precedenza su uno meno specifico. Se hai sia /foo/* che /foo/bar/*, /foo/bar/bat viene considerato corrispondente a /foo/bar/*.

Per ulteriori informazioni sulle limitazioni dei percorsi e sulla corrispondenza dei pattern, consulta la documentazione di URL Maps.

Il manifest per il 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 file manifest del servizio, devi utilizzare type: NodePort, a meno che tu non stia utilizzando 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 l'etichetta app: products e l'etichetta department: sales è membro di questo servizio.

Quando una richiesta arriva al servizio sulla porta 60000, viene inoltrata a uno dei pod membri sulla porta TCP 50000.

Ogni pod membro deve avere un container in ascolto sulla porta TCP 50000.

Il manifest per il 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 l'etichetta app: discounted-products e l'etichetta department: sales è membro di questo servizio.

Quando una richiesta arriva al servizio sulla porta 80, viene inoltrata a uno dei pod membri 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 Ingress fornendo un campo spec.defaultBackend nel manifest Ingress. In questo modo verranno gestite 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 ne fornisce uno che restituisce 404. Viene creato come servizio default-http-backend NodePort 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.

Mappature di Ingress alle risorse Compute Engine

Il controller Ingress di GKE esegue il deployment e la gestione delle risorse di bilanciamento del carico di Compute Engine in base alle risorse Ingress di cui è stato 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 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 front-end Google 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 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 in seguito ai servizi my-discounted-products e my-products.

Opzioni per la fornitura di 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 eseguiti il provisioning, il deployment, il rinnovo e la gestione 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 del certificato nel tuo progetto Google Cloud. Puoi quindi elencare la risorsa del certificato in un'annotazione su un Ingress per creare un bilanciatore del carico HTTP(S) che utilizzi il certificato. Per ulteriori informazioni, consulta le istruzioni per i certificati precompartiti.
Certificati autogestiti come risorse Secret
Puoi eseguire il provisioning del tuo certificato SSL e creare un Secret per conservarlo. Puoi quindi fare riferimento al segreto in una specifica Ingress per creare un bilanciatore del carico HTTP(S) che utilizzi il certificato. Per ulteriori informazioni, consulta le istruzioni per l'utilizzo dei certificati in Secrets.

Controlli di integrità

Quando esponi uno o più servizi tramite un 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 in un'unica 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 idoneità Kubernetes perché viene implementato al di fuori del cluster.

I controlli di integrità del bilanciatore del carico vengono specificati per servizio di backend. Anche se è possibile utilizzare lo stesso controllo di integrità per tutti i servizi di backend del bilanciatore del carico, il riferimento al controllo di integrità non è specificato per l'intero bilanciatore del carico (nell'oggetto Ingress stesso).

GKE crea controlli di integrità in base a uno dei seguenti metodi:

  • BackendConfig CRD: una definizione di risorsa personalizzata (CRD) che ti consente di controllare con precisione il modo in cui i tuoi servizi interagiscono con il bilanciatore del carico. Le CRD BackendConfig ti consentono di specificare impostazioni personalizzate per il controllo di stato associato al servizio di backend corrispondente. Queste impostazioni personalizzate offrono maggiore flessibilità e controllo sui controlli di integrità sia per l'Application Load Balancer classico sia per l'Application Load Balancer interno creato da un Ingress.
  • Probe di idoneità: un controllo diagnostico che determina se un container all'interno di un pod è pronto a gestire il traffico. Il controller Ingress di GKE crea il controllo di integrità per il servizio di backend del servizio in base al probe di idoneità utilizzato dai pod di servizio. Puoi ricavare i parametri di controllo di integrità, come percorso, porta e protocollo, dalla definizione del probe di idoneità.
  • Valori predefiniti: i parametri utilizzati quando non configuri un BackendConfig CRD o non definisci gli attributi per il test di idoneità.
Best practice:

Utilizza un BackendConfig CRD per avere il massimo controllo sulle impostazioni del controllo di integrità del bilanciatore del carico.

GKE utilizza la seguente procedura per creare un controllo di integrità per ogni servizio di backend corrispondente a un servizio Kubernetes:

  • Se il servizio fa riferimento a un BackendConfig CRD con informazioni su healthCheck, GKE lo utilizza per creare il controllo di stato. Sia il controller Ingress di GKE Enterprise sia il controller GKE Ingress supportano la creazione di controlli di integrità in questo modo.

  • Se il servizio non fa riferimento a una BackendConfig CRD:

    • 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 contenitore la cui verifica di idoneità ha attributi che possono essere interpretati come parametri di controllo di integrità. Consulta Parametri di un controllo di idoneità per dettagli sull'implementazione e Parametri predefiniti e dedotti per un elenco di attributi che possono essere utilizzati per creare parametri di controllo di integrità. Solo il controller GKE Ingress supporta la deduzione dei parametri da un controllo di idoneità.

    • Se il modello di pod per i pod di servizio in esecuzione non ha un contenitore con un controllo di idoneità i cui attributi possono essere interpretati come parametri di controllo di integrità, vengono utilizzati i valori predefiniti per creare il controllo di integrità. Sia il controller Ingress di GKE Enterprise sia il controller Ingress di GKE possono creare un controllo di integrità utilizzando solo i valori predefiniti.

Parametri predefiniti e dedotti

I seguenti parametri vengono utilizzati quando non specifichi i parametri di controllo di integrità'integrità per il Servizio corrispondente utilizzando un BackendConfig .

Parametro del controllo di integrità Valore predefinito Valore deducibile
Protocollo HTTP se presente nell'annotazione del servizio cloud.google.com/app-protocols
Percorso richiesta / Se presente in spec:
del pod in uso: containers[].readinessProbe.httpGet.path
Intestazione Host della richiesta Host: backend-ip-address se presente in spec:
del pod in uso containers[].readinessProbe.httpGet.httpHeaders
Risposta prevista HTTP 200 (OK) Impossibile modificare il codice HTTP 200 (OK)
Intervallo di controllo
  • per i NEG a livello di zona: 15 secondi
  • Per i gruppi di istanze: 60 secondi
 Se presente in spec del pod in uso:
  • per i NEG a livello di zona:
    containers[].readinessProbe.periodSeconds
  • per i gruppi di istanze:
    containers[].readinessProbe.periodSeconds + 60 seconds
Timeout del controllo 5 secondi Se presente in spec:
del pod in uso: containers[].readinessProbe.timeoutSeconds
Soglia di stato integro 1 1
non può essere modificato
Soglia di stato non integro
  • per i NEG a livello di zona: 2
  • per i gruppi di istanze: 10
 come predefinito:
  • per i NEG a livello di zona: 2
  • per i gruppi di istanze: 10
Specifiche della porta
  • Per i NEG a livello di zona: port del Servizio
  • Per i gruppi di istanze: il nodePort del servizio
 I controlli di integrità vengono inviati al numero di porta specificato da spec.containers[].readinessProbe.httpGet.port, a condizione che siano vere anche tutte le seguenti condizioni:
  • Il numero di porta del controllo di idoneità deve corrispondere a quello del pod di pubblicazione. containers[].spec.ports.containerPort
  • containerPort del pod in uso corrisponde a targetPort del servizio
  • La specifica della porta del backend del servizio Ingress fa riferimento a una porta valida di spec.ports[] del servizio. Puoi eseguire questa operazione in due modi:
    • spec.rules[].http.paths[].backend.service.port.name nell'Ingress corrisponde a spec.ports[].name definito nel Servizio corrispondente
    • spec.rules[].http.paths[].backend.service.port.number nell'Ingress corrisponde a spec.ports[].port definito nel Servizio corrispondente
Indirizzo IP di destinazione
  • per i NEG zonali: l'indirizzo IP del pod
  • Per i gruppi di istanze: l'indirizzo IP del nodo
 come predefinito:
  • per i NEG zonali: l'indirizzo IP del pod
  • Per i gruppi di istanze: l'indirizzo IP del nodo

Parametri di un probe di idoneità

Quando GKE crea il controllo di integrità per il servizio di backend del servizio, può copiare determinati parametri dal controllo di idoneità di un contenitore utilizzato dai pod di servizio. Questa opzione è supportata solo dal controller Ingress di GKE.

Gli attributi di verifica di idoneità supportati che possono essere interpretati come parametri di controllo di integrità dell'integrità sono elencati insieme ai valori predefiniti in Parametri predefiniti e dedotti. I valori predefiniti vengono utilizzati per tutti gli attributi non specificati nel test di idoneità o se non specifichi affatto un test di idoneità.

Se i pod di gestione per il tuo servizio contengono più container o se utilizzi il controller Ingress GKE Enterprise, devi utilizzare una CRD BackendConfig per definire i parametri del controllo di integrità. Per ulteriori informazioni, consulta Quando utilizzare un'BackendConfig CRD.

Quando utilizzare invece i BackendConfig CRD

Anziché fare affidamento sui parametri dei controlli di idoneità dei pod, devi definire esplicitamente i parametri di 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 di GKE Enterprise non supporta l'ottenimento dei parametri di controllo di integrità dell'integrità dalle prove di idoneità dei pod di servizio. Può creare controlli di integrità solo utilizzando parametri impliciti o come definito in un BackendConfig CRD.

  • Se hai più di un container nei pod di pubblicazione: GKE non ha un modo per selezionare il controllo di idoneità di un container specifico da cui dedurre i parametri di controllo di integrità dell'integrità. Poiché ogni container può avere il proprio probe di idoneità e poiché 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 devi controllare la porta utilizzata per i controlli di integrità del bilanciatore del carico: GKE utilizza il valore containers[].readinessProbe.httpGet.port del controllo di idoneità solo per il controllo di integrità del servizio di backend quando la porta corrisponde alla porta del servizio a cui fa riferimento il servizio Ingressspec.rules[].http.paths[].backend.servicePort.

Parametri di un BackendConfig CRD

Puoi specificare i parametri del controllo di integrità del servizio di backend utilizzando il parametro healthCheck di un BackendConfig CRD a cui fa riferimento il servizio corrispondente. In questo modo, puoi avere 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 un Ingress. Consulta la configurazione in entrata per la compatibilità con le versioni di GKE.

Questo esempio di BackendConfig CRD definisce il protocollo (tipo) del controllo di integrità, 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 controllo di integrità BackendConfig, utilizza l'esempio di configurazione del controllo di integrità personalizzato.

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: tuo-negozio.example e tuo-negozio-sperimentale.example. Inoltre, vuoi che il bilanciatore del carico utilizzi un certificato per il tuo-store.example e un altro per il tuo-store-sperimentale.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 Utilizzare più certificati SSL nel bilanciamento del carico HTTPS con Ingress.

Servizio Kubernetes rispetto al servizio di backend Google Cloud

Un servizio Kubernetes e un servizio di backend Google Cloud sono cose diverse. Esiste una relazione molto stretta tra i due, ma non necessariamente uno a uno. Il controller ingress di GKE crea un servizio di backend Google Cloud per ogni coppia (service.name, service.port) in un manifest di Ingress. Pertanto, è possibile che un oggetto Kubernetes Service sia correlato a diversi servizi di backend Google Cloud.

Limitazioni

  • Nei cluster che utilizzano versioni precedenti alla 1.16, la lunghezza totale dello spazio dei nomi e del nome di un Ingress non deve superare i 40 caratteri. Il mancato rispetto di queste linee guida potrebbe causare un comportamento anomalo del controller Ingress GKE. Per ulteriori informazioni, consulta questo problema di GitHub relativo ai nomi lunghi.

  • Nei cluster che utilizzano i gruppi di negazioni, il tempo di riconciliazione degli ingressi può essere influenzato dal numero di ingressi. Ad esempio, un cluster con 20 ingressi, ciascuno contenente 20 backend NEG distinti, potrebbe comportare una latenza di oltre 30 minuti per la riconciliazione di una modifica all'ingresso. Ciò influisce in modo particolare sui cluster regionali a causa dell'aumento del 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 eseguiti 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 Ingress di GKE utilizzi il tuo readinessProbes come controlli di integrità, i pod per un Ingress devono esistere al momento della creazione di Ingress. Se le repliche sono scalate a 0, viene applicato il controllo di stato predefinito. Per ulteriori informazioni, consulta questo commento relativo a un problema di GitHub sui controlli di integrità.

  • Le modifiche a readinessProbe di un pod non influiscono sull'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 posizione in cui viene terminato TLS, devi utilizzare un controller di ingresso personalizzato esposto tramite un servizio GKE di tipo LoadBalancer e terminare TLS sui backend che si trovano nelle regioni appropriate alle tue esigenze.

  • La combinazione di più risorse Ingress in un unico bilanciatore del carico Google Cloud non è supportata.

  • Devi disattivare l'autenticazione TLS reciproca nella tua applicazione perché non è supportata per i bilanciatori del carico delle applicazioni esterni.

Ingresso 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 GCE_VM_IP_PORT gruppi di endpoint di rete (NEG). Il controller Ingress utilizza invece i backend dei gruppi di istanze non gestite che includono tutti i nodi di tutti i pool di nodi. Se questi gruppi di istanze non gestiti vengono utilizzati anche da LoadBalancer Services, possono verificarsi problemi relativi alla limitazione del gruppo di istanze con bilanciamento del carico singolo.

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

Per scoprire come risolvere i problemi relativi agli errori 502 con Ingress esterno, consulta Ingress esterno genera errori HTTP 502.

Dettagli sull'implementazione

  • Il controller Ingress esegue controlli periodici delle autorizzazioni degli account di servizio recuperando una risorsa di test dal progetto Google Cloud. Vedrai questo come un GET del BackendService globale (inesistente) con il nome k8s-ingress-svc-acct-permission-check-probe. Poiché questa risorsa non dovrebbe normalmente esistere, la richiesta GET restituirà "non trovato". Questo è normale. Il controller sta verificando che la chiamata API non venga rifiutata a causa di problemi di autorizzazione. Se crei un BackendService con lo stesso nome, la chiamata GET andrà a buon fine anziché restituire "not found".

Modelli per la configurazione di Ingress

Passaggi successivi