Ingress GKE per i bilanciatori del carico delle applicazioni

Questa pagina fornisce una panoramica generale di Ingress per i bilanciatori del carico delle applicazioni 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 di Google Cloud per i carichi di lavoro HTTP(S) in GKE.

Panoramica

In GKE, un 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 è associato a un insieme di pod. Per scoprire di più su come Ingress espone le applicazioni utilizzando i servizi, consulta Panoramica del networking di 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 presenti nella risorsa Ingress e nei servizi associati.

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; non è necessario disabilitarlo.

In entrata per traffico esterno e interno

Le risorse GKE Ingress sono di due tipi:

Comportamento del controller GKE Ingress

Per i cluster che eseguono GKE versione 1.18 e successive, il fatto che il controller GKE Ingress elabori o meno una risorsa Ingress dipende dal valore dell'annotazione kubernetes.io/ingress.class:

kubernetes.io/ingress.class valore ingressClassName valore Comportamento del controller GKE Ingress
Non impostata Non impostata Elabora il manifest Ingress e crea un bilanciatore del carico delle applicazioni esterno.
Non impostata Qualsiasi valore Non effettua 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 bilanciatore del carico delle applicazioni esterno.
gce-internal Qualsiasi valore. Questo campo viene ignorato. Elabora il manifest Ingress e crea un bilanciatore del carico delle applicazioni interno.
Imposta un valore diverso da gce o gce-internal Qualsiasi valore Non effettua 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 risorsa Ingress senza l'annotazione kubernetes.io/ingress.class o con l'annotazione con il valore gce o gce-internal.

Ritiro dell'annotazione kubernetes.io/ingress.class

Anche se l'annotazione kubernetes.io/ingress.class è deprecata in Kubernetes, GKE continua a utilizzare questa annotazione.

Non puoi utilizzare il campo ingressClassName per specificare un traffico GKE Ingress. 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 le seguenti funzionalità:

  • 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, consulta Configurazione in entrata.

Bilanciamento del carico nativo del container

Il bilanciamento del carico nativo del container è la pratica di bilanciamento del carico direttamente con gli endpoint dei pod in GKE utilizzando i gruppi di endpoint di rete (NEG).

Quando si utilizzano i gruppi di istanze, i bilanciatori del carico di Compute Engine inviano il traffico agli IP delle VM come backend. L'esecuzione di container su VM, dove i container condividono la stessa interfaccia host, introduce alcune limitazioni:

  • Richiede 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 può risiedere 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, pertanto il bilanciamento del traffico non è ottimale.
  • È più probabile che eventi ambientali come la perdita di VM o pod causino una perdita di traffico intermittente a causa del doppio hop di traffico.

Con i NEG, il traffico viene bilanciato dal bilanciatore del carico direttamente all'IP del pod anziché attraversare l'IP della VM e il networking kube-proxy. Inoltre, vengono implementati gateway 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à nel cluster di Kubernetes. Ciò migliora la stabilità complessiva del traffico rendendo l'infrastruttura del bilanciatore del carico sensibile a eventi del ciclo di vita come l'avvio dei pod, la perdita di pod o la perdita di VM. Queste funzionalità risolvono i limiti di cui sopra e migliorano le prestazioni e la stabilità del networking.

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
  • 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, ti consigliamo vivamente di 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 in VPC condiviso, ma richiedono un'ulteriore preparazione.

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 Ingress 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 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:

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 risorsa Ingress fornisce la regola firewall specifica da aggiungere per fornire l'accesso.

Per eseguire manualmente il provisioning di una regola:

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

  2. Copia e applica le regole firewall suggerite dal progetto host. L'applicazione della regola fornisce l'accesso ai pod dal bilanciatore del carico e dai 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 e gestisca le risorse firewall nel progetto host, è necessario concedere all'account di servizio GKE del progetto di servizio le autorizzazioni IAM appropriate utilizzando una delle strategie seguenti:

  • 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 e compute.firewalls.delete. Concedi all'account di servizio GKE del progetto di servizio quel ruolo personalizzato al progetto host.

Se disponi di 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:

Più servizi di backend

Ogni bilanciatore del carico delle applicazioni esterno o bilanciatore del carico delle applicazioni 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 per instradare le richieste a diversi servizi di backend a seconda del percorso dell'URL. Le richieste inviate a your-store.example potrebbero essere instradate a un servizio di backend che mostra articoli a prezzo intero, mentre le richieste inviate a your-store.example/discounted potrebbero essere instradate a un servizio di backend che mostra articoli scontati.

Puoi anche configurare il bilanciatore del carico per instradare le richieste in base al nome host. Le richieste inviate a your-store.example potrebbero andare a un servizio di backend, mentre le richieste inviate a your-experimental-store.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, ognuno dei quali è associato a 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 la 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 presenti 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 al nome di dominio your-store.example. Quando un client invia una richiesta a your-store.example, questa viene instradata a un servizio Kubernetes denominato my-products sulla porta 60000. Quando un client invia una richiesta a your-store.example/discounted, questa viene instradata a un servizio Kubernetes denominato my-discounted-products sulla porta 80.

L'unico carattere jolly supportato per il campo path di un elemento 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 hai sia /foo/* sia /foo/bar/*, il valore /foo/bar/bat viene utilizzato per trovare /foo/bar/*.

Per maggiori informazioni sulle limitazioni dei percorsi e sulla corrispondenza dei pattern, consulta la 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 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 file manifest del servizio, il campo selector indica che qualsiasi pod con l'etichetta app: products e department: sales è membro di questo 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 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 file manifest del servizio, il campo selector indica che qualsiasi pod con l'etichetta app: discounted-products e department: sales è membro di questo 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 avere un container in ascolto sulla porta TCP 8080.

Backend predefinito

Puoi specificare un backend predefinito per la risorsa Ingress fornendo un campo spec.defaultBackend nel file manifest di 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 404. Viene creato come servizio NodePort default-http-backend 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 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 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 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à dei bilanciatori 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 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 come risultato dei Servizi my-discounted-products e my-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 distribuiti, rinnovati, 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 del certificato in un'annotazione su una risorsa Ingress per creare un bilanciatore del carico HTTP(S) che utilizza il certificato. Per saperne di più, 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 utilizza 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 Bilanciatore del carico delle applicazioni interno. Entrambi questi bilanciatori del carico supportano più servizi di backend su 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 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à per ciascun servizio di backend corrispondente a un servizio Kubernetes:

  • Se il servizio fa riferimento a un CRD BackendConfig con informazioni healthCheck, GKE la utilizza per creare il controllo di integrità. Sia il controller GKE Enterprise Ingress che il controller GKE Ingress supportano 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 controllo di integrità se i pod in uso utilizzano un modello di pod con un container il cui probe di idoneità contiene attributi che possono essere interpretati come parametri del controllo di integrità. Consulta Parametri di un probe di idoneità per i dettagli dell'implementazione e Parametri predefiniti e dedotti per un elenco di attributi che possono essere utilizzati per creare parametri del controllo di integrità. Solo il controller GKE Ingress supporta il deduzione di 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 del controllo di integrità, per creare il controllo di integrità vengono utilizzati i valori predefiniti. Sia il controller GKE Enterprise Ingress 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 del 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'oggetto spec del pod di pubblicazione:
containers[].readinessProbe.httpGet.path
Richiedi intestazione Host Host: backend-ip-address se presente nell'oggetto spec del pod di pubblicazione:
containers[].readinessProbe.httpGet.httpHeaders
Risposta prevista HTTP 200 (OK) HTTP 200 (OK)
non può essere modificato
Intervallo di controllo
  • per i NEG a livello di zona: 15 secondi
  • per i gruppi di istanze: 60 secondi
 se presente nell'oggetto spec del pod di pubblicazione:
  • per i NEG a livello di zona:
    containers[].readinessProbe.periodSeconds
  • per i gruppi di istanze:
    containers[].readinessProbe.periodSeconds + 60 seconds
Timeout controllo 5 secondi se presente nell'oggetto spec del pod di pubblicazione:
containers[].readinessProbe.timeoutSeconds
Soglia stato integro 1 1
non può essere modificato
Soglia stato non integro
  • per NEG a livello di zona: 2
  • per i gruppi di istanze: 10
 uguale a quello predefinito:
  • per 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: nodePort del servizio
 I probe del controllo di integrità vengono inviati al numero di porta specificato da spec.containers[].readinessProbe.httpGet.port, a condizione che tutte le seguenti condizioni siano vere:
  • Il numero di porta del probe di idoneità deve corrispondere a containers[].spec.ports.containerPort del pod di gestione
  • Il valore containerPort del pod di gestione corrisponde all'oggetto targetPort del servizio
  • La specifica della porta di backend del servizio in entrata fa riferimento a una porta valida da spec.ports[] del servizio. Questa operazione può essere eseguita in due modi:
    • spec.rules[].http.paths[].backend.service.port.name nella corrispondenza in entrata a spec.ports[].name definito nel servizio corrispondente
    • spec.rules[].http.paths[].backend.service.port.number nella corrispondenza in entrata a spec.ports[].port definito nel servizio corrispondente
Indirizzo IP di destinazione
  • per i NEG a livello di zona: l'indirizzo IP del pod
  • per i gruppi di istanze: l'indirizzo IP del nodo
 uguale a quello predefinito:
  • per i NEG a livello di zona: 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 probe di idoneità di un container utilizzato dai pod di gestione del servizio. Questa opzione è supportata solo dal controller GKE Ingress.

Gli attributi supportati del probe di idoneità che possono essere interpretati come parametri del 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 ne specifichi affatto.

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 invece un CRD BackendConfig.

Quando utilizzare invece i CRD BackendConfig

Anziché fare affidamento sui parametri dei probe di idoneità dei pod, devi definire esplicitamente i parametri del controllo di integrità per un servizio di backend creando un CRD BackendConfig per il servizio in queste situazioni:

  • Se utilizzi GKE Enterprise: il controller Ingress GKE Enterprise non supporta il recupero dei parametri del controllo di integrità dai probe di idoneità dei pod di gestione. Può creare controlli di integrità solo utilizzando parametri impliciti o come definito in un CRD BackendConfig.

  • Se hai più di un container nei pod di gestione: GKE non ha modo di 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 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 hai bisogno di controllare la porta utilizzata per i controlli di integrità del bilanciatore del carico: GKE utilizza il valore containers[].readinessProbe.httpGet.port del probe di idoneità per il controllo di integrità del servizio di backend solo quando questa porta corrisponde alla porta del servizio per il servizio a cui viene fatto riferimento in Ingress spec.rules[].http.paths[].backend.servicePort.

Parametri di un CRD BackendConfig

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. Ciò 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 un traffico in entrata. Consulta la pagina relativa alla configurazione in entrata per la compatibilità delle versioni di GKE.

In questo esempio di CRD BackendConfig viene definito il protocollo (tipo), un percorso di richiesta, una porta e un intervallo di controllo nel suo 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 della 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 un bilanciatore del carico HTTP(S) pubblichi contenuti da due nomi host: your-store.example e your-experimental-store.example. Inoltre, il bilanciatore del carico deve utilizzare un certificato per your-store.example e un altro certificato per your-experimental-store.example.

Puoi farlo specificando 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.

Servizio Kubernetes a confronto con il servizio di backend Google Cloud

Un servizio Kubernetes e un servizio di backend di Google Cloud sono due cose diverse. Esiste una forte relazione tra i due, ma non è necessariamente 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, un oggetto del servizio Kubernetes può essere correlato a diversi 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. Il mancato seguimento di questa linea guida può causare un comportamento anomalo del controller GKE Ingress. 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, ciascuno contenente 20 backend NEG distinti, potrebbe causare una latenza di oltre 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.

  • Si applicano quote per le risorse di Compute Engine.

  • Se non utilizzi NEG con il controller in entrata GKE, i cluster GKE hanno un limite di 1000 nodi. Quando si esegue il deployment dei servizi con NEG, non è previsto alcun limite di nodi GKE. Tutti i servizi non NEG esposti tramite Ingress non funzionano correttamente su cluster sopra i 1000 nodi.

  • Affinché il controller GKE Ingress utilizzi readinessProbes come controlli di integrità, i pod per una risorsa Ingress devono esistere al momento della creazione di Ingress. Se le repliche sono scalate a 0, si applica il controllo di integrità predefinito. 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 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 del controllo geografico sulla posizione in cui viene terminato TLS, devi utilizzare invece un controller in entrata personalizzato esposto tramite un servizio GKE di tipo LoadBalancer e terminare TLS sui backend che si trovano in regioni appropriate alle tue esigenze.

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

  • Devi disattivare TLS comune sull'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 usando GCE_VM_IP_PORT gruppi di endpoint di rete (NEG). Il controller Ingress utilizza invece backend di gruppi di istanze non gestite che includono tutti i nodi in tutti i pool di nodi. Se questi gruppi di istanze non gestite vengono utilizzati anche dai servizi LoadBalancer, potrebbero verificarsi problemi relativi alla limitazione del singolo gruppo di istanze con bilanciamento del carico.

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

Per scoprire come risolvere gli errori 502 relativi a un traffico Ingress esterno, consulta La 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. Verrà visualizzato come un GET del valore BackendService globale (inesistente) con il nome k8s-ingress-svc-acct-permission-check-probe. Poiché questa risorsa in genere non dovrebbe esistere, la richiesta GET restituirà "non trovato". 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, GET avrà esito positivo anziché restituire "not found".

Modelli per la configurazione di Ingress

Passaggi successivi