Configurazione di Ingress su Google Cloud

Autopilota Standard

---

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 la configurazione di Ingress utilizzando il controller predefinito, i parametri FrontendConfig e i parametri BackendConfig.

Questa pagina è rivolta agli esperti di networking che progettano e progettano la rete per la propria organizzazione e installano, configurano e supportano le apparecchiature di rete. A scopri di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento per i contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.

Confronto delle funzioni

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

Classe in entrata	Ingresso esterno	Ingress interno	Ingress multi-cluster
Controller Ingress	Controller Ingress in hosting su Google
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
Supporto dell'ambiente	GKE	GKE	GKE
Supporto di VPC condivisi	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 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+^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 di 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 mediante 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 una risorsa Ingress utilizzando il controller predefinito, puoi scegliere il tipo del bilanciatore del carico (un bilanciatore del carico delle applicazioni esterno o un bilanciatore del carico delle applicazioni interno) utilizzando un sull'oggetto Ingress. Puoi scegliere se GKE crea NEG a livello di zona o se utilizza gruppi di istanze utilizzando un'annotazione Oggetto di servizio.

FrontendConfig e BackendConfig definizioni di risorse personalizzate (CRD) consentono di personalizzare ulteriormente il bilanciatore del carico. Questi 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 su cui è abilitato il componente aggiuntivo per il bilanciamento del carico HTTP. Il bilanciamento del carico HTTP è attivo per impostazione predefinita nei cluster GKE e non devi disattivarlo.

A FrontendConfigs viene fatto riferimento in un oggetto Ingress e può essere utilizzato solo con ingressi esterni. Le configurazioni BackendConfig a cui fa riferimento un oggetto Service. Per la coerenza della configurazione, è possibile fare riferimento agli stessi CRD da più oggetti Service o Ingress. Le CRD FrontendConfig e BackendConfig condividono lo stesso ciclo di vita delle risorse Ingress e Service corrispondenti e spesso vengono implementate 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 modello Google Cloud Criterio SSL.

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

Figura: panoramica di BackendConfig e FrontendConfig

Associazione di FrontendConfig alla tua risorsa 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 di FrontendConfig.

Associazione BackendConfig al tuo Ingress

Puoi utilizzare lo 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 nella annotazione. Il controller Ingress utilizza la stessa BackendConfig ogni volta 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 Ingress che per MultiClusterIngress Google Cloud.

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 corrispondente 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 un'entità BackendConfig esistente.
• BACKENDCONFIG_REFERENCE_B: il nome di un elemento esistente BackendConfig.
• 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 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 i probe di traffico o di 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 del servizio a cui si fa riferimento targetPort (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 fa riferimentonodePort.

• Quando usi 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 da il numero spec.ports[].port del Servizio. Per informazioni dettagliate sui numeri di porta per i controlli di integrità, consulta Configurazione di controlli di integrità personalizzati.

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

Configurazione delle funzionalità di Ingress tramite i parametri FrontendConfig

La seguente sezione mostra come impostare FrontendConfig per attivare specifiche Funzionalità in entrata.

Criteri SSL

I criteri SSL ti consentono di specificare un set di versioni TLS e crittografie che il bilanciatore del carico utilizza per terminare HTTPS proveniente dai client. Devi prima creare un criterio SSL al di fuori di GKE. Una volta creato, puoi fare riferimento a questo valore in un FrontendConfig CRD.

Il campo sslPolicy in 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, creato per il bilanciatore del carico HTTP(S) esterno da Ingress. Uguale Risorsa FrontendConfig e criterio SSL è possibile fare riferimento a più risorse Ingress. Se un criterio SSL di riferimento viene modificata, la modifica viene propagata ai Google Front End (GFE) che supportano il bilanciatore del carico HTTP(S) esterno creato da 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 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'Ingress sulla porta 80 vengono reindirizzate automaticamente allo stesso indirizzo IP esterno sulla porta 443. Questo è basata su HTTP-HTTPS reindirizzamenti forniti da Cloud Load Balancing.

Per supportare il reindirizzamento da HTTP a HTTPS, è necessario configurare un Ingress per gestire il traffico sia HTTP che HTTPS. Se HTTP o HTTPS è disabilitato, il reindirizzamento non funzioneranno.

I reindirizzamenti da HTTP ad 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 verranno abilitati i reindirizzamenti HTTPS.

Il seguente manifest FrontendConfig consente i reindirizzamenti da HTTP a HTTPS. Imposta il campo spec.redirectToHttps.enabled su true per attivare i reindirizzamenti HTTPS. La 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 (impostazione predefinita 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:

Per verificare che il reindirizzamento funzioni, 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 è per un FrontendConfig configurato con un 301: MovedPermanently reindirizzamento:

<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 riportate di seguito mostrano come impostare BackendConfig per attivare funzionalità Ingress specifiche. Le modifiche a una risorsa BackendConfig vengono costantemente riconciliato, quindi non devi eliminare e ricreare il file Ingress Vengono applicate le modifiche apportate a BackendConfig.

Per informazioni sui limiti di BackendConfig, consulta limitazioni.

Timeout del servizio di backend

Puoi utilizzare BackendConfig per impostare 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 attivare Cloud CDN utilizzando un BackendConfig.

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

Il seguente manifest BackendConfig mostra tutti i campi disponibili quando viene attivato 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 è attivato per questo backend di 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 memorizzati nella cache separatamente.
• INCLUDE_QUERY_STRING: se impostato su true, i parametri della stringa di query vengono inclusi nella chiave della cache in base a queryStringBlacklist o queryStringWhitelist. Se non è impostato nessuno dei due, 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 della 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 della query i parametri di stringa da includere nelle chiavi cache. Tutti gli altri parametri sono esclusi. Puoi queryStringBlacklist o queryStringWhitelist, ma non entrambi.

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

• CACHE_MODE: la modalità cache.
• CLIENT_TTL, DEFAULT_TTL e MAX_TTL: configurazione del TTL. Per ulteriori informazioni, consulta la sezione Utilizzare le impostazioni e gli override TTL.
• NEGATIVE_CACHING: se impostato su true, memorizzazione nella cache negativa sia abilitato. Per ulteriori informazioni, vedi Utilizzo della memorizzazione nella cache negativa.
• NEGATIVE_CACHING_CODE e NEGATIVE_CACHING_TTL: configurazione della memorizzazione nella cache negativa. Per ulteriori informazioni, consulta la sezione Utilizzare la memorizzazione nella cache negativa.
• REQ_COALESCING: se impostato su true, la compressione è in un bucket in cui è abilitato il controllo delle versioni. Per ulteriori informazioni, vedi Richiedi compressione (coalescing).
• 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: tempo massimo in secondi per cui le risposte possono essere memorizzate nella cache. Per ulteriori informazioni, consulta Personalizzare facoltativamente il tempo massimo della cache.
• KEY_NAME, KEY_VALUE e SECRET_NAME: configurazione della chiave dell'URL firmato. Per ulteriori informazioni, vedi Creazione di chiavi di richiesta firmate.

Espandi la sezione seguente per vedere un esempio che esegue il deployment di Cloud CDN tramite Ingress e convalida la memorizzazione nella cache dei contenuti dell'applicazione.

Esempio di Cloud CDN

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

1. Crea uno spazio dei nomi dedicato in cui eseguire 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 di BackendConfig. Il manifest specifica un criterio di cache Cloud CDN e dichiara che Cloud CDN deve essere attivato:

     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 in base al seguente manifest del servizio:

   apiVersion: v1
   kind: Service
   metadata:
     namespace: cdn-how-to
     name: my-service
     labels:
       purpose: demonstrate-cdn
     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 in base al seguente manifest di 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:
     - 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 per la configurazione del controller Kubernetes Ingress da un bilanciatore del carico Google Cloud, per poi recuperare l'indirizzo IP usato dal carico le regole di forwarding del bilanciatore del servizio di bilanciamento del carico dalla risorsa Ingress.

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

    Uscita:

    Address:         ADDRESS
    

    ADDRESS è l'indirizzo IP esterno di Ingress.

Convalida la memorizzazione nella cache di Cloud CDN

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

curl -v ADDRESS/?cache=true

Sostituisci ADDRESS con il tuo indirizzo IP esterno Ingress.

L'output mostra le intestazioni e il corpo della risposta. Nelle intestazioni di risposta, puoi vedere che i contenuti sono stati memorizzati nella cache. L'intestazione Age indica quanti secondi sono trascorsi dall'ultima memorizzazione nella cache dei contenuti:

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 ti accorgi che i tuoi contenuti non vengono memorizzati nella cache, assicurati di l'applicazione sia configurata correttamente per abilitare la memorizzazione nella cache dei contenuti. Per ulteriori informazioni, vedi Contenuti memorizzabili nella cache.

Pulizia

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

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

Timeout per svuotamento della connessione

Puoi configurare il timeout per lo 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, alle richieste esistenti al backend rimosso viene concesso il tempo di completarsi. Il bilanciatore del carico non invia nuove richieste al backend rimosso. Una volta raggiunta la durata del timeout, tutte le connessioni rimanenti al backend sono chiusi. La durata del timeout può essere compresa tra 0 e 3600 secondi. Il valore predefinito è 0, che disattiva anche lo svuotamento delle connessioni.

Avviso: impostazione di un valore alto per drainingTimeoutSec (ad es. 3600) secondi) su una risorsa Ingress o un servizio che utilizza gruppi di istanze causerà ritardi proporzionale alla durata impostata in drainingTimeoutSec quando aggiornare altre risorse Ingress nel cluster. Questo perché tutte le istanze risorse Ingress basate su gruppi in un cluster condividono lo stesso gruppo di istanze. Se hai bisogno di un valore elevato, valuta la possibilità di utilizzare i servizi basati su gruppi di endpoint di rete.

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

Esistono diversi modi in cui GKE configura i controlli di integrità del bilanciatore del carico Google Cloud durante il deployment tramite Ingress. Per saperne di più su come GKE Ingress esegue il deployment dei controlli di integrità, consulta Controlli di integrità in entrata.

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

Nota: Ingress non supporta gRPC per le configurazioni dei controlli di integrità personalizzati.

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

Il seguente manifest di BackendConfig mostra tutti i campi disponibili durante la configurazione di un controllo dell'integrità di 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 il parametro check-interval, in secondi, per ogni prober del controllo di integrità. Si tratta del tempo che intercorre dall'inizio del controllo di un sondatore all'inizio del controllo successivo. Se ometti questo parametro, viene utilizzato il valore predefinito di 5 secondi di Google Cloud. Per ulteriori dettagli di implementazione, consulta Più probe e frequenza.
• TIMEOUT: specifica la quantità di 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à di misura sono in secondi. Ogni probe richiede Codice di risposta HTTP 200 (OK) da consegnare prima del timeout del probe.
• HEALTH_THRESHOLD e UNHEALTHY_THRESHOLD: specifica i campi numero di tentativi di connessione sequenziali che devono avere esito positivo o negativo, per almeno un prober per modificare stato di integrità da uno stato sano a uno insalubre 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 creando controlli di integrità utilizzando i protocolli HTTP, HTTPS o HTTP2. Per maggiori informazioni le informazioni, vedi 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 il request-path a cui deve connettersi il sistema di monitoraggio. Se ometti questo parametro, Google Cloud utilizza il valore predefinito di /.

• PORT: una proprietà BackendConfig supporta solo la specifica del bilanciatore del carico una porta per il controllo di integrità numero predefinito. Se ometti questo parametro, Google Cloud utilizza il valore predefinito 80.

  • Quando utilizzi il caricamento nativo del container bilanciato, devi selezionare una porta corrispondente a containerPort di un pod di gestione (a prescindere dal fatto che containerPort faccia riferimento o meno a targetPort di al Servizio). Poiché il bilanciatore del carico invia probe all'IP del pod, direttamente un indirizzo, non sei limitato a containerPort a cui fa riferimento un targetPort del servizio. I sistemi di probe per il controllo di integrità si connettono a un servizio Indirizzo IP del pod sulla porta specificata.

  • Per i backend dei gruppi di istanze, devi selezionare una porta corrispondente a una nodePort esposta dal servizio. I sistemi di probe del controllo di integrità si connettono quindi 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 tue 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 un 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"

Avviso: non modificare direttamente le risorse BackendService all'interno di Compute Engine per collegare i tuoi criteri Google Cloud Armor ai tuoi criteri e i servizi di backend.

Due fonti di verità

Anche se configurate tramite GKE, le API BackendService Compute Engine sottostanti possono comunque essere utilizzate per modificare direttamente il criterio di sicurezza da applicare. Questo crea due fonti di dati: 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 comportamento imprevisto, consigliamo di utilizzare GKE BackendConfig per la gestione dei criteri di sicurezza da usare.

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 di ingressi 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 Ingress di GKE con la protezione di Google Cloud Armor, consulta Ingress abilitato per Google Cloud Armor.

Log degli accessi HTTP

Nota: per impostazione predefinita, GKE abilita il logging degli accessi per tutto il traffico in entrata (incluso Ingress multi-cluster). Impostazione di logging degli accessi per GKE Ingress non era supportato per le versioni GKE precedenti al 1.16.8-gke.10. Per le versioni GKE 1.16.8-gke.10 o successive, puoi configurare l'impostazione di logging degli accessi per Ingress di GKE tramite BackendConfig.

Ingress può registrare tutte le richieste HTTP inviate dai client a Cloud Logging. Puoi attivare e disattivare accesso al logging utilizzando BackendConfig insieme all'impostazione della frequenza di campionamento del logging degli accessi.

Per configurare il logging degli accessi, utilizza il campo logging in BackendConfig. Se viene omesso, il logging 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à attivata per questo 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 non sono presenti pacchetti e 1,0 significa che viene registrato il 100% dei pacchetti. Questo campo è pertinente solo se enable è impostato su true. sampleRate è un campo facoltativo, ma se configurato, anche enable: true deve essere impostato, altrimenti viene interpretato come enable: false.

Il seguente manifest BackendConfig attiva la registrazione 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 IAP Identity-Aware Proxy, 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.

Nota: non puoi attivare sia IAP che Cloud CDN in un BackendConfig. Se BackendConfig non ha un blocco iap, tutte 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 gli acquisti in-app con il client OAuth gestito da Google

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

Per abilitare IAP con il client OAuth gestito da Google, non forniscono le credenziali OAuth 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 (rimuovi il servizio dall'Ingress e ricollegalo). Ti consigliamo di eseguire questa operazione durante un periodo di manutenzione, in quanto causerà un tempo di riposo. La migrazione opposta è possibile passare da OAuthClient a OAuthCredentials gestito da Google.

Il seguente manifest BackendConfig abilita Identity-Aware Proxy con Google Managed Client OAuth:

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

Nota: se utilizzi gli acquisti in-app sulle 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 del servizio, esegui l'upgrade alla versione 1.29.4-gke.1043000 del cluster GKE.

Identity-Aware Proxy con Ingress interno

Per configurare Ingress interno per l'IAP, devi utilizzare il livello Premium. Se non utilizzi il livello Premium, non puoi visualizzare o creare Application Load Balancer interni Identity-Aware Proxy. Devi anche disporre di Chrome Enterprise Premium per utilizzare il traffico interno in entrata 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à alla sessione sull'IP del client o sul cookie generato.

Importante: utilizza un cluster nativo della VPC se vuoi configurare l'affinità di sessione. L'affinità sessione è utile solo per 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 file BackendConfig per impostare l'affinità IP del 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"

Affinità cookie generata

Per utilizzare BackendConfig per impostare affinità 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 BackendConfig per configurare intestazioni della richiesta definite dall'utente. Il bilanciatore del carico aggiunge le intestazioni specificate alle richieste inoltrate ai backend.

Il bilanciatore del carico aggiunge intestazioni delle richieste personalizzate solo alle richieste del client, non ai probe del controllo di integrità. Se il tuo 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 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 attivare le intestazioni delle risposte personalizzate, specifica un elenco di intestazioni nella sezione Proprietà customResponseHeaders della risorsa BackendConfig. Specifica ogni intestazione come stringa header-name:header-value.

Gli intestazioni di risposta personalizzate sono disponibili solo nei cluster GKE 1.25 e versioni successive.

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

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 tramite una risorsa Ingress con una risorsa BackendConfig.

Per configurare le proprietà di backend di un 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 un Ingress e associalo alla coppia (Service, port).
5. Convalida le proprietà del servizio di backend.
6. Esegui la pulizia.

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 questo comando:

kubectl apply -f my-deployment.yaml

Creazione di un oggetto BackendConfig

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

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 di servizio e porta, anche se un servizio ha più porte. Ogni porta può essere associata a un singolo CRD di BackendConfig. Se una porta di servizio viene richiamata da un Ingress e se la porta di servizio è associata a un BackendConfig, il servizio di backend del 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 le porte e gli oggetti BackendConfig. In my-service.yaml:

• Qualsiasi pod con l'etichetta purpose: bsc-config-demo è membro di il Servizio.
• La porta TCP 80 del servizio è associata a una 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 il seguente 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 arrivo 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 alcuni minuti affinché il controller Ingress configuri un bilanciatore del carico delle applicazioni esterno e un servizio di backend associato. Una volta completata l'operazione, configurato la tua risorsa Ingress in modo da utilizzare un timeout di 40 secondi e uno svuotamento della connessione di 60 secondi.

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

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

Per prima cosa, descrivi la risorsa my-ingress e filtra per l'annotazione che elenca i servizi di backend associati all'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 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.

A questo punto, controlla il servizio di backend associato a my-service utilizzando gcloud. Filtra per "drainingTimeoutSec" e "timeoutSec" per verificare che siano stati impostati nel control plane 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

Se vedi drainingTimeoutSec e timeoutSec nell'output, significa 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

BackendConfigs presenta le seguenti limitazioni:

• Una sola coppia (servizio, porta) può utilizzare un solo 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.

• IAP e Cloud CDN non possono essere attivati 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 FrontendConfig o BackendConfig

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

Per cancellare o disattivare una configurazione attivata in precedenza, imposta il valore del campo a una stringa vuota ("") o a un valore booleano di false, in base al tipo di campo.

Il seguente manifest di 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 FrontendConfig o BackendConfig

FrontendConfig

Per eliminare un FrontendConfig:

1. Rimuovi il nome di FrontendConfig dal Annotazione networking.gke.io/v1beta1.FrontendConfig in Ingress del file manifest.

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 averne rimosso il nome da l'annotazione networking.gke.io/v1beta1.FrontendConfig e applicare lo stato Manifest Ingress. In questo caso, la configurazione non viene rimossa Servizio di backend di bilanciamento del carico HTTP(S). Inoltre, vedrai gli errori come eventi Kubernetes nell'oggetto Ingress.

BackendConfig

Per eliminare un BackedConfig:

1. Rimuovi il nome BackendConfig dal 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, utilizza kubectl delete backendconfig my-backendconfig.

Attenzione: non eliminare un oggetto BackendConfig prima di averne rimosso il nome da l'annotazione cloud.google.com/backend-config e applicare lo stato Manifest del servizio. In questo caso, la configurazione non viene rimossa Servizio di backend di bilanciamento del carico HTTP(S). Inoltre, vedrai gli errori come eventi Kubernetes nell'oggetto Ingress.

Risoluzione dei problemi

Puoi rilevare gli errori di configurazione più comuni utilizzando Strumento di diagnostica di Ingress. Devi inoltre assicurarti che tutti i controlli di integrità siano configurati correttamente.

BackendConfig non trovato

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

Per valutare un evento Kubernetes, esegui il seguente 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 questo problema, assicurati di non aver creato la risorsa BackendConfig nello spazio dei nomi sbagliato o errori di ortografia nel suo riferimento nell'annotazione Service.

Criterio di sicurezza in entrata non trovato

Dopo aver creato l'oggetto Ingress, se il criterio di sicurezza non è associato correttamente al servizio LoadBalancer, valuta l'evento Kubernetes per verificare se è presente un errore di configurazione. Se BackendConfig specifica un criterio di sicurezza che non esiste, periodicamente viene emesso un evento di avviso.

Per valutare un evento Kubernetes, esegui il seguente comando:

kubectl get event

L'esempio di output 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 nel BackendConfig.

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

Sintomo:

Quando utilizzi NEG di GKE di cui è stato eseguito il provisioning per il bilanciamento del carico, potresti riscontrare errori 502 o 503 per i servizi durante il ridimensionamento del carico di lavoro. 502 gli errori si verificano quando i pod vengono arrestati 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 i prodotti di bilanciamento del carico gestiti da GKE che utilizzano gli NEG, tra cui Gateway, Ingress e NEG autonomi. Se esegui spesso il ridimensionamento dei carichi di lavoro, il tuo cluster è più a rischio di essere interessato.

Diagnosi:

Rimuovere un pod in Kubernetes senza svuotare il relativo endpoint e rimuoverlo da il NEG prima porta a errori della serie 500. Per evitare problemi durante il pod risoluzione, devi considerare l'ordine delle operazioni. Le seguenti immagini rappresentano scenari in cui BackendService Drain Timeout non è impostato e BackendService Drain Timeout è impostato con BackendConfig.

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

Scenario 1: BackendService Drain Timeout non è impostato.

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

Scenario 2: è impostato BackendService Drain Timeout.

La seguente immagine 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 scollegamento API NEG: la latenza di scollegamento API NEG rappresenta la latenza attuale Tempo impiegato per finalizzare l'operazione di scollegamento in Google Cloud. Questo valore è influenzato da una serie di fattori esterni a Kubernetes, tra cui il tipo di bilanciatore del carico e la zona specifica.

• Latenza di scarico: la latenza di scarico rappresenta il tempo impiegato per il bilanciatore del carico. per iniziare a indirizzare il traffico lontano da una determinata parte del sistema. Una volta avviato il ritiro, il bilanciatore del carico smette di inviare nuove richieste all'endpoint, ma esiste ancora una latenza nell'attivazione del ritiro (Latenza ritiro) che può causare errori 503 temporanei se il pod non esiste più.

• Configurazione del controllo di integrità: le soglie di controllo di integrità più sensibili si riducono. la durata degli errori 503, in quanto può segnalare l'arresto del bilanciatore del carico di inviare richieste agli endpoint anche se l'operazione di scollegamento non è terminata.

• Periodo di tolleranza per l'interruzione: il periodo di tolleranza per l'interruzione determina il tempo massimo concesso a un pod per uscire. Tuttavia, un pod può uscire prima del completamento del periodo di tolleranza prima dell'interruzione. Se un pod impiega più tempo di questo periodo, viene costretto a uscire al termine di questo periodo. Questa è un'impostazione nel pod deve essere configurato 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:

Per evitare errori della serie 500:

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

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

   • Per gli utenti in entrata, vedi Impostare il timeout nella BackendConfig.

   • Per gli utenti di Gateway, vedi configurare il timeout su GCPBackendPolicy.

   • Per coloro che gestiscono direttamente i propri servizi di backend quando utilizzano la modalità autonoma NEG, vedi Impostare il timeout direttamente nel servizio di backend.

2. Estendi terminationGracePeriod sul pod.

   Imposta terminationGracePeriodSeconds sul pod su 3,5 minuti. Se abbinata alle impostazioni consigliate, questa impostazione consente ai pod di avere un intervallo di 30-45 secondi per un arresto graduale dopo la rimozione dell'endpoint del pod dal NEG. Se hai bisogno di più tempo per la chiusura controllata, puoi per 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 garantisca che il pod rimanga attivo per altri 120 secondi mentre l'endpoint del pod viene svuotato nel bilanciatore del carico e l'endpoint viene rimosso dal NEG.

   Nota: applica preStopHook a ogni contenitore del pod. In assenza di questo, i container senza hook vengono chiusi non appena il pod viene eliminati. Se utilizzi uno strumento che inietta contenitori, assicurati che i contenitori iniettati abbiano il preStopHook richiesto.

   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 a quando l'endpoint non viene rimosso dal NEG. In particolare, per evitare errori 502 e 503, prendi in considerazione l'implementazione di una combinazione di timeout e un preStopHook.

Nota: se la configurazione del controllo di integrità è impostata per rilevare immediatamente gli errori, i bilanciatori del carico potrebbero smettere di inviare richieste prima, potenzialmente riducendo la frequenza degli errori 503. Tuttavia, tieni presente che gli errori 503 possono verificarsi anche durante la durata della soglia non corretta. È essenziale è consapevole 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 più a lungo durante il processo di arresto, aggiungi preStopHook a all'interno del pod. Esegui preStopHook prima che un pod venga segnalato per uscire, in modo che È possibile utilizzare preStopHook per tenere il pod a portata di mano fino all'endpoint corrispondente viene rimosso dal NEG.

Per estendere la durata del 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>"]

Nota: nei pod multi-container, assicurati di aggiungere preStopHook a ogni il container per mantenere attivi tutti i container. Senza questo, solo i container con l'hook viene eseguito e il resto si ferma. Se utilizzi uno strumento che aggiunge contenitori, assicurati che i contenitori aggiunti abbiano anche il valore preStopHook necessario.

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

Timeout svuotamento servizio di backend

Il parametro Backend Service Drain Timeout non è impostato per impostazione predefinita e non è associato effetto. Se imposti e attivi il parametro Backend Service Drain Timeout, il bilanciatore del carico smette di inoltrare le nuove richieste all'endpoint e attende il timeout prima di terminare le connessioni esistenti.

Puoi impostare il parametro Backend Service Drain Timeout utilizzando il metodo BackendConfig con Ingress, GCPBackendPolicy con gateway o manualmente attivo il BackendService con NEG autonomi. Il timeout deve essere compreso tra 1,5 e 2 volte rispetto al tempo necessario per elaborare una richiesta. In questo modo, se una richiesta viene inviata poco prima dell'avvio dello scarico, verrà completata prima del timeout. L'impostazione del parametro Backend Service Drain Timeout su un valore un valore maggiore di 0 aiuta a mitigare gli errori 503 perché non vengono inviate nuove richieste agli endpoint di cui è stata pianificata la rimozione. Affinché questo timeout venga applicato, è necessario usalo insieme a preStopHook per assicurarti che il pod resti durante 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 per completare sia la latenza di svuotamento sia il timeout di svuotamento del servizio di backend, garantendo un corretto svuotamento delle connessioni e la rimozione degli endpoint dal NEG prima dell'arresto del pod.

Per risultati ottimali, assicurati che il tempo di esecuzione di preStopHook sia inferiore a 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 scarico su 1 minuto. Se gli errori 500 rimangono invariati, stima la durata totale dell'occorrenza e aggiungi il doppio dell'intervallo a una latenza. Ciò garantisce che il pod abbia tempo sufficiente per svuotarsi con cautela prima di essere rimossi dal servizio. Puoi modificare se è troppo lungo per il tuo caso d'uso specifico.

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

Parametro Periodo di tolleranza per il recesso

Devi configurare il parametro terminationGracePeriod in modo da concedere tempo sufficiente per il completamento di preStopHook e per l'arresto graduale del pod.

Per impostazione predefinita, se non impostato esplicitamente, terminationGracePeriod è pari a 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 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 condivisi o nei cluster con i criteri di rete abilitati, 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 una Ingress 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 proxy Envoy nella configurazione proxy un intervallo di subnet.

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

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

Potrebbe verificarsi il seguente errore quando accedi a un servizio da una Ingress 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

Quando esegui l'upgrade del piano di controllo GKE o 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."

In alternativa:

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. Attendi cinque minuti per consentire a GKE di eliminare le risorse Ingress non utilizzate. Quindi, ricrea la risorsa Ingress. Per ulteriori informazioni, vedi Il campo hosts di un oggetto Ingress.
• Ripristina le modifiche apportate a Ingress. Aggiungi un certificato utilizzando un'annotazione o un secret Kubernetes.

Problemi noti

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

Non puoi attivare i reindirizzamenti HTTPS nelle risorse Ingress di GKE create nelle versioni GKE 1.16.8-gke.12 e precedenti. Tu devi ricreare l'oggetto Ingress prima di poter abilitare i reindirizzamenti HTTPS, oppure viene creato un evento di errore e la risorsa Ingress non viene 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.

I campi dei criteri di sicurezza di Google Cloud Armor sono stati rimossi da BackendConfig

Esiste un problema noto per cui l'aggiornamento di una risorsa BackendConfig utilizzando l'v1beta1 API rimuove un criterio di sicurezza Google Cloud Armor attivo dal 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 risorse Ingress tramite la configurazione di BackendConfig, questo problema non influisce sui tuoi cluster.

Per i cluster GKE che configurano Google Cloud Armor tramite la risorsa BackendConfig, è fortemente consigliato aggiornare solo le risorse BackendConfig utilizzando l'API v1. Applicazione di una BackendConfig al cluster utilizzando v1beta1 Le risorse BackendConfig rimuoveranno il tuo criterio di sicurezza di Google Cloud Armor dal Servizio a cui fa riferimento.

Per ridurre il problema, apporta aggiornamenti a BackendConfig solo utilizzando l'v1 API BackendConfig. v1 BackendConfig supporta tutti gli stessi campi di v1beta1 e non apporta modifiche che comportano interruzioni, pertanto il campo dell'API può essere aggiornato in modo trasparente. Sostituisci il campo apiVersion di tutti i manifest di 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 di BackendConfig, assicurati di utilizzare il gruppo di 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. Puoi verificare se ciò si è verificato eseguendo questo comando:

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

Se la risposta restituisce un output, il problema riguarda il tuo cluster. 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 introdotto. Eventuali aggiornamenti futuri a BackendConfig devono 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 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 correggono il 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 singolo cluster.

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

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