Configurazione Ingress

---

Panoramica

Questa pagina fornisce una panoramica completa di ciò che puoi configurare tramite Kubernetes Ingress su Google Cloud. Il documento confronta anche le funzionalità supportate per Ingress su Google Cloud e fornisce istruzioni per configurare Ingress utilizzando il controller predefinito, i parametri FrontendConfig e i parametri BackendConfig.

Questa pagina è dedicata agli specialisti di networking che progettano e realizzano l'architettura di rete per la loro organizzazione e installano, configurano e supportano le apparecchiature di rete. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Confronto delle funzioni

La tabella seguente fornisce un elenco delle funzionalità supportate per Ingress su Google Cloud. Viene indicata anche la disponibilità della funzionalità, disponibilità generale (GA) o beta.

Classe Ingress	Ingress esterno	Ingress interno	Ingress multi-cluster
Controller Ingress	Controller Ingress ospitato da Google
Google Cloud load balancer type	Bilanciatore del carico HTTP(S) esterno	Bilanciatore del carico HTTP(S) interno	Bilanciatore del carico HTTP(S) esterno
Ambito cluster	Singolo cluster	Singolo cluster	Cluster multipli
Ambito del bilanciatore del carico	Globale	Regionale	Globale
Supporto dell'ambiente	GKE	GKE	GKE
Supporto per il VPC condiviso	GA	GA	GA
Annotazioni del servizio
Bilanciamento del carico nativo del container (NEG)	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 sui secret Kubernetes	GA	GA	GA
Certificati SSL autogestiti	GA	GA	GA
Certificati SSL gestiti da Google	GA		GA
FrontendConfig
Policy SSL	GA	GA con gateway	GA
Reindirizzamento da HTTP a HTTPS	GA 1.17.13-gke.2600+^GA		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 Google Cloud Armor	GA 1.19.10-gke.700^G		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

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

^GQuesta funzionalità è supportata come GA a partire dalla versione specificata.

Configurazione di Ingress utilizzando il controller predefinito

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

Quando crei un Ingress utilizzando 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 utilizzando un'annotazione su ogni oggetto Service.

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

I FrontendConfig vengono referenziati in un oggetto Ingress e possono essere utilizzati solo con Ingress esterni. I BackendConfig fanno riferimento a un oggetto Service. È possibile fare riferimento agli stessi CRD da più oggetti Service o Ingress per garantire la coerenza della configurazione. Le CRD FrontendConfig e BackendConfig condividono lo stesso ciclo di vita delle risorse Ingress e Service corrispondenti e vengono spesso implementate insieme.

Il seguente diagramma illustra come:

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

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

Figura: panoramica di BackendConfig e FrontendConfig

Associazione di FrontendConfig al tuo Ingress

FrontendConfig può essere utilizzato solo con ingressi esterni.

Puoi associare un FrontendConfig a un 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 del tuo 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 del tuo FrontendConfig.

Associazione di 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.

Stesso BackendConfig per tutte le porte di servizio

Per utilizzare la stessa 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 quelle MultiClusterIngress.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

BackendConfig univoco per porta di servizio

Per Ingress e MultiClusterIngress, puoi specificare un BackendConfig personalizzato per una o più porte utilizzando una chiave che corrisponde al nome o al numero della porta. Il controller Ingress utilizza il BackendConfig specifico quando crea un servizio di backend del bilanciatore del carico per una porta di servizio a cui viene fatto 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 un BackendConfig esistente.
• BACKENDCONFIG_REFERENCE_B: il nome di un BackendConfig esistente.
• SERVICE_REFERENCE_A: utilizza il valore di 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 di 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 in base al numero, devi utilizzare il valore port anziché il valore targetPort. Il numero di porta utilizzato qui serve solo per il binding di 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 a un indirizzo IP del pod) sulla porta targetPort del servizio di riferimento (che deve corrispondere a un containerPort per un pod di servizio). In caso contrario, il bilanciatore del carico invia il traffico all'indirizzo IP di un nodo sulla porta del servizio a cui viene fatto riferimento nodePort.

• Quando utilizzi un BackendConfig per fornire un controllo di integrità del bilanciatore del carico personalizzato, il numero di porta che utilizzi per il controllo di integrità del bilanciatore del carico può differire dal numero spec.ports[].port del servizio. Per informazioni dettagliate sui numeri di porta per i controlli di integrità, consulta Configurazione personalizzata del controllo di integrità.

Nota: la porta di servizio associata a BackendConfig deve essere utilizzata anche nel campo di definizione Ingress backend.service.port. Se la porta del servizio non viene utilizzata in alcun oggetto Ingress, BackendConfig viene ignorato.

Configurazione delle funzionalità Ingress tramite i parametri FrontendConfig

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

Policy SSL

I criteri SSL ti consentono di specificare un insieme di versioni TLS e cifrari che il bilanciatore del carico utilizza per terminare il traffico HTTPS dai client. Devi prima creare una policy SSL al di fuori di GKE. Una volta creato, puoi farvi riferimento in un FrontendConfig CRD.

Il campo sslPolicy in FrontendConfig fa riferimento al nome di una policy SSL nello stesso progetto Google Cloud del cluster GKE. Collega il criterio SSL al proxy HTTPS di destinazione, creato per il bilanciatore del carico HTTP(S) esterno da Ingress. È possibile fare riferimento alla stessa risorsa FrontendConfig e alla stessa policy SSL da più risorse Ingress. Se viene modificato un criterio SSL a cui viene fatto riferimento, la modifica viene propagata ai Google Front Ends (GFE) che alimentano il bilanciatore del carico HTTP(S) esterno creato da Ingress.

Il seguente manifest FrontendConfig abilita una policy SSL denominata 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 un Ingress con i reindirizzamenti da HTTP a HTTPS abilitati, entrambi i bilanciatori del carico vengono creati automaticamente. Le richieste all'indirizzo IP esterno dell'ingresso sulla 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, un Ingress deve essere configurato per gestire il traffico HTTP e HTTPS. Se HTTP o HTTPS sono disattivati, 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, quindi tutti i servizi a cui fa riferimento Ingress avranno i reindirizzamenti HTTPS abilitati.

Il seguente manifest FrontendConfig consente 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 una delle seguenti opzioni:

• 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 reindirizzamento 302.
• SEE_OTHER per restituire un codice di risposta reindirizzamento 303.
• TEMPORARY_REDIRECT per restituire un codice di risposta reindirizzamento 307.
• PERMANENT_REDIRECT per restituire un codice di risposta reindirizzamento 308.

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

Per verificare che il reindirizzamento funzioni, utilizza un comando curl:

curl http://IP_ADDRESS

Sostituisci IP_ADDRESS con l'indirizzo IP del tuo Ingress.

La risposta mostra il codice di risposta reindirizzamento che hai configurato. Ad esempio, il seguente esempio riguarda 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 tramite i parametri BackendConfig

Le sezioni seguenti mostrano come impostare BackendConfig per attivare funzionalità Ingress specifiche. Le modifiche a una risorsa BackendConfig vengono riconciliate costantemente, quindi non è necessario eliminare e ricreare l'ingresso per visualizzare le modifiche a BackendConfig.

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

Timeout del servizio di backend

Puoi utilizzare un 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 un BackendConfig.

Nota: non puoi abilitare sia IAP che Cloud CDN in un BackendConfig. Se BackendConfig non ha un blocco iap, le impostazioni IAP esistenti nel servizio di backend vengono ereditate.

Il seguente manifest BackendConfig mostra tutti i campi disponibili quando attivi 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
      # Specify only one of queryStringBlacklist and queryStringWhitelist.
      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
    # Time, in seconds, to continue serving a stale version after request expiry.
    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 Ingress.
• INCLUDE_HOST: se 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 separatamente nella cache.
• 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 non è impostato nessuno dei due, viene inclusa l'intera stringa di query. Se 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 delle stringhe di query da escludere dalle chiavi cache. Tutti gli altri parametri sono inclusi. Puoi specificare queryStringBlacklist o queryStringWhitelist, ma non entrambi.
• QUERY_STRING_ALLOWLIST: specifica un array di stringhe con i nomi dei parametri delle stringhe di query da includere nelle chiavi cache. Tutti gli altri parametri vengono esclusi. Puoi specificare queryStringBlacklist o queryStringWhitelist, ma non entrambi.

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

• CACHE_MODE: la modalità cache.
• CLIENT_TTL, DEFAULT_TTL, e MAX_TTL: configurazione del TTL. Per ulteriori informazioni, vedi Utilizzo delle impostazioni e degli override TTL.
• NEGATIVE_CACHING: se impostato su true, la memorizzazione nella cache negativa è abilitata. Per saperne di più, consulta la sezione Utilizzare la memorizzazione nella cache negativa.
• NEGATIVE_CACHING_CODE e NEGATIVE_CACHING_TTL: configurazione della memorizzazione nella cache negativa. Per saperne di più, consulta la sezione Utilizzare la memorizzazione nella cache negativa.
• REQ_COALESCING: se impostato su true, il collasso è attivato. Per ulteriori informazioni, vedi Compressione (unione) delle richieste.
• SERVE_WHILE_STALE: tempo in secondi dopo la scadenza della risposta in cui Cloud CDN continua a pubblicare una versione obsoleta. Per ulteriori informazioni, vedi Pubblicazione di contenuti obsoleti.
• SIGNED_MAX_AGE: il tempo massimo per cui le risposte possono essere memorizzate nella cache, in secondi. Per saperne di più, consulta Personalizzare facoltativamente il tempo massimo di memorizzazione nella cache.
• KEY_NAME, KEY_VALUE e SECRET_NAME: configurazione della chiave dell'URL firmato. Per saperne di più, consulta Creazione di chiavi di richiesta firmate.

Espandi la sezione seguente per visualizzare un esempio che esegue il deployment di Cloud CDN tramite Ingress e poi verifica che i contenuti dell'applicazione vengano memorizzati nella cache.

Esempio di Cloud CDN

Per utilizzare un BackendConfig per configurare Cloud CDN, esegui le seguenti attività:

1. Crea uno spazio dei nomi dedicato per l'esecuzione di questo esempio:
   

   kubectl create namespace cdn-how-to
   

2. Crea un file di deployment denominato my-deployment.yaml in base al seguente manifest di deployment. Questo manifest dichiara che vuoi eseguire due repliche dell'applicazione web ingress-gce-echo-amd64.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     namespace: cdn-how-to
     name: my-deployment
   spec:
     selector:
       matchLabels:
         purpose: demonstrate-cdn
     replicas: 2
     template:
       metadata:
         labels:
           purpose: demonstrate-cdn
       spec:
         containers:
         - name: echo-amd64
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app-cdn:1.0

3. Crea la risorsa Deployment:

   kubectl apply -f my-deployment.yaml
   

4. Crea un BackendConfig denominato my-backendconfig.yaml in base al seguente manifest BackendConfig. Il manifest specifica una policy di cache Cloud CDN e dichiara che Cloud CDN deve essere abilitato:

     apiVersion: cloud.google.com/v1
     kind: BackendConfig
     metadata:
       namespace: cdn-how-to
       name: my-backendconfig
     spec:
       cdn:
         enabled: true
         cachePolicy:
           includeHost: true
           includeProtocol: true
           includeQueryString: false

5. Crea la risorsa BackendConfig:

   kubectl apply -f my-backendconfig.yaml
   

6. Crea un file denominato my-service.yaml basato sul seguente manifest del servizio:

   apiVersion: v1
   kind: Service
   metadata:
     namespace: cdn-how-to
     name: my-service
     labels:
       purpose: demonstrate-cdn
     # Use a custom BackendConfig for port 80 in the Service.
     annotations:
       cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
   spec:
     type: NodePort
     selector:
       purpose: demonstrate-cdn
     ports:
     - port: 80
       protocol: TCP
       targetPort: 8080

7. Crea la risorsa Service:

   kubectl apply -f my-service.yaml
   

8. Crea un indirizzo IP riservato:

   gcloud compute addresses create cdn-how-to-address --global
   

9. Crea un file denominato my-ingress.yaml basato sul seguente manifest Ingress:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     namespace: cdn-how-to
     name: my-ingress
     annotations:
       kubernetes.io/ingress.global-static-ip-name: "cdn-how-to-address"
   spec:
     rules:
     # Route all incoming HTTP requests to port 80 in the example Service.
     - http:
         paths:
         - path: /*
           pathType: ImplementationSpecific
           backend:
             service:
               name: my-service
               port:
                 number: 80

10. Crea la risorsa Ingress:

    kubectl apply -f my-ingress.yaml
    

11. Attendi circa dieci minuti affinché il controller Ingress di Kubernetes configuri un bilanciatore del carico, quindi recupera l'indirizzo IP utilizzato dalle regole di forwarding del bilanciatore del carico dalla risorsa Ingress. Google Cloud

    kubectl describe ingress my-ingress --namespace=cdn-how-to | grep "Address"
    

    Output:

    Address:         ADDRESS
    

    ADDRESS è l'indirizzo IP esterno di Ingress.

Convalidare la memorizzazione nella cache di Cloud CDN

Per verificare se i tuoi contenuti vengono memorizzati nella cache, inserisci questo comando curl due volte:

curl -v ADDRESS/?cache=true

Sostituisci ADDRESS con l'indirizzo IP esterno di Ingress.

L'output mostra le intestazioni e il corpo della risposta. Nelle intestazioni della risposta puoi vedere che i contenuti sono stati memorizzati nella cache. L'intestazione Age indica per quanti secondi i contenuti sono stati memorizzati nella cache:

HTTP/1.1 200 OK
Date: Fri, 25 Jan 2019 02:34:08 GMT
Content-Length: 70
Content-Type: text/plain; charset=utf-8
Via: 1.1 google
Cache-Control: max-age=86400,public
Age: 2716

Hello, world!
Version: 1.0.0
Hostname: my-deployment-7f589cc5bc-l8kr8
...

Se noti che i tuoi contenuti non vengono memorizzati nella cache, assicurati che la tua applicazione sia configurata correttamente per abilitare la memorizzazione nella cache dei contenuti. Per maggiori informazioni, consulta Contenuti memorizzabili nella cache.

Pulizia

Per evitare addebiti indesiderati sul tuo account, rilascia l'indirizzo IP statico che hai prenotato:

gcloud compute addresses delete cdn-how-to-address --global

Timeout per svuotamento della connessione

Puoi configurare il timeout di svuotamento delle connessioni utilizzando un BackendConfig. Il timeout per lo svuotamento della connessione è 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 raggiunto il periodo di 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 disattiva anche lo svuotamento della connessione.

Avviso: l'impostazione di un valore elevato per drainingTimeoutSec (ad esempio 3600 secondi) in un Ingress o un servizio che utilizza gruppi di istanze causerà ritardi proporzionali alla durata impostata in drainingTimeoutSec durante l'aggiornamento di altre risorse Ingress nel cluster. Questo perché tutte le risorse Ingress basate su gruppi di istanze in un cluster condividono lo stesso gruppo di istanze. Se hai bisogno di un valore elevato, valuta la possibilità di utilizzare servizi supportati da gruppi di endpoint di rete.

Il seguente manifest BackendConfig specifica un timeout di 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

Esistono diversi modi in cui GKE configura i controlli di integrità del bilanciatore del caricoGoogle Cloud durante il deployment tramite Ingress. Per scoprire di più su come GKE Ingress esegue il deployment dei controlli di integrità, consulta la sezione Controlli di integrità di Ingress.

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

Nota: Ingress non supporta gRPC per le configurazioni personalizzate del controllo di integrità.

Puoi configurare più servizi GKE in modo che facciano riferimento allo stesso BackendConfig come modello riutilizzabile. Per i parametri healthCheck, viene creato un controllo di integritàGoogle Cloud univoco per ogni servizio di backend corrispondente a ogni 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:
    # Time, in seconds, between prober checks. Default is `5`.
    checkIntervalSec: INTERVAL
    # Probe timeout period. Must be less than or equal to checkIntervalSec.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTH_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    # Protocol to use. Must be `HTTP`, `HTTP2`, or `HTTPS`.
    type: PROTOCOL
    # Path for probe to use. Default is `/`.
    requestPath: PATH
    # Port number of the load balancer health check port. Default is `80`.
    port: PORT

Sostituisci quanto segue:

• INTERVAL: specifica il check-interval, in secondi, per ogni probe di controllo di integrità. Questo è il tempo che intercorre tra l'inizio del controllo di un prober e l'inizio del controllo successivo. Se ometti questo parametro, viene utilizzato il valore predefinito di Google Cloud 5 secondi. Per ulteriori dettagli di implementazione, vedi Più probe e frequenza.
• TIMEOUT: specifica il tempo di attesa da parte 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 riuscire o non riuscire, per almeno un prober, per 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 saperne di più, consulta Criteri di esito positivo 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 /.

• PORT: un BackendConfig supporta solo la specifica della porta di controllo dell'controllo di integrità del carico utilizzando 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 a un containerPort di un pod di pubblicazione (indipendentemente dal fatto che questo containerPort sia referenziato da un targetPort del servizio). Poiché il bilanciatore del carico invia 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 del controllo di integrità si connettono all'indirizzo IP di un pod di pubblicazione sulla porta specificata.

  • Per i backend dei gruppi di istanze, devi selezionare una porta corrispondente a un nodePort esposto dal servizio. I sistemi di probe del controllo di integrità si connettono a ogni 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 Ingress di Google Cloud Armor

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

Aggiungi il nome della tua norma di sicurezza a BackendConfig. Il seguente manifest BackendConfig specifica una policy di sicurezza denominata 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"

Avviso: non devi modificare direttamente le risorse BackendService in Compute Engine per collegare le tue norme Cloud Armor ai tuoi servizi di backend gestiti da GKE.

Due fonti attendibili

Sebbene configurate tramite GKE, le API Compute Engine BackendService sottostanti possono comunque essere utilizzate per modificare direttamente la norma di sicurezza da applicare. In questo modo vengono create due fonti attendibili: 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, ti consigliamo di utilizzare il controller di ammissione GKE BackendConfig per la gestione della policy di sicurezza da utilizzare.

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

Per configurare GKE Ingress con la protezione Google Cloud Armor, consulta Ingress abilitato per Google Cloud Armor.

Registrazione dei log di accesso HTTP

Nota :per impostazione predefinita, GKE attiva la registrazione degli accessi per tutti i tipi di ingresso (incluso lIngress multi-cluster). L'impostazione di logging degli accessi per GKE Ingress non era supportata per le versioni di GKE precedenti alla 1.16.8-gke.10. Per GKE 1.16.8-gke.10 o versioni successive, puoi configurare l'impostazione di logging degli accessi per GKE Ingress tramite BackendConfig.

L'ingresso può registrare tutte le richieste HTTP dai client in Cloud Logging. Puoi attivare e disattivare il logging degli accessi utilizzando BackendConfig, oltre a impostare la frequenza di campionamento del logging degli accessi.

Per configurare la registrazione degli accessi, utilizza il campo logging in BackendConfig. Se logging viene omesso, la registrazione degli accessi assume il comportamento predefinito. Questo dipende dalla versione di GKE.

Puoi configurare i seguenti campi:

• enable: se impostato su true, la registrazione degli accessi verrà abilitata per questo ingresso e i log saranno disponibili in Cloud Logging. In caso contrario, il logging degli accessi è disattivato per questo Ingress.
• sampleRate: specifica un valore compreso tra 0,0 e 1,0, dove 0,0 indica che non vengono registrati pacchetti e 1,0 indica che viene registrato il 100% dei pacchetti. Questo campo è pertinente solo se enable è impostato su true. sampleRate è un campo facoltativo, ma se è configurato, deve essere impostato anche enable: true, altrimenti viene interpretato come enable: false.

Il seguente manifest BackendConfig attiva la registrazione degli accessi e imposta la frequenza di campionamento al 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 nel blocco iap di BackendConfig. Per specificare questi valori, assicurati che l'agente di servizio GKE disponga dell'autorizzazione compute.backendServices.update.

Nota: non puoi abilitare sia IAP che Cloud CDN in un BackendConfig. Se BackendConfig non ha un blocco iap, le impostazioni IAP esistenti nel servizio di backend vengono ereditate.

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

Attivare IAP con il client OAuth gestito da Google

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

Per abilitare IAP con il client OAuth gestito da Google, non fornire OAuthCredentials in BackendConfig. Per gli utenti che hanno già configurato IAP utilizzando OAuthCredentials, non esiste un percorso di migrazione per passare all'utilizzo del client OAuth gestito da Google: devi ricreare il backend (rimuovere il servizio dall'ingresso e ricollegarlo). Ti consigliamo di eseguire questa operazione durante un periodo di manutenzione, in quanto causerà tempi di inattività. È possibile il percorso di migrazione opposto, ovvero il passaggio dal client OAuth gestito da Google a OAuthCredentials.

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, vedi Abilitare IAP per GKE nella documentazione di IAP.

Nota: se utilizzi IAP nelle versioni del cluster GKE 1.29.2-gke.1521000, 1.29.3-gke.1093000, 1.29.3-gke.1093002 o 1.29.3-gke.1282000, per evitare interruzioni, esegui l'upgrade alla versione del cluster GKE 1.29.4-gke.1043000.

Identity-Aware Proxy con ingresso interno

Per configurare l'ingresso interno 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. Per utilizzare l'ingresso interno per IAP, devi anche avere un abbonamento a Chrome Enterprise Premium.

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

Affinità sessione

Puoi utilizzare un BackendConfig per impostare l'affinità di sessione all'IP client o al cookie generato.

Importante :utilizza un cluster nativo di VPC se vuoi configurare laffinità sessione. L'affinità di sessione è utile solo per i servizi supportati da gruppi di endpoint di rete e i gruppi di endpoint di rete richiedono un cluster nativo di VPC.

Affinità IP client

Per utilizzare un BackendConfig per impostare l'affinità IP client, imposta affinityType su "CLIENT_IP", come nel seguente esempio:

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

Affinità cookie generato

Per utilizzare un 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à su 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 BackendConfig per configurare le intestazioni di richiesta definite dall'utente. Il bilanciatore del carico aggiunge le intestazioni specificate alle richieste che inoltra ai backend.

Il bilanciatore del carico aggiunge intestazioni delle richieste personalizzate solo alle richieste client, non ai probe del controllo di integrità. Se il backend richiede un'intestazione specifica per l'autorizzazione che non è presente nel pacchetto del controllo di integrità, il controllo di integrità potrebbe non riuscire.

Per attivare le intestazioni delle richieste definite dall'utente, specifica 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 della 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 attivare 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 di risposta personalizzate sono disponibili solo nei cluster GKE versione 1.25 e 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

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

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

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

Creazione di un deployment

Prima di creare un BackendConfig e un servizio, 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 il seguente comando:

kubectl apply -f my-deployment.yaml

Creazione di un oggetto BackendConfig

Utilizza BackendConfig per specificare le funzionalità Ingress che vuoi utilizzare.

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

• Un timeout di 40 secondi.
• Un timeout per lo 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 di servizio e porta, anche se un servizio ha più porte. Ogni porta può essere associata a un singolo CRD BackendConfig. Se viene fatto riferimento a una porta di servizio da un Ingress e se la porta di servizio è associata a un 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
  # Associate the Service with Pods that have the same label.
  labels:
    purpose: bsc-config-demo
  annotations:
    # Associate TCP port 80 with a BackendConfig.
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  # Forward requests from port 80 in the Service to port 8080 in a member Pod.
  - port: 80
    protocol: TCP
    targetPort: 8080

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

• Qualsiasi pod con l'etichetta purpose: bsc-config-demo è membro del servizio.
• La porta TCP 80 del servizio è associata a un BackendConfig denominato my-backendconfig. L'annotazione cloud.google.com/backend-config lo specifica.
• 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 indirizzate alla porta 80 del servizio denominato my-service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  # Route all HTTP requests to port 80 in a Service.
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-service
            port:
              number: 80

Per creare l'oggetto Ingress, esegui questo comando:

kubectl apply -f my-ingress.yaml

Attendi alcuni minuti 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 svuotamento della connessione di 60 secondi.

Convalida delle proprietà del servizio di backend

Puoi verificare che le impostazioni del bilanciatore del carico corrette siano state applicate tramite BackendConfig. Per farlo, identifica il servizio di backend che Ingress ha implementato e controlla le relative impostazioni per verificare che corrispondano ai manifest di Deployment.

Per prima cosa, descrivi la risorsa my-ingress e filtra l'annotazione che elenca i servizi di backend associati all'ingresso. 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 tuoi 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 (server 404).
  • 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.

Successivamente, esamina il servizio di backend associato a my-service utilizzando gcloud. Filtra in base a "drainingTimeoutSec" e "timeoutSec" per verificare 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 relativi valori sono stati impostati correttamente tramite BackendConfig.

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

BackendConfig presenta le seguenti limitazioni:

• Una sola coppia (servizio, porta) può utilizzare un solo BackendConfig, anche se più oggetti Ingress fanno riferimento alla coppia (servizio, porta). Ciò significa che tutti gli oggetti Ingress che fanno riferimento allo stesso (servizio, porta) devono utilizzare la stessa configurazione per Cloud Armor, IAP e Cloud CDN.

• IAP e Cloud CDN non possono essere abilitati per lo stesso servizio di backend del bilanciamento del carico HTTP(S). Ciò significa che non puoi configurare sia IAP che Cloud CDN nella stessa BackendConfig.

• Per interagire con BackendConfig, devi utilizzare kubectl 1.7 o versioni successive.

Rimozione della configurazione specificata in un FrontendConfig o BackendConfig

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

Per cancellare o disattivare 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 disattiva 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 un FrontendConfig o BackendConfig

FrontendConfig

Per eliminare un FrontendConfig:

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

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

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

Attenzione: non eliminare un oggetto FrontendConfig prima di rimuovere il relativo nome dall'annotazione networking.gke.io/v1beta1.FrontendConfig e applicare il manifest Ingress aggiornato. In questo caso, la configurazione non viene rimossa dal servizio di backend del bilanciamento del carico HTTP(S). Inoltre, vedrai gli errori come eventi Kubernetes nell'oggetto Ingress.

BackendConfig

Per eliminare un BackedConfig:

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

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

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

Attenzione: non eliminare un oggetto BackendConfig prima di rimuovere il relativo nome dall'annotazione cloud.google.com/backend-config e applicare il manifest del servizio aggiornato. In questo caso, la configurazione non viene rimossa dal servizio di backend del bilanciamento del carico HTTP(S). Inoltre, vedrai gli errori come eventi Kubernetes nell'oggetto Ingress.

Risoluzione dei problemi

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

BackendConfig non trovato

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

Per valutare un evento Kubernetes, esegui questo comando:

kubectl get event

Il seguente output di esempio 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 digitato in modo errato il riferimento nell'annotazione di servizio.

Policy di sicurezza in entrata non trovata

Dopo aver creato l'oggetto Ingress, se la norma di sicurezza non è associata correttamente al servizio LoadBalancer, valuta l'evento Kubernetes per verificare se è presente un errore di configurazione. Se BackendConfig specifica un criterio di sicurezza inesistente, viene generato periodicamente un evento di avviso.

Per valutare un evento Kubernetes, esegui questo comando:

kubectl get event

Il seguente output di esempio 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 corretto del criterio di sicurezza in BackendConfig.

Risoluzione degli errori della serie 500 con i NEG durante lo scaling dei workload in GKE

Sintomo:

Quando utilizzi i NEG di GKE di cui è stato eseguito il provisioning per il bilanciamento del carico, potresti riscontrare errori 502 o 503 per i servizi durante lafare lo scale downe del workload. 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ò influire sui cluster se utilizzi prodotti di bilanciamento del carico gestito da GKE che utilizzano i NEG, inclusi Gateway, Ingress e i NEG autonomi. Se esegui spesso lo scale dei carichi di lavoro, il rischio che il cluster venga interessato è maggiore.

Diagnosi:

La rimozione di un pod in Kubernetes senza svuotare il relativo endpoint e rimuoverlo dal NEG prima comporta errori della serie 500. Per evitare problemi durante l'interruzione del pod, devi considerare l'ordine delle operazioni. Le seguenti immagini mostrano gli scenari quando BackendService Drain Timeout non è impostato e BackendService Drain Timeout è impostato con BackendConfig.

Nota: la seguente soluzione non è efficace per risolvere altri errori della serie 500 derivanti da preemptions di pod o nodi in GKE, in particolare nel caso di GKE con VM spot e VM preemptible.

Scenario 1: BackendService Drain Timeout non è impostato.

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

Scenario 2: BackendService Drain Timeout è impostato.

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

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

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

• Latenza di svuotamento: la latenza di svuotamento è il tempo impiegato dal bilanciatore del carico per iniziare a reindirizzare il traffico lontano da una particolare parte del sistema. Dopo l'avvio dello svuotamento, il bilanciatore del carico smette di inviare nuove richieste all'endpoint, ma esiste ancora una latenza nell'attivazione dello svuotamento (latenza di svuotamento) che può causare errori 503 temporanei se il pod non esiste più.

• Configurazione del controllo di integrità: soglie di controllo di integrità più sensibili 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 distacco non è terminata.

• Periodo di tolleranza per l'arresto: il periodo di tolleranza per l'arresto determina il tempo massimo concesso a un pod per uscire. Tuttavia, un pod può uscire prima del completamento del periodo di tolleranza prima di arrestarsi. Se un pod impiega più tempo di questo periodo, viene forzato a uscire al termine del periodo. Si tratta di un'impostazione del pod e deve essere configurata nella definizione del workload.

Potenziale soluzione:

Per evitare questi errori 5XX, applica le seguenti impostazioni. I valori di timeout sono indicativi 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 un hook preStop:

Per evitare errori della serie 500, segui questi passaggi:

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

   Nota: se il tempo medio di richiesta è superiore a 30 secondi, consulta la sezione Personalizzare i timeout per personalizzare BackendService Drain Timeout.

   • Per gli utenti Ingress, vedi impostare il timeout su BackendConfig.

   • Per gli utenti del gateway, vedi configurare il timeout in GCPBackendPolicy.

   • Per chi gestisce direttamente i propri BackendService quando utilizza i NEG autonomi, consulta Impostare il timeout direttamente sul servizio di backend.

2. Estendi terminationGracePeriod sul pod.

   Imposta terminationGracePeriodSeconds sul pod su 3,5 minuti. Se combinata con le impostazioni consigliate, questa opzione consente ai pod di avere una finestra di 30-45 secondi per un arresto normale dopo che l'endpoint del pod è stato rimosso dal NEG. Se hai bisogno di più tempo per l'arresto normale, puoi estendere il periodo di tolleranza o seguire le istruzioni riportate nella sezione Personalizzare i timeout.

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

   spec:
     terminationGracePeriodSeconds: 210
     containers:
     - name: my-app
       ...
     ...
   

3. Applica un hook preStop a tutti i contenitori.

   Applica un hook preStop che garantisca che il pod rimanga attivo per 120 secondi in più mentre l'endpoint del pod viene svuotato nel bilanciatore del carico e l'endpoint viene rimosso dal NEG.

   Nota: applica l'hook preStop a ogni contenitore nel pod. I container senza l'hook verranno chiusi non appena il pod viene eliminato. Se utilizzi uno strumento che inserisce contenitori, assicurati che i contenitori inseriti abbiano l'hook preStop richiesto.

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

Personalizzare i timeout

Per garantire la continuità del pod ed evitare errori della serie 500, il pod deve essere attivo finché l'endpoint non viene rimosso dal NEG. Nello specifico, per evitare errori 502 e 503, valuta la possibilità di implementare una combinazione di timeout e un hook preStop.

Nota: se la configurazione del controllo di integrità è impostata per rilevare immediatamente gli errori, potrebbe portare i bilanciatori del carico a interrompere l'invio di richieste prima, riducendo potenzialmente il verificarsi di errori 503. Tuttavia, tieni presente che potrebbero comunque verificarsi errori 503 durante la durata della soglia non integra. È essenziale comprendere che la configurazione dei controlli di integrità non impedisce gli errori 502, che si verificano quando le connessioni esistenti vengono terminate prematuramente.

Per mantenere il pod attivo più a lungo durante la procedura di spegnimento, aggiungi un hook preStop al pod. Esegui l'hook preStop prima che a un pod venga segnalato di uscire, in modo che l'hook preStop possa essere utilizzato per mantenere attivo il pod finché il relativo endpoint non viene rimosso dal NEG.

Per estendere la durata di attività di un pod durante la procedura di arresto, inserisci un hook preStop nella configurazione del pod nel seguente modo:

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

Nota: nei pod multi-container, assicurati di aggiungere l'hook preStop a ogni container per mantenerli tutti attivi. Solo i container con l'hook in esecuzione e il resto si arresta. Se utilizzi uno strumento che aggiunge contenitori, assicurati che anche questi abbiano l'hook preStop necessario.

Puoi configurare i timeout e le impostazioni correlate per gestire l'arresto controllato dei pod durante la riduzione dei carichi di lavoro. Puoi modificare i timeout in base a casi d'uso specifici. Ti consigliamo di iniziare con timeout più lunghi e ridurre la durata in base alle necessità. Puoi personalizzare i timeout configurando i parametri correlati al timeout e l'hook preStop nei seguenti modi:

Timeout di svuotamento del 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 Gateway o manualmente su BackendService con NEG autonomi. Il timeout deve essere da 1,5 a 2 volte più lungo del tempo necessario per elaborare una richiesta. In questo modo, se una richiesta è arrivata subito prima dell'avvio dello svuotamento, verrà completata prima del completamento del timeout. L'impostazione del parametro Backend Service Drain Timeout su un valore maggiore di 0 contribuisce a ridurre gli errori 503 perché non vengono inviate nuove richieste agli endpoint la cui rimozione è pianificata. Affinché questo timeout sia efficace, devi utilizzarlo con l'hook preStop per garantire che il pod rimanga attivo durante lo scaricamento. Senza questa combinazione, le richieste esistenti che non sono state completate riceveranno un errore 502.

preStop hook time

L'hook preStop deve ritardare l'arresto del pod sufficientemente per consentire il completamento sia della latenza di svuotamento sia del timeout di svuotamento del servizio di backend, garantendo lo svuotamento corretto della connessione e la rimozione dell'endpoint dal NEG prima dell'arresto del pod.

Per risultati ottimali, assicurati che il tempo di esecuzione dell'hook preStop sia maggiore o uguale alla somma della latenza di Backend Service Drain Timeout e di scaricamento.

Calcola il tempo di esecuzione ideale dell'hook preStop con la seguente formula:

preStop hook execution time >= BACKEND_SERVICE_DRAIN_TIMEOUT + DRAIN_LATENCY

Sostituisci quanto segue:

• BACKEND_SERVICE_DRAIN_TIMEOUT: l'ora che hai configurato per Backend Service Drain Timeout.
• DRAIN_LATENCY: un tempo stimato per la latenza di svuotamento. Ti consigliamo di utilizzare un minuto come stima.

Se gli errori 500 persistono, stima la durata totale dell'occorrenza e aggiungi il doppio di questo tempo alla latenza di svuotamento stimata. In questo modo, il Pod ha abbastanza tempo per scaricarsi gradualmente prima di essere rimosso dal servizio. Puoi modificare questo valore se è troppo lungo per il tuo caso d'uso specifico.

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

Parametro Periodo di tolleranza per la chiusura

Devi configurare il parametro terminationGracePeriod per consentire un tempo sufficiente per il completamento dell'hook preStop e per il completamento di un arresto controllato del pod.

Per impostazione predefinita, se non viene impostato esplicitamente, il valore di terminationGracePeriod è 30 secondi. Puoi calcolare il terminationGracePeriod ottimale utilizzando la formula:

terminationGracePeriod >= preStop hook time + Pod shutdown time

Per definire terminationGracePeriod all'interno della configurazione del pod nel seguente modo:

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

NEG non trovato durante la creazione di una risorsa Ingress interno

Quando crei un Ingress interno 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é Ingress per i bilanciatori del carico delle applicazioni interni richiede gruppi di endpoint di rete (NEG) come backend.

Negli ambienti VPC condiviso o nei cluster con i criteri di rete abilitati, aggiungi l'annotazione cloud.google.com/neg: '{"ingress": true}' al manifest del servizio.

504 Gateway Timeout: timeout della richiesta upstream

Quando accedi a un servizio da un ingresso interno in GKE, potrebbe verificarsi il seguente errore:

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 sottoposto a proxy dai proxy Envoy nell'intervallo di subnet solo proxy.

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

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

Quando accedi a un servizio da un ingresso interno in GKE, potrebbe verificarsi il seguente errore:

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

Quando viene eseguito l'upgrade del control plane GKE o quando modifichi un oggetto Ingress, potrebbe verificarsi uno dei seguenti errori:

"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 i seguenti passaggi:

• Aggiungi il campo hosts nella sezione tls del manifest Ingress, poi elimina Ingress. Attendi cinque minuti affinché GKE elimini le risorse Ingress inutilizzate. Quindi, ricrea l'ingresso. Per maggiori informazioni, vedi Il campo hosts di un oggetto Ingress.
• Ripristina le modifiche apportate all'Ingress. A questo punto, aggiungi un certificato utilizzando un'annotazione o un secret Kubernetes.

Problemi noti

Non è possibile attivare i reindirizzamenti HTTPS con lo schema di denominazione Ingress V1

Non puoi abilitare i reindirizzamenti HTTPS sulle risorse Ingress di GKE create nelle versioni GKE 1.16.8-gke.12 e precedenti. Devi ricreare l'ingresso prima di poter attivare i reindirizzamenti HTTPS, altrimenti viene creato un evento di errore e l'ingresso non viene sincronizzato.

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

Esiste un problema noto per cui l'aggiornamento di una risorsa BackendConfig utilizzando l'API v1beta1 rimuove una policy di sicurezza Cloud Armor attiva dal relativo servizio. Questo problema interessa le seguenti versioni di GKE:

• 1.18.19-gke.1400 a 1.18.20-gke.5099
• 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 Cloud Armor sulle risorse Ingress tramite BackendConfig, questo problema non influisce sui tuoi cluster.

Per i cluster GKE che configurano Cloud Armor tramite BackendConfig, è vivamente consigliato aggiornare le risorse BackendConfig solo utilizzando l'API v1. L'applicazione di un BackendConfig al cluster utilizzando le risorse BackendConfig rimuoverà la policy di sicurezza Cloud Armor dal servizio a cui fa riferimento.v1beta1

Per risolvere questo problema, aggiorna BackendConfig solo utilizzando l'API BackendConfig.v1 v1 BackendConfig supporta tutti gli stessi campi di v1beta1 e non introduce modifiche che causano interruzioni, quindi il campo API può essere aggiornato in modo trasparente. Sostituisci il campo apiVersion di tutti i manifest BackendConfig attivi 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 Cloud Armor potrebbe essere stato rimosso. Puoi determinare se si è verificato eseguendo il comando seguente:

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

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

Se i criteri di sicurezza di Cloud Armor sono stati rimossi, puoi determinare quando sono stati rimossi utilizzando la seguente query 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, il problema può essere corretto eseguendo il push di un aggiornamento alla risorsa BackendConfig che utilizza l'API v1.

Esegui l'upgrade del control plane GKE a una delle seguenti versioni aggiornate che correggono questo problema e consentono di utilizzare in sicurezza le risorse v1beta1 BackendConfig:

• 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

• GKE Ingress per il bilanciamento del carico a cluster singolo.

• Tutorial su Ingress per il deployment del routing HTTP(S) per le app GKE.

• Implementa GKE Ingress con un controllo di integrità HTTP personalizzato