Configurazione in entrata su Google Cloud


Questa pagina fornisce una panoramica completa di ciò che è supportato e configurabile tramite Kubernetes Ingress su Google Cloud.

Confronto delle funzionalità

La tabella seguente fornisce un elenco di funzionalità supportate per Ingress su Google Cloud. È indicata anche la disponibilità della funzionalità Disponibilità generale (GA) o Beta.

Classe in entrata Ingress esterno Ingress interno Ingress multi-cluster
Controller Ingress Controller Ingress ospitato da Google Controller GKE Ingress
Tipo di bilanciatore del carico Google Cloud Bilanciatore del carico HTTP(S) esterno Bilanciatore del carico HTTP(S) interno Bilanciatore del carico HTTP(S) esterno
Ambito cluster Cluster singolo Cluster singolo Cluster multipli
Ambito del bilanciatore del carico Globale Regionale Globale
Assistenza per l'ambiente GKE GKE GKE
Supporto di VPC condivisi GA GA GA
Annotazioni del servizio
Bilanciamento del carico (NEG) nativo del container GA GA GA
HTTPS dal bilanciatore del carico ai backend GA GA GA
HTTP/2 GA GA
Solo TLS
GA
Annotazioni Ingress
Indirizzi IP statici GA GA GA
Certificati basati su secret di Kubernetes GA GA GA
Certificati SSL con gestione indipendente GA GA GA
Certificati SSL gestiti da Google GA GA
FrontendConfig
Criterio SSL GA GA con gateway GA
Reindirizzamento da HTTP a HTTPS GA
1.17.13-gke.2600 e versioni successiveGA
GA
BackendConfig
Timeout del servizio di backend GA GA GA
Cloud CDN GA GA
Timeout per svuotamento della connessione GA GA GA
Configurazione personalizzata del controllo di integrità del bilanciatore del carico GA GA GA
Criterio di sicurezza di Google Cloud Armor GA
1.19.10-gke.700G
GA
Configurazione del logging degli accessi HTTP GA GA GA
Identity-Aware Proxy (IAP) GA GA GA
Affinità sessione GA GA GA
Intestazioni delle richieste definite dall'utente GA GA
Intestazioni delle risposte personalizzate GA
1.25-gke+G
GA
1.25-gke+G

B Questa funzionalità è disponibile in versione beta a partire dalla versione specificata. Le funzionalità senza una versione elencata sono supportate per tutte le versioni GKE disponibili.

G Questa funzionalità è supportata in disponibilità generale a partire dalla versione specificata.

Configurazione di Ingress mediante il controller predefinito

Non puoi configurare manualmente le funzionalità di LoadBalancer utilizzando Google Cloud SDK o la console Google Cloud. Devi usare le risorse Kubernetes BackendConfig o FrontendConfig.

Quando crei una risorsa Ingress mediante il controller predefinito, puoi scegliere il tipo di bilanciatore del carico (un bilanciatore del carico delle applicazioni esterno o un bilanciatore del carico delle applicazioni interno) utilizzando un'annotazione sull'oggetto Ingress. Puoi scegliere se GKE crea NEG a livello di zona o se utilizza gruppi di istanze usando un'annotazione su ciascun oggetto di servizio.

Le definizioni delle risorse personalizzate (CRD) di FrontendConfig e BackendConfig ti consentono di personalizzare ulteriormente il bilanciatore del carico. Questi CRD consentono di definire funzionalità aggiuntive del bilanciatore del carico in modo gerarchico, in modo più strutturato rispetto alle annotazioni. Per utilizzare Ingress (e questi CRD), devi avere il componente aggiuntivo per il bilanciamento del carico HTTP abilitato. Nei cluster GKE il bilanciamento del carico HTTP è abilitato per impostazione predefinita; non occorre disabilitarlo.

Ai frontendConfig viene fatto riferimento in un oggetto Ingress e possono essere utilizzati solo con risorse Ingress esterne. Le configurazioni BackendConfig sono indicate da un oggetto Service. Più oggetti Service o Ingress possono fare riferimento agli stessi CRD per coerenza della configurazione. I CRD FrontendConfig e BackendConfig condividono lo stesso ciclo di vita delle risorse Ingress e di servizio corrispondenti e il loro deployment viene spesso eseguito insieme.

Il seguente diagramma illustra come:

  • Un'annotazione su un oggetto Ingress o MultiClusterIngress fa riferimento a un CRD FrontendConfig. Il CRD FrontendConfig fa riferimento a un criterio SSL di Google Cloud.

  • Un'annotazione su un oggetto Service o MultiClusterService fa riferimento a un CRD BackendConfig. Il CRD BackendConfig specifica le impostazioni personalizzate per il controllo di integrità del servizio di backend corrispondente.

Panoramica di BackendConfig e FrontendConfig
Figura: panoramica di BackendConfig e FrontendConfig

Associazione di FrontendConfig alla tua risorsa Ingress

FrontendConfig può essere utilizzato solo con risorse Ingress esterne.

Puoi associare un FrontendConfig a una risorsa Ingress o a un MultiClusterIngress.

In entrata

Utilizza l'annotazione networking.gke.io/v1beta1.FrontendConfig:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"
...

Sostituisci FRONTENDCONFIG_NAME con il nome di FrontendConfig.

MultiClusterIngress

Utilizza l'annotazione networking.gke.io/frontend-config:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  annotations:
    networking.gke.io/frontend-config: "FRONTENDCONFIG_NAME"
...

Sostituisci FRONTENDCONFIG_NAME con il nome di FrontendConfig.

Associazione BackendConfig al tuo Ingress

Puoi utilizzare l'annotazione cloud.google.com/backend-config o beta.cloud.google.com/backend-config per specificare il nome di un BackendConfig.

Stessa BackendConfig per tutte le porte di servizio

Per utilizzare lo stesso BackendConfig per tutte le porte, utilizza la chiave default nell'annotazione. Il controller Ingress utilizza lo stesso BackendConfig ogni volta che crea un servizio di backend del bilanciatore del carico per fare riferimento a una delle porte del servizio.

Puoi utilizzare la chiave default sia per le risorse Ingress che per MultiClusterIngress.
apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

BackendConfig univoco per porta del servizio

Per Ingress e MultiClusterIngress, puoi specificare un BackendConfig personalizzato per una o più porte utilizzando una chiave che corrisponda al nome o al numero della porta. Il controller Ingress utilizza lo specifico BackendConfig quando crea un servizio di backend del bilanciatore del carico per una porta del servizio di riferimento.

GKE 1.16-gke.3 e versioni successive

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
    "SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Tutte le versioni supportate

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
      PORT_NAME_1:"BACKENDCONFIG_REFERENCE_A",
      PORT_NAME_2:"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Sostituisci quanto segue:

  • BACKENDCONFIG_REFERENCE_A: il nome di una BackendConfig esistente.
  • BACKENDCONFIG_REFERENCE_B: il nome di una BackendConfig esistente.
  • SERVICE_REFERENCE_A: utilizza il valore PORT_NUMBER_1 o PORT_NAME_1. Questo perché l'annotazione BackendConfig di un servizio può fare riferimento al nome della porta (spec.ports[].name) o al numero della porta (spec.ports[].port).
  • SERVICE_REFERENCE_B: utilizza il valore PORT_NUMBER_2 o PORT_NAME_2. Questo perché l'annotazione BackendConfig di un servizio può fare riferimento al nome della porta (spec.ports[].name) o al numero della porta (spec.ports[].port).

Quando fai riferimento alla porta del servizio per numero, devi utilizzare il valore port anziché il valore targetPort. Il numero di porta utilizzato qui serve solo per associare BackendConfig; non controlla la porta a cui il bilanciatore del carico invia il traffico o i probe del controllo di integrità:

  • Quando utilizzi il bilanciamento del carico nativo del container, il bilanciatore del carico invia il traffico a un endpoint in un gruppo di endpoint di rete (corrispondente all'indirizzo IP di un pod) sulla targetPort della porta del servizio a cui viene fatto riferimento (che deve corrispondere a un containerPort per un pod di gestione). In caso contrario, il bilanciatore del carico invia il traffico all'indirizzo IP di un nodo sull'nodePort della porta del servizio a cui viene fatto riferimento.

  • Quando si utilizza un oggetto BackendConfig per fornire un controllo di integrità personalizzato del bilanciatore del carico, il numero di porta utilizzato per il controllo di integrità del bilanciatore del carico può essere diverso dal numero spec.ports[].port del servizio. Per maggiori dettagli sui numeri di porta per i controlli di integrità, vedi Configurazione del controllo di integrità personalizzato.

Configurazione di funzionalità Ingress tramite i parametri FrontendConfig

La seguente sezione mostra come impostare FrontendConfig per abilitare funzionalità Ingress specifiche.

Criteri SSL

I criteri SSL consentono di specificare un insieme di versioni TLS e crittografie che il bilanciatore del carico utilizza per terminare il traffico HTTPS dai client. Devi prima creare un criterio SSL all'esterno di GKE. Una volta creato, puoi farvi riferimento in un CRD FrontendConfig.

Il campo sslPolicy di FrontendConfig fa riferimento al nome di un criterio SSL nello stesso progetto Google Cloud del cluster GKE. Collega il criterio SSL al proxy HTTPS di destinazione, che è stato creato per il bilanciatore del carico HTTP(S) esterno dalla risorsa Ingress. Più risorse Ingress possono fare riferimento alla stessa risorsa FrontendConfig e allo stesso criterio SSL. Se un criterio SSL di riferimento viene modificato, la modifica viene propagata ai Google Front End (GFE) che alimentano il bilanciatore del carico HTTP(S) esterno creato dall'Ingress.

Il seguente manifest FrontendConfig abilita un criterio SSL denominato gke-ingress-ssl-policy:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

Reindirizzamenti da HTTP a HTTPS

Un bilanciatore del carico HTTP esterno può reindirizzare le richieste HTTP non criptate a un bilanciatore del carico HTTPS che utilizza lo stesso indirizzo IP. Quando crei una risorsa Ingress con reindirizzamenti da HTTP a HTTPS abilitati, entrambi questi bilanciatori del carico vengono creati automaticamente. Le richieste all'indirizzo IP esterno della porta 80 vengono reindirizzate automaticamente allo stesso indirizzo IP esterno sulla porta 443. Questa funzionalità si basa sui reindirizzamenti da HTTP a HTTPS forniti da Cloud Load Balancing.

Per supportare il reindirizzamento da HTTP a HTTPS, è necessario configurare una risorsa Ingress in modo da gestire il traffico sia HTTP che HTTPS. Se HTTP o HTTPS è disabilitato, il reindirizzamento non funzionerà.

I reindirizzamenti da HTTP a HTTPS vengono configurati utilizzando il campo redirectToHttps in una risorsa personalizzata FrontendConfig. I reindirizzamenti sono abilitati per l'intera risorsa Ingress, pertanto per tutti i servizi a cui fa riferimento l'Ingress disporranno di reindirizzamenti HTTPS abilitati.

Il seguente manifest FrontendConfig abilita i reindirizzamenti da HTTP a HTTPS. Imposta il campo spec.redirectToHttps.enabled su true per attivare i reindirizzamenti HTTPS. Il campo spec.responseCodeName è facoltativo. Se viene omesso, viene utilizzato un reindirizzamento 301 Moved Permanently.

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: RESPONSE_CODE

Sostituisci RESPONSE_CODE con uno dei seguenti:

  • MOVED_PERMANENTLY_DEFAULT per restituire un codice di risposta di reindirizzamento 301 (valore predefinito se responseCodeName non è specificato).
  • FOUND per restituire un codice di risposta di reindirizzamento 302.
  • SEE_OTHER per restituire un codice di risposta di reindirizzamento 303.
  • TEMPORARY_REDIRECT per restituire un codice di risposta di reindirizzamento 307.
  • PERMANENT_REDIRECT per restituire un codice di risposta di reindirizzamento 308.

Quando i reindirizzamenti sono abilitati, il controller Ingress crea un bilanciatore del carico come mostrato nel seguente diagramma:

Un bilanciatore del carico HTTP esterno solo per il reindirizzamento costituito da una regola di forwarding, un proxy HTTP di destinazione e una mappa URL con un reindirizzamento a un bilanciatore del carico HTTPS completo con servizi di backend

Per verificare il funzionamento del reindirizzamento, utilizza un comando curl:

curl http://IP_ADDRESS

Sostituisci IP_ADDRESS con l'indirizzo IP del tuo traffico Ingress.

La risposta mostra il codice di risposta di reindirizzamento che hai configurato. Ad esempio, l'esempio seguente si riferisce a un FrontendConfig configurato con un reindirizzamento 301: MovedPermanently:

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>

Configurazione delle funzionalità Ingress mediante i parametri BackendConfig

Le sezioni seguenti mostrano come impostare BackendConfig per abilitare funzionalità specifiche di Ingress. Le modifiche a una risorsa BackendConfig vengono costantemente riconciliate, quindi non è necessario eliminare e ricreare la risorsa Ingress per vedere le modifiche apportate a BackendConfig.

Per informazioni sulle limitazioni di BackendConfig, consulta la sezione sulle limitazioni.

Timeout del servizio di backend

Puoi utilizzare un oggetto BackendConfig per impostare un periodo di timeout del servizio di backend in secondi. Se non specifichi un valore, il valore predefinito è 30 secondi.

Il seguente manifest BackendConfig specifica un timeout di 40 secondi:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

Puoi abilitare Cloud CDN utilizzando una BackendConfig.

Il seguente manifest BackendConfig mostra tutti i campi disponibili durante l'abilitazione di Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: CDN_ENABLED
    cachePolicy:
      includeHost: INCLUDE_HOST
      includeProtocol: INCLUDE_PROTOCOL
      includeQueryString: INCLUDE_QUERY_STRING
      queryStringBlacklist: QUERY_STRING_DENYLIST
      queryStringWhitelist: QUERY_STRING_ALLOWLIST
    cacheMode: CACHE_MODE
    clientTtl: CLIENT_TTL
    defaultTtl: DEFAULT_TTL
    maxTtl: MAX_TTL
    negativeCaching: NEGATIVE_CACHING
    negativeCachingPolicy:
      code: NEGATIVE_CACHING_CODE
      ttl: NEGATIVE_CACHING_TTL
    requestCoalescing: REQ_COALESCING
    serveWhileStale: SERVE_WHILE_STALE
    signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
    signedUrlKeys:
      keyName: KEY_NAME
      keyValue: KEY_VALUE
      secretName: SECRET_NAME

Sostituisci quanto segue:

  • CDN_ENABLED: se impostato su true, Cloud CDN è abilitato per questo backend in entrata.
  • INCLUDE_HOST: se il criterio viene impostato su true, le richieste a host diversi vengono memorizzate nella cache separatamente.
  • INCLUDE_PROTOCOL: se impostato su true, le richieste HTTP e HTTPS vengono memorizzate nella cache separatamente.
  • INCLUDE_QUERY_STRING: se impostato su true, i parametri della stringa di query vengono inclusi nella chiave cache in base a queryStringBlacklist o queryStringWhitelist. Se nessuno dei due valori è impostato, viene inclusa l'intera stringa di query. Se il criterio viene impostato su false, l'intera stringa di query viene esclusa dalla chiave cache.
  • QUERY_STRING_DENYLIST: specifica un array di stringhe con i nomi dei parametri stringa di query da escludere dalle chiavi cache. Sono inclusi tutti gli altri parametri. Puoi specificare queryStringBlacklist o queryStringWhitelist, ma non entrambi.
  • QUERY_STRING_ALLOWLIST: specifica un array di stringhe con i nomi dei parametri stringa di query da includere nelle chiavi cache. Tutti gli altri parametri sono esclusi. Puoi queryStringBlacklist o queryStringWhitelist, ma non entrambe.

I campi seguenti sono supportati solo nelle versioni GKE 1.23.3-gke.900 e successive utilizzando GKE Ingress. Non sono supportati utilizzando Ingress multi-cluster:

Espandi la sezione seguente per vedere un esempio che esegue il deployment di Cloud CDN tramite Ingress e poi verifica che il contenuto dell'applicazione venga memorizzato nella cache.

Timeout per svuotamento della connessione

Puoi configurare il timeout per lo svuotamento della connessione utilizzando una BackendConfig. Il timeout per svuotamento connessioni è il tempo, in secondi, di attesa per lo svuotamento delle connessioni. Per la durata specificata del timeout, le richieste esistenti al backend rimosso hanno il tempo di essere completate. Il bilanciatore del carico non invia nuove richieste al backend rimosso. Una volta raggiunta la durata del timeout, tutte le connessioni rimanenti al backend vengono chiuse. La durata del timeout può essere compresa tra 0 e 3600 secondi. Il valore predefinito è 0, il che disabilita anche lo svuotamento della connessione.

Il seguente manifest BackendConfig specifica un timeout per lo svuotamento della connessione di 60 secondi:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

Configurazione del controllo di integrità personalizzato

GKE configura i controlli di integrità dei bilanciatori del carico Google Cloud durante il deployment tramite Ingress. Per scoprire di più su come GKE Ingress esegue il deployment dei controlli di integrità, consulta Controlli di integrità in entrata.

Una BackendConfig ti consente di controllare con precisione le impostazioni del controllo di integrità del bilanciatore del carico.

Puoi configurare più servizi GKE per fare riferimento alla stessa BackendConfig come modello riutilizzabile. Per i parametri healthCheck, viene creato un controllo di integrità univoco di Google Cloud per ogni servizio di backend corrispondente a ciascun servizio GKE.

Il seguente manifest BackendConfig mostra tutti i campi disponibili durante la configurazione di un controllo di integrità BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTH_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    type: PROTOCOL
    requestPath: PATH
    port: PORT

Sostituisci quanto segue:

  • INTERVAL: specifica check-interval, in secondi, per ogni prober del controllo di integrità. Si tratta del tempo che intercorre dall'inizio di un controllo di un prober all'inizio di quello successivo. Se ometti questo parametro, viene usato il valore predefinito di 5 secondi di Google Cloud. Per ulteriori dettagli sull'implementazione, consulta Frequenza e probe multipli.
  • TIMEOUT: specifica il tempo di attesa di Google Cloud per una risposta a un probe. Il valore di TIMEOUT deve essere minore o uguale a INTERVAL. Le unità sono in secondi. Ogni probe richiede la consegna di un codice di risposta HTTP 200 (OK) prima del timeout del probe.
  • HEALTH_THRESHOLD e UNHEALTHY_THRESHOLD: specifica il numero di tentativi di connessione sequenziali che devono avere esito positivo o negativo, per almeno un prober, al fine di modificare lo stato di integrità da integro a non integro o viceversa. Se ometti uno di questi parametri, Google Cloud utilizza il valore predefinito 2.
  • PROTOCOL: specifica un protocollo utilizzato dai sistemi di probe per il controllo di integrità. BackendConfig supporta solo la creazione di controlli di integrità utilizzando i protocolli HTTP, HTTPS o HTTP2. Per ulteriori informazioni, consulta Criteri di successo per HTTP, HTTPS e HTTP/2. Non puoi omettere questo parametro.
  • PATH: per i controlli di integrità HTTP, HTTPS o HTTP2, specifica request-path a cui deve connettersi il sistema di probe. Se ometti questo parametro, Google Cloud utilizza il valore predefinito di /.
  • PORT: una configurazione BackendConfig supporta solo la specifica porta per il controllo di integrità del bilanciatore del carico tramite un numero di porta. Se ometti questo parametro, Google Cloud utilizza il valore predefinito 80.

    • Quando utilizzi il bilanciamento del carico nativo del container, devi selezionare una porta corrispondente alla containerPort di un pod di gestione (indipendentemente dal fatto che a containerPort sia indicato o meno un targetPort del servizio). Poiché il bilanciatore del carico invia i probe direttamente all'indirizzo IP del pod, non sei limitato ai containerPort a cui fa riferimento un targetPort di un servizio. I sistemi di probe per il controllo di integrità si connettono all'indirizzo IP di un pod di gestione

    • Per i backend di gruppi di istanze, devi selezionare una porta corrispondente a un valore nodePort esposto dal servizio. I sistemi di probe per il controllo di integrità si connettono a ciascun nodo su quella porta.

Per configurare GKE Ingress con un controllo di integrità HTTP personalizzato, consulta GKE Ingress con controllo di integrità HTTP personalizzato.

Criterio di sicurezza in entrata di Google Cloud Armor

I criteri di sicurezza di Google Cloud Armor ti aiutano a proteggere le applicazioni con bilanciamento del carico dagli attacchi basati sul web. Dopo aver configurato un criterio di sicurezza di Google Cloud Armor, puoi farvi riferimento utilizzando una configurazione BackendConfig.

Aggiungi il nome del criterio di sicurezza a BackendConfig. Il seguente manifest BackendConfig specifica un criterio di sicurezza denominato example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Due fonti di verità

Sebbene configurate tramite GKE, le API Compute Engine BackendService sottostanti possono comunque essere utilizzate per modificare direttamente il criterio di sicurezza da applicare. Questo crea due fonti di attendibilità: GKE e Compute Engine. Il comportamento del controller GKE Ingress in risposta al campo securityPolicy all'interno di BackendConfig è documentato nella tabella seguente. Per evitare conflitti e comportamenti imprevisti, consigliamo di utilizzare l'BackendConfig di GKE per la gestione del criterio di sicurezza da utilizzare.

Campo BackendConfig Valore Comportamento
spec.securityPolicy.name CloudArmorPolicyName Il controller GKE Ingress imposta il criterio Google Cloud Armor denominato CloudArmorPolicyName sul bilanciatore del carico. Il controller GKE Ingress sovrascrive qualsiasi criterio impostato in precedenza.
spec.securityPolicy.name Stringa vuota ("") Il controller GKE Ingress rimuove dal bilanciatore del carico qualsiasi criterio di Google Cloud Armor configurato.
spec.securityPolicy nil Il controller GKE Ingress utilizza la configurazione impostata nell'oggetto BackendService configurato tramite l'API Compute Engine utilizzando la console Google Cloud, gcloud CLI o Terraform.

Per configurare GKE Ingress con la protezione di Google Cloud Armor, vedi Traffico in entrata abilitato per Google Cloud Armor.

Logging degli accessi HTTP

Ingress può registrare tutte le richieste HTTP dai client in Cloud Logging. Puoi abilitare e disabilitare il logging degli accessi utilizzando BackendConfig e impostando la frequenza di campionamento del logging degli accessi.

Per configurare il logging degli accessi, utilizza il campo logging in BackendConfig. Se logging viene omesso, il logging degli accessi adotta il comportamento predefinito. Dipende dalla versione di GKE.

Puoi configurare i seguenti campi:

  • enable: se impostato su true, il logging degli accessi verrà abilitato per questa risorsa Ingress e i log saranno disponibili in Cloud Logging. Altrimenti, il logging degli accessi è disabilitato per questo Ingress.
  • sampleRate: specifica un valore compreso tra 0,0 e 1,0, dove 0,0 indica che nessun pacchetto viene registrato e 1,0 indica che il 100% dei pacchetti viene registrato. Questo campo è pertinente solo se enable è impostato su true. sampleRate è un campo facoltativo, ma se è configurato, è necessario impostare anche enable: true oppure viene interpretato come enable: false.

Il seguente manifest BackendConfig abilita il logging degli accessi e imposta la frequenza di campionamento sul 50% delle richieste HTTP per una determinata risorsa Ingress:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

Per configurare BackendConfig per Identity-Aware Proxy IAP, devi specificare i valori enabled e secretName per il blocco iap in BackendConfig. Per specificare questi valori, assicurati di disporre dell'autorizzazione compute.backendServices.update.

Il seguente manifest BackendConfig abilita Identity-Aware Proxy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

Abilita IAP con il client OAuth gestito da Google

A partire da GKE 1.29.4-gke.1043000, IAP può essere configurato in modo da utilizzare il client OAuth gestito da Google tramite una BackendConfig. Per decidere se utilizzare il client OAuth di Google o un client OAuth personalizzato, vedi Quando utilizzare una configurazione OAuth personalizzata nella documentazione di IAP.

Per abilitare IAP con il client OAuth gestito da Google, non fornire le credenziali OAuth in BackendConfig. Per gli utenti che hanno già configurato IAP utilizzando Credenziali OAuth, non esiste un percorso di migrazione a cui passare all'utilizzo di un client OAuth gestito da Google, devi ricreare il backend (rimuovere il servizio dall'Ingress e ricollegarlo). Ti consigliamo di eseguire questa operazione durante un periodo di manutenzione, poiché ciò causerà tempi di inattività. Il percorso di migrazione opposto, ovvero il passaggio da OAuthClient a OAuthCredentials gestito da Google.

Il seguente manifest BackendConfig abilita Identity-Aware Proxy con il client OAuth gestito da Google:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true

Per istruzioni complete, consulta Attivazione di IAP per GKE nella documentazione di IAP.

Identity-Aware Proxy con Ingress interno

Per configurare il traffico interno in entrata per IAP, devi utilizzare il livello Premium. Se non utilizzi il livello Premium, non puoi visualizzare o creare bilanciatori del carico delle applicazioni interni con Identity-Aware Proxy. Devi anche disporre di un abbonamento a BeyondCorp Enterprise per utilizzare Ingress interno per IAP.

Per configurare GKE Ingress sicuro con l'autenticazione basata su Identity-Aware Proxy, vedi l'esempio In entrata con IAP abilitato.

Affinità sessione

Puoi utilizzare un BackendConfig per impostare l'affinità sessione sull'IP del client o sul cookie generato.

Affinità IP client

Per utilizzare un BackendConfig in modo da impostare l'affinità IP client, imposta affinityType su "CLIENT_IP", come nell'esempio seguente:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

Per utilizzare una proprietà BackendConfig per impostare l'affinità dei cookie generata, imposta affinityType su GENERATED_COOKIE nel manifest BackendConfig. Puoi anche utilizzare affinityCookieTtlSec per impostare il periodo di tempo durante il quale il cookie rimane attivo.

Il seguente manifest imposta il tipo di affinità sul cookie generato e assegna ai cookie un TTL di 50 secondi:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

Intestazioni delle richieste definite dall'utente

Puoi utilizzare un oggetto BackendConfig per configurare le intestazioni delle richieste definite dall'utente. Il bilanciatore del carico aggiunge le intestazioni specificate alle richieste che inoltra ai backend.

Per abilitare le intestazioni delle richieste definite dall'utente, devi specificare un elenco di intestazioni nella proprietà customRequestHeaders della risorsa BackendConfig. Specifica ogni intestazione come stringa header-name:header-value.

Il seguente manifest BackendConfig aggiunge tre intestazioni di richiesta:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

Intestazioni delle risposte personalizzate

Per abilitare le intestazioni delle risposte personalizzate, specifica un elenco di intestazioni nella proprietà customResponseHeaders della risorsa BackendConfig. Specifica ogni intestazione come stringa header-name:header-value.

Le intestazioni delle risposte personalizzate sono disponibili solo nei cluster GKE 1.25 e versioni successive.

Il seguente manifest BackendConfig è un esempio per aggiungere un'intestazione di risposta HTTP Strict Transport Security (HSTS):

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customResponseHeaders:
    headers:
    - "Strict-Transport-Security: max-age=28800; includeSubDomains"

Esercizio: impostazione dei timeout di Ingress utilizzando un servizio di backend

L'esercizio seguente mostra i passaggi necessari per configurare i timeout e lo svuotamento della connessione con una risorsa Ingress con una risorsa BackendConfig.

Per configurare le proprietà di backend di una risorsa Ingress, completa le seguenti attività:

  1. Creare un deployment.
  2. Crea una BackendConfig.
  3. Crea un servizio e associa una delle sue porte a BackendConfig.
  4. Crea una risorsa Ingress e associala alla coppia (servizio, porta).
  5. Convalida le proprietà del servizio di backend.
  6. Esegui la pulizia.

Creazione di un deployment

Prima di creare un BackendConfig e un Service, devi creare un Deployment.

Il seguente manifest di esempio è per un deployment denominato my-deployment.yaml:

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Crea il deployment eseguendo questo comando:

kubectl apply -f my-deployment.yaml

Creazione di una BackendConfig

Utilizza il tuo BackendConfig per specificare le funzionalità Ingress che vuoi usare.

Il manifest BackendConfig, denominato my-backendconfig.yaml, specifica:

  • Un timeout di 40 secondi.
  • Un timeout per svuotamento della connessione di 60 secondi.
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

Crea BackendConfig eseguendo questo comando:

kubectl apply -f my-backendconfig.yaml

Crea un Service

Un BackendConfig corrisponde a una singola combinazione servizio-porta, anche se un servizio ha più porte. Ogni porta può essere associata a un singolo CRD BackendConfig. Se una porta del servizio fa riferimento a una porta Ingress e se la porta del servizio è associata a una struttura BackendConfig, il servizio di backend di bilanciamento del carico HTTP(S) prende parte della sua configurazione da BackendConfig.

Di seguito è riportato un esempio di manifest del servizio denominato my-service.yaml:

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

L'annotazione cloud.google.com/backend-config specifica una mappatura tra porte e oggetti BackendConfig. Tra my-service.yaml:

  • Qualsiasi pod con l'etichetta purpose: bsc-config-demo è membro del servizio.
  • La porta TCP 80 del servizio è associata a una BackendConfig denominato my-backendconfig. Questa è l'annotazione cloud.google.com/backend-config.
  • Una richiesta inviata alla porta 80 del servizio viene inoltrata a uno dei pod membri sulla porta 8080.

Per creare il servizio, esegui questo comando:

kubectl apply -f my-service.yaml

Creare una risorsa Ingress

Di seguito è riportato un manifest Ingress denominato my-ingress.yaml.. In questo esempio, le richieste in entrata vengono instradate alla porta 80 del servizio denominato my-service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-service
            port:
              number: 80

Per creare la risorsa Ingress, esegui questo comando:

kubectl apply -f my-ingress.yaml

Attendi qualche minuto affinché il controller Ingress configuri un bilanciatore del carico delle applicazioni esterno e un servizio di backend associato. Al termine, hai configurato Ingress in modo che utilizzi un timeout di 40 secondi e un timeout per lo svuotamento della connessione di 60 secondi.

Convalida delle proprietà del servizio di backend in corso...

Puoi verificare che siano state applicate le impostazioni corrette del bilanciatore del carico tramite BackendConfig. A questo scopo, identifica il servizio di backend di cui è stato eseguito il deployment da Ingress e controllane le impostazioni per verificare che corrispondano ai manifest del deployment.

Innanzitutto, descrivi la risorsa my-ingress e filtra per l'annotazione che elenca i servizi di backend associati alla risorsa Ingress. Ad esempio:

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

Dovresti vedere un output simile al seguente:

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

L'output fornisce informazioni sui servizi di backend. Ad esempio, questa annotazione contiene due servizi di backend:

  • "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" fornisce informazioni sul servizio di backend associato al servizio Kubernetes my-service.
    • k8s1-27fde173 è un hash utilizzato per descrivere il cluster.
    • default è lo spazio dei nomi Kubernetes.
    • HEALTHY indica che il backend è integro.
  • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" fornisce informazioni sul servizio di backend associato al backend predefinito (404-server).
    • k8s1-27fde173 è un hash utilizzato per descrivere il cluster.
    • kube-system è lo spazio dei nomi.
    • default-http-backend è il nome del servizio Kubernetes.
    • 80 è la porta dell'host.
    • HEALTHY indica che il backend è integro.

Quindi, ispeziona il servizio di backend associato a my-service utilizzando gcloud. Filtra per "drainingTimeoutSec" e "timeoutSec" per confermare che siano stati impostati nel piano di controllo del bilanciatore del carico Google Cloud. Ad esempio:

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

Output:

  drainingTimeoutSec: 60
  timeoutSec: 40

La visualizzazione di drainingTimeoutSec e timeoutSec nell'output conferma che i rispettivi valori sono stati impostati correttamente tramite BackendConfig.

esegui la pulizia

Per evitare addebiti indesiderati sul tuo account, elimina gli oggetti Kubernetes che hai creato per questo esercizio:

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

Limitazioni di BackendConfig

Le configurazioni BackendConfig presentano le seguenti limitazioni:

  • Solo una coppia (servizio, porta) può utilizzare una sola coppia BackendConfig, anche se più oggetti Ingress fanno riferimento a (servizio, porta). Ciò significa che tutti gli oggetti Ingress che fanno riferimento allo stesso (servizio, porta) devono utilizzare la stessa configurazione per Google Cloud Armor, IAP e Cloud CDN.
  • Impossibile abilitare IAP e Cloud CDN per lo stesso servizio di backend di bilanciamento del carico HTTP(S). Ciò significa che non puoi configurare IAP e Cloud CDN nello stesso BackendConfig.
  • Devi utilizzare kubectl 1.7 o versioni successive per interagire con BackendConfig.

Rimozione della configurazione specificata in FrontendConfig o BackendConfig

Per revocare una funzionalità Ingress, devi disabilitare esplicitamente la configurazione della funzionalità nel CRD di FrontendConfig o BackendConfig. Il controller Ingress riconcilia solo le configurazioni specificate in questi CRD.

Per cancellare o disabilitare una configurazione abilitata in precedenza, imposta il valore del campo su una stringa vuota ("") o su un valore booleano false, a seconda del tipo di campo.

Il seguente manifest BackendConfig disabilita un criterio di sicurezza di Google Cloud Armor e Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

Eliminazione di FrontendConfig o BackendConfig

FrontendConfig

Per eliminare un FrontendConfig:

  1. Rimuovi il nome di FrontendConfig dall'annotazione networking.gke.io/v1beta1.FrontendConfig nel manifest Ingress.

  2. Applica al cluster il manifest Ingress modificato. Ad esempio, utilizza kubectl apply.

  3. Elimina FrontendConfig. Ad esempio, utilizza kubectl delete frontendconfig config my-frontendconfig.

BackendConfig

Per eliminare un BackedConfig, segui questi passaggi:

  1. Rimuovi il nome di BackendConfig dall'annotazione cloud.google.com/backend-config nel manifest del servizio.

  2. Applica al cluster il manifest del servizio modificato. Ad esempio, utilizza kubectl apply.

  3. Elimina BackendConfig. Ad esempio, utilizza kubectl delete backendconfig my-backendconfig.

Risoluzione dei problemi

Puoi rilevare gli errori di configurazione più comuni utilizzando lo strumento di diagnostica di Ingress. Dovresti anche assicurarti che tutti i controlli di integrità siano configurati correttamente.

BackendConfig non trovato

Questo errore si verifica quando nell'annotazione del servizio viene specificata una porta BackendConfig per un servizio, ma non è stato possibile trovare la risorsa BackendConfig effettiva.

Per valutare un evento Kubernetes, esegui questo comando:

kubectl get event

L'output di esempio seguente indica che BackendConfig non è stato trovato:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

Per risolvere il problema, assicurati di non aver creato la risorsa BackendConfig nello spazio dei nomi errato o di non aver scritto in modo errato il relativo riferimento nell'annotazione del servizio.

Criterio di sicurezza in entrata non trovato

Dopo la creazione dell'oggetto Ingress, se il criterio di sicurezza non è associato correttamente al servizio LoadBalancer, valuta l'evento Kubernetes per vedere se si è verificato un errore di configurazione. Se il tuo BackendConfig specifica un criterio di sicurezza che non esiste, viene generato periodicamente un evento di avviso.

Per valutare un evento Kubernetes, esegui questo comando:

kubectl get event

L'output di esempio seguente indica che il criterio di sicurezza non è stato trovato:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

Per risolvere il problema, specifica il nome del criterio di sicurezza corretto in BackendConfig.

Gestione degli errori della serie 500 con i NEG durante la scalabilità dei carichi di lavoro in GKE

Sintomo:

Quando utilizzi i NEG di cui è stato eseguito il provisioning di GKE per il bilanciamento del carico, potresti riscontrare errori 502 o 503 per i servizi durante lo fare lo scale down del carico di lavoro. Gli errori 502 si verificano quando i pod vengono terminati prima della chiusura delle connessioni esistenti, mentre gli errori 503 si verificano quando il traffico viene indirizzato ai pod eliminati.

Questo problema può interessare i cluster se utilizzi prodotti di bilanciamento del carico gestiti da GKE che utilizzano NEG, inclusi gateway, Ingress e NEG autonomi. Se scala frequentemente i carichi di lavoro, il rischio di impatto sul cluster è maggiore.

Diagnosi:

La rimozione di un pod in Kubernetes senza svuotare il relativo endpoint e rimuoverlo dal NEG prima causa errori di serie 500. Per evitare problemi durante la terminazione dei pod, devi considerare l'ordine delle operazioni. Le seguenti immagini mostrano scenari quando il criterio BackendService Drain Timeout non viene configurato e BackendService Drain Timeout è impostato su BackendConfig.

Scenario 1: il criterio BackendService Drain Timeout non è impostato.

L'immagine seguente mostra uno scenario in cui BackendService Drain Timeout non è impostato.

Il timeout dello svuotamento di BackendService non è impostato

Scenario 2: BackendService Drain Timeout è impostato.

La seguente immagine mostra uno scenario in cui è impostato BackendService Drain Timeout.

Il timeout dello svuotamento di BackendService è impostato

Il momento esatto in cui si verificano gli errori della serie 500 dipende dai seguenti fattori:

  • Latenza di scollegamento dell'API NEG: la latenza di scollegamento dell'API NEG rappresenta il tempo attuale necessario per finalizzare l'operazione di scollegamento in Google Cloud. Ciò è influenzato da una serie di fattori esterni a Kubernetes, tra cui il tipo di bilanciatore del carico e la zona specifica.

  • Latenza di svuotamento: rappresenta il tempo impiegato dal bilanciatore del carico per iniziare a indirizzare il traffico lontano da una determinata parte del sistema. Una volta avviata la procedura di svuotamento, il bilanciatore del carico interrompe l'invio di nuove richieste all'endpoint, ma l'attivazione dello svuotamento (latenza di svuotamento) presenta ancora una latenza che può causare errori 503 temporanei se il pod non esiste più.

  • Configurazione del controllo di integrità: soglie più sensibili per i controlli di integrità riducono la durata degli errori 503, in quanto possono segnalare al bilanciatore del carico di interrompere l'invio di richieste agli endpoint anche se l'operazione di scollegamento non è terminata.

  • Periodo di tolleranza per la chiusura: il periodo di tolleranza per la chiusura determina il periodo massimo di tempo concesso per l'uscita di un pod. Tuttavia, un pod può uscire prima del termine del periodo di tolleranza. Se un pod impiega più tempo di questo periodo, ne viene forzata l'uscita alla fine del periodo. Questa è un'impostazione sul pod e deve essere configurata nella definizione del carico di lavoro.

Potenziale risoluzione:

Per evitare questi errori 5XX, applica le seguenti impostazioni. I valori di timeout sono allusivi e potresti doverli modificare per la tua applicazione specifica. La sezione seguente illustra la procedura di personalizzazione.

La seguente immagine mostra come mantenere attivo il pod con preStopHook:

Il timeout dello svuotamento di BackendService è impostato

Per evitare errori relativi alla serie 500:

  1. Imposta BackendService Drain Timeout per il servizio su 1 minuto.

  2. Estendi terminationGracePeriod sul pod.

    Imposta terminationGracePeriodSeconds sul pod su 3,5 minuti. Se combinato con le impostazioni consigliate, consente ai pod di usufruire di una finestra di 30-45 secondi per un arresto controllato dopo la rimozione dell'endpoint del pod dal NEG. Se hai bisogno di più tempo per la chiusura controllata, puoi estendere il periodo di tolleranza o seguire le istruzioni riportate nella sezione Personalizzare i timeout.

    Il seguente manifest dei pod specifica un timeout per lo svuotamento della connessione di 210 secondi (3,5 minuti):

    spec:
      terminationGracePeriodSeconds: 210
      containers:
      - name: my-app
        ...
      ...
    
  3. Applica un'istruzione preStopHook a tutti i container.

    Applica un preStopHook che garantirà che il pod sia attivo per 120 secondi più a lungo mentre l'endpoint del pod viene svuotato nel bilanciatore del carico e l'endpoint viene rimosso dal NEG.

    spec:
      containers:
      - name: my-app
        ...
        lifecycle:
          preStopHook:
            exec:
              command: ["/bin/sh", "-c", "sleep 120s"]
      ...
    

Personalizza timeout

Per garantire la continuità del pod ed evitare errori della serie 500, il pod deve essere attivo fino alla rimozione dell'endpoint dal NEG. Specialmente per evitare errori 502 e 503, valuta la possibilità di implementare una combinazione di timeout e di un valore preStopHook.

Per mantenere il pod più a lungo durante il processo di arresto, aggiungi un preStopHook al pod. Esegui preStopHook prima che venga segnalato l'uscita di un pod, in modo che preStopHook possa essere utilizzato per mantenere il pod a portata di mano fino a quando l'endpoint corrispondente non viene rimosso dal NEG.

Per estendere il periodo di tempo in cui un pod rimane attivo durante il processo di arresto, inserisci un preStopHook nella configurazione del pod come segue:

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStopHook:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

Puoi configurare i timeout e le relative impostazioni per gestire l'arresto controllato dei pod durante lo scale down dei carichi di lavoro. Puoi regolare i timeout in base a casi d'uso specifici. Ti consigliamo di iniziare con timeout più lunghi e di ridurre la durata, se necessario. Puoi personalizzare i timeout configurando i parametri relativi al timeout e il preStopHook nei seguenti modi:

Timeout svuotamento servizio di backend

Il parametro Backend Service Drain Timeout non è impostato per impostazione predefinita e non ha alcun effetto. Se imposti il parametro Backend Service Drain Timeout e lo attivi, il bilanciatore del carico interrompe l'instradamento delle nuove richieste all'endpoint e attende il timeout prima di terminare le connessioni esistenti.

Puoi impostare il parametro Backend Service Drain Timeout utilizzando BackendConfig con Ingress, GCPBackendPolicy con il gateway o manualmente su BackendService con NEG autonomi. Il timeout dovrebbe essere da 1,5 a 2 volte superiore al tempo necessario per elaborare una richiesta. Ciò garantisce che, se una richiesta è stata inviata poco prima dell'inizio dello svuotamento, verrà completata prima del completamento del timeout. L'impostazione del parametro Backend Service Drain Timeout su un valore maggiore di 0 consente di mitigare gli errori 503 perché non vengono inviate nuove richieste agli endpoint pianificati per la rimozione. Affinché questo timeout venga applicato, devi utilizzarlo insieme a preStopHook per assicurarti che il pod resti attivo mentre si verifica lo svuotamento. Senza questa combinazione, le richieste esistenti che non sono state completate riceveranno un errore 502.

preStopHook volta

preStopHook deve ritardare l'arresto del pod in modo sufficiente affinché la latenza di svuotamento e il timeout per lo svuotamento del servizio di backend siano completati, garantendo il corretto svuotamento della connessione e la rimozione dell'endpoint dal NEG prima dell'arresto del pod.

Per risultati ottimali, assicurati che il tempo di esecuzione di preStopHook sia inferiore o uguale alla somma di Backend Service Drain Timeout e Latenza di svuotamento.

Questo valore può essere calcolato utilizzando la formula:

preStopHook >= Backend Service Drain Timeout + Drain Latency

Ti consigliamo di impostare la Latenza di svuotamento su 1 minuto. Se rimangono 500 errori, stima la durata totale dell'occorrenza e aggiungi il doppio alla latenza. In questo modo il pod ha tempo a sufficienza per svuotarsi correttamente prima di essere rimosso dal servizio. Puoi regolare questo valore se è troppo lungo per il tuo caso d'uso specifico.

In alternativa, puoi stimare la tempistica esaminando il timestamp di eliminazione dal pod e il timestamp in cui l'endpoint è stato rimosso dal NEG in Cloud Audit Logs.

Parametro periodo di tolleranza per la chiusura

Devi configurare il parametro terminationGracePeriod in modo da concedere tempo sufficiente per il completamento di preStopHook e per il completamento di un arresto controllato dal pod.

Per impostazione predefinita, se non viene configurato in modo esplicito, il valore di terminationGracePeriod è di 30 secondi. Puoi calcolare il valore ottimale di terminationGracePeriod utilizzando la formula:

terminationGracePeriod >= preStopHook Time + Pod shutdown time

Per definire terminationGracePeriod all'interno della configurazione del pod come segue:

  spec:
    terminationGracePeriodSeconds: <terminationGracePeriod>
    containers:
    - name: my-app
      ...
    ...

NEG non trovato durante la creazione di una risorsa Ingress interna

Quando crei una risorsa Ingress interna in GKE, potrebbe verificarsi il seguente errore:

Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

Questo errore si verifica perché il traffico in entrata per i bilanciatori del carico delle applicazioni interni richiede gruppi di endpoint di rete (NEG) come backend.

In ambienti o cluster VPC condivisi in cui sono abilitati i criteri di rete, aggiungi l'annotazione cloud.google.com/neg: '{"ingress": true}' al manifest del servizio.

504 Timeout gateway: timeout della richiesta upstream

Potrebbe verificarsi il seguente errore quando accedi a un servizio da un server Ingress interno in GKE:

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

Questo errore si verifica perché il traffico inviato ai bilanciatori del carico delle applicazioni interni viene inviato tramite proxy da proxy Envoy nell'intervallo di subnet solo proxy.

Per consentire il traffico dall'intervallo di subnet solo proxy, crea una regola firewall in targetPort del servizio.

Errore 400: valore non valido per il campo "resource.target"

Potrebbe verificarsi il seguente errore quando accedi a un servizio da un server Ingress interno in GKE:

Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

Per risolvere il problema, crea una subnet solo proxy.

Errore durante la sincronizzazione: errore durante l'esecuzione della routine di sincronizzazione del bilanciatore del carico: il bilanciatore del carico non esiste

Potrebbe verificarsi uno dei seguenti errori quando viene eseguito l'upgrade del piano di controllo GKE o quando modifichi un oggetto Ingress:

"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."

Oppure:

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

Per risolvere questi problemi, prova a procedere nel seguente modo:

  • Aggiungi il campo hosts nella sezione tls del manifest Ingress, quindi elimina l'oggetto Ingress. Aspetta cinque minuti affinché GKE elimini le risorse Ingress inutilizzate. Quindi, ricrea la risorsa Ingress. Per maggiori informazioni, consulta il campo hosts di un oggetto Ingress.
  • Ripristina le modifiche apportate a Ingress. Quindi, aggiungi un certificato utilizzando un'annotazione o un secret di Kubernetes.

Problemi noti

Impossibile abilitare i reindirizzamenti HTTPS con lo schema di denominazione Ingress V1

Non puoi abilitare i reindirizzamenti HTTPS sulle risorse GKE Ingress create nelle versioni GKE 1.16.8-gke.12 e precedenti. Devi ricreare l'oggetto Ingress prima di poter abilitare i reindirizzamenti HTTPS oppure prima che venga creato un evento di errore e la risorsa Ingress non venga sincronizzata.

Il messaggio di evento di errore è simile al seguente:

Error syncing: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.

Campi dei criteri di sicurezza di Google Cloud Armor rimossi da BackendConfig

Si è verificato un problema noto per cui l'aggiornamento di una risorsa BackendConfig tramite l'API v1beta1 rimuove un criterio di sicurezza di Google Cloud Armor attivo dal suo servizio. Questo problema riguarda le seguenti versioni di GKE:

  • da 1.18.19-gke.1400 a 1.18.20-gke.5099
  • da 1.19.10-gke.700 a 1.19.14-gke.299
  • da 1.20.6-gke.700 a 1.20.9-gke.899

Se non configuri Google Cloud Armor nelle tue risorse Ingress tramite BackendConfig, questo problema non interessa i tuoi cluster.

Per i cluster GKE che configurano Google Cloud Armor tramite BackendConfig, ti consigliamo vivamente di aggiornare le risorse BackendConfig solo utilizzando l'API v1. L'applicazione di una proprietà BackendConfig al cluster utilizzando le risorse v1beta1 BackendConfig rimuoverà il criterio di sicurezza di Google Cloud Armor dal servizio a cui fa riferimento.

Per mitigare questo problema, aggiorna la tua BackendConfig solo utilizzando l'v1 API BackendConfig. BackendConfig di v1 supporta gli stessi campi di v1beta1 e non apporta modifiche che provocano un errore, in modo che il campo dell'API possa essere aggiornato in modo trasparente. Sostituisci il campo apiVersion di qualsiasi manifest BackendConfig attivo con cloud.google.com/v1 e non utilizzare cloud.google.com/v1beta1. Il seguente manifest di esempio descrive una risorsa BackendConfig che utilizza l'API v1:

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: my-backend-config
  spec:
    securityPolicy:
      name: "ca-how-to-security-policy"

Se disponi di sistemi o strumenti CI/CD che aggiornano regolarmente le risorse BackendConfig, assicurati di utilizzare il gruppo API cloud.google.com/v1 in questi sistemi.

Se BackendConfig è già stato aggiornato con l'API v1beta1, il criterio di sicurezza di Google Cloud Armor potrebbe essere stato rimosso. Per determinare se ciò si è verificato, puoi eseguire questo comando:

kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'

Se la risposta restituisce un output, il cluster è interessato dal problema. L'output di questo comando restituisce un elenco di risorse BackendConfig (<namespace>/<name>) interessate dal problema. Se l'output è vuoto, significa che BackendConfig non è stato aggiornato utilizzando l'API v1beta1 da quando è stato presentato il problema. Eventuali aggiornamenti futuri a BackendConfig dovrebbero utilizzare solo v1.

Se il criterio di sicurezza di Google Cloud Armor è stato rimosso, puoi determinare quando è stato rimosso utilizzando la seguente query di Logging:

resource.type="gce_backend_service"
protoPayload.methodName="v1.compute.backendServices.setSecurityPolicy"
protoPayload.authenticationInfo.principalEmail:"container-engine-robot.iam.gserviceaccount.com"
protoPayload.response.status = "RUNNING"
NOT protoPayload.authorizationInfo.permission:"compute.securityPolicies.use"

Se uno dei tuoi cluster è stato interessato, puoi correggerlo eseguendo il push di un aggiornamento alla risorsa BackendConfig che utilizza l'API v1.

Esegui l'upgrade del piano di controllo GKE a una delle seguenti versioni aggiornate che corregge questo problema e consente l'uso sicuro delle risorse BackendConfig di v1beta1:

  • 1.18.20-gke.5100 e versioni successive
  • 1.19.14-gke.300 e versioni successive
  • 1.20.9-gke.900 e versioni successive

Passaggi successivi