Questa pagina fornisce una panoramica completa di ciò che è supportato e configurabile tramite Kubernetes Ingress su Google Cloud.
Confronto delle funzionalità
La tabella seguente fornisce un elenco delle funzionalità supportate per Ingress su Google Cloud. Viene indicata anche la disponibilità della funzionalità, ovvero la disponibilità generale (GA) o beta.
Classe in entrata | In entrata esterna | In entrata interna | In entrata multi-cluster | ||
---|---|---|---|---|---|
Controller Ingress | Controller Ingress ospitato da Google | Controller GKE Ingress | |||
Tipo di bilanciatore del carico Google Cloud | Bilanciatore del carico HTTP(S) esterno | Bilanciatore del carico HTTP(S) interno | Bilanciatore del carico HTTP(S) esterno | ||
Ambito cluster | Cluster singolo | Cluster singolo | Cluster multipli | ||
Ambito del bilanciatore del carico | Globale | Regionale | Globale | ||
Supporto dell'ambiente | GKE | GKE | GKE | ||
Supporto per VPC condivisi | GA | GA | GA | ||
Annotazioni dei servizi | |||||
Bilanciamento del carico (NEG) nativo del container | GA | GA | GA | ||
HTTPS dal bilanciatore del carico ai backend | GA | GA | GA | ||
HTTP/2 | GA | GA Solo TLS |
GA | ||
Annotazioni in entrata | |||||
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 | ||
Criteri di sicurezza di Google Cloud Armor | GA
1.19.10-gke.700G |
GA | |||
Configurazione del logging degli accessi HTTP | GA | GA | GA | ||
Identity-Aware Proxy (IAP) | GA | GA | GA | ||
Affinità sessione | GA | GA | GA | ||
Intestazioni delle richieste definite dall'utente | GA | GA | |||
Intestazioni delle risposte personalizzate | GA
1.25-gke+G |
GA
1.25-gke+G |
B Questa funzionalità è disponibile in versione beta a partire dalla versione specificata. Le funzionalità senza una versione elencata sono supportate per tutte le versioni di GKE disponibili.
G Questa funzionalità è supportata in disponibilità generale a partire dalla versione specificata.
Configurazione di Ingress con il controller predefinito
Non puoi configurare manualmente le funzionalità LoadBalancer utilizzando Google Cloud SDK o la console Google Cloud. Devi usare le risorse Kubernetes BackendConfig o FrontendConfig.
Quando crei una risorsa Ingress utilizzando il controller predefinito, puoi scegliere il tipo di bilanciatore del carico (Application Load Balancer esterno o Application Load Balancer interno) utilizzando un'annotazione sull'oggetto Ingress. Puoi scegliere se GKE deve creare NEG a livello di zona o se utilizzare gruppi di istanze utilizzando un'annotazione su ciascun oggetto di servizio.
Le definizioni di risorse personalizzate (CRD) di FrontendConfig e BackendConfig consentono di personalizzare ulteriormente il bilanciatore del carico. Questi CRD consentono di definire funzionalità aggiuntive del bilanciatore del carico in modo gerarchico e più strutturato rispetto alle annotazioni. Per utilizzare Ingress (e questi CRD), devi abilitare il componente aggiuntivo per il bilanciamento del carico HTTP. Il bilanciamento del carico HTTP è abilitato nei cluster GKE per impostazione predefinita; non devi disabilitarlo.
I FrontendConfig fanno riferimento a un oggetto Ingress e possono essere utilizzati solo con Ingress esterni. Un oggetto Service fa riferimento a BackendConfig. Più oggetti Service o Ingress possono fare riferimento agli stessi CRD per la coerenza della configurazione. I CRD FrontendConfig e BackendConfig condividono lo stesso ciclo di vita delle risorse Ingress e Service corrispondenti e spesso il deployment viene eseguito insieme.
Il seguente diagramma illustra come:
Un'annotazione su un oggetto Ingress o MultiClusterIngress fa riferimento a un CRD FrontendConfig. Il CRD FrontendConfig fa riferimento a un criterio SSL di Google Cloud.
Un'annotazione su un oggetto Service o MultiClusterService fa riferimento a un CRD BackendConfig. Il CRD BackendConfig specifica le impostazioni personalizzate per il controllo di integrità del servizio di backend corrispondente.
Associazione di FrontendConfig al tuo Ingress
FrontendConfig può essere utilizzato solo con risorse Ingress esterne.
Puoi associare un FrontendConfig a un Ingress o a unMultiClusterIngress
.
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 del servizio
Per utilizzare lo stesso BackendConfig per tutte le porte, usa 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.
default
per le risorse Ingress e MultiClusterIngress.
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...
BackendConfig univoco per porta del servizio
Sia per Ingress che per 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 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 valorePORT_NUMBER_1
oPORT_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 valorePORT_NUMBER_2
oPORT_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 l'associazione di BackendConfig; non controlla la porta a cui il bilanciatore del carico invia il traffico o i probe 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) sul
targetPort
della porta di servizio di riferimento (che deve corrispondere a uncontainerPort
per un pod di gestione). In caso contrario, il bilanciatore del carico invia il traffico all'indirizzo IP di un nodo sulnodePort
della porta di servizio di riferimento.Quando utilizzi un BackendConfig per fornire un controllo di integrità personalizzato del bilanciatore del carico, il numero di porta che utilizzi per il controllo di integrità del bilanciatore del carico può essere diverso dal numero
spec.ports[].port
del servizio. Per maggiori dettagli sui numeri di porta per i controlli di integrità, consulta Configurazione personalizzata del controllo di integrità.
Configurazione delle funzionalità di Ingress tramite i parametri FrontendConfig
La seguente sezione mostra come impostare FrontendConfig per abilitare funzionalità specifiche di Ingress.
Criteri SSL
I criteri SSL consentono di specificare un insieme di versioni e crittografie TLS utilizzate dal bilanciatore del carico per terminare il traffico HTTPS proveniente dai client. Devi prima creare un criterio SSL all'esterno di GKE. Una volta creato, puoi farvi riferimento in una
CRD FrontendConfig
.
Il campo sslPolicy
in FrontendConfig fa riferimento al nome di un criterio SSL nello stesso progetto Google Cloud del cluster GKE. Associa il criterio SSL al proxy HTTPS di destinazione, creato per il bilanciatore del carico HTTP(S) esterno da Ingress. Più risorse Ingress possono fare riferimento alla stessa risorsa FrontendConfig e allo stesso criterio SSL. Se un criterio SSL a cui viene fatto riferimento viene modificato, la modifica viene propagata ai Google Front End (GFE) che alimentano 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 una risorsa Ingress con i reindirizzamenti da HTTP a HTTPS abilitati, entrambi i bilanciatori del carico vengono creati automaticamente. Le richieste all'indirizzo IP esterno del server Ingress sulla porta 80 vengono reindirizzate automaticamente allo stesso indirizzo IP esterno sulla porta 443. Questa funzionalità è basata sui reindirizzamenti da HTTP a HTTPS forniti da Cloud Load Balancing.
Per supportare il reindirizzamento da HTTP a HTTPS, è necessario configurare una risorsa Ingress per gestire il traffico sia HTTP che HTTPS. Se HTTP o HTTPS è disattivato, 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 per tutti i servizi a cui fa riferimento l'oggetto Ingress saranno
abilitati i reindirizzamenti HTTPS.
Il seguente manifest FrontendConfig
abilita i reindirizzamenti da HTTP a HTTPS. Imposta il campo spec.redirectToHttps.enabled
su true
per abilitare i reindirizzamenti HTTPS. Il campo spec.responseCodeName
è facoltativo. Se 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 valori:
MOVED_PERMANENTLY_DEFAULT
per restituire un codice di risposta di reindirizzamento 301 (valore predefinito seresponseCodeName
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 il funzionamento del reindirizzamento, utilizza un comando curl
:
curl http://IP_ADDRESS
Sostituisci IP_ADDRESS
con l'indirizzo IP del tuo traffico in entrata.
La risposta mostra il codice di risposta di reindirizzamento che hai configurato. Ad esempio
il seguente esempio è per un elemento 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à di Ingress tramite parametri BackendConfig
Le sezioni seguenti mostrano come impostare BackendConfig per abilitare funzionalità specifiche di Ingress. Le modifiche a una risorsa BackendConfig vengono costantemente riconciliate, quindi non è necessario eliminare e ricreare la risorsa Ingress per vedere che le modifiche BackendConfig vengono applicate.
Per informazioni sulle limitazioni di BackendConfig, consulta la sezione limitazioni.
Timeout del servizio di backend
Puoi utilizzare 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.
Il seguente manifest BackendConfig mostra tutti i campi disponibili durante l'abilitazione di Cloud CDN:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
cdn:
enabled: CDN_ENABLED
cachePolicy:
includeHost: INCLUDE_HOST
includeProtocol: INCLUDE_PROTOCOL
includeQueryString: INCLUDE_QUERY_STRING
queryStringBlacklist: QUERY_STRING_DENYLIST
queryStringWhitelist: QUERY_STRING_ALLOWLIST
cacheMode: CACHE_MODE
clientTtl: CLIENT_TTL
defaultTtl: DEFAULT_TTL
maxTtl: MAX_TTL
negativeCaching: NEGATIVE_CACHING
negativeCachingPolicy:
code: NEGATIVE_CACHING_CODE
ttl: NEGATIVE_CACHING_TTL
requestCoalescing: REQ_COALESCING
serveWhileStale: SERVE_WHILE_STALE
signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
signedUrlKeys:
keyName: KEY_NAME
keyValue: KEY_VALUE
secretName: SECRET_NAME
Sostituisci quanto segue:
CDN_ENABLED
: se è impostato sutrue
, Cloud CDN è abilitato per questo backend in entrata.INCLUDE_HOST
: se il criterio viene impostato sutrue
, le richieste a host diversi vengono memorizzate nella cache separatamente.INCLUDE_PROTOCOL
: se viene impostato sutrue
, le richieste HTTP e HTTPS vengono memorizzate nella cache separatamente.INCLUDE_QUERY_STRING
: se è impostato sutrue
, i parametri della stringa di query vengono inclusi nella chiave cache in base aqueryStringBlacklist
oqueryStringWhitelist
. Se nessuno dei due è impostato, viene inclusa l'intera stringa di query. Se impostato sufalse
, l'intera stringa di query viene esclusa dalla chiave cache.QUERY_STRING_DENYLIST
: specifica un array di stringhe con i nomi dei parametri di stringa di query da escludere dalle chiavi cache. Sono inclusi tutti gli altri parametri. Puoi specificarequeryStringBlacklist
oqueryStringWhitelist
, ma non entrambi.QUERY_STRING_ALLOWLIST
: specifica un array di stringhe con i nomi dei parametri della stringa di query da includere nelle chiavi cache. Tutti gli altri parametri sono esclusi. PuoiqueryStringBlacklist
oqueryStringWhitelist
, ma non entrambi.
I seguenti campi sono supportati solo nelle versioni GKE 1.23.3-gke.900 e successive utilizzando GKE Ingress. Non sono supportati se si utilizzano Ingress multi-cluster:
CACHE_MODE
: la modalità cache.CLIENT_TTL
,DEFAULT_TTL
eMAX_TTL
: configurazione TTL. Per ulteriori informazioni, consulta la sezione Utilizzo delle impostazioni e degli override TTL.NEGATIVE_CACHING
: se viene impostata sutrue
, viene abilitata la memorizzazione nella cache negativa. Per maggiori informazioni, consulta Utilizzo della memorizzazione nella cache negativa.NEGATIVE_CACHING_CODE
eNEGATIVE_CACHING_TTL
: configurazione della memorizzazione nella cache negativa. Per maggiori informazioni, consulta Utilizzo della memorizzazione nella cache negativa.REQ_COALESCING
: se è impostata sutrue
, la compressione è attivata. Per maggiori informazioni, consulta Richiesta di compressione (coalescenza).SERVE_WHILE_STALE
: tempo in secondi dopo la scadenza della risposta in cui Cloud CDN continua a gestire una versione obsoleta. Per ulteriori informazioni, consulta la sezione Pubblicare contenuti obsoleti.SIGNED_MAX_AGE
: tempo massimo per le risposte che possono essere memorizzate nella cache, in secondi. Per maggiori informazioni, consulta Personalizzare eventualmente il tempo massimo della cache.KEY_NAME
,KEY_VALUE
eSECRET_NAME
: configurazione della chiave URL firmata. Per maggiori informazioni, consulta la pagina relativa alla creazione di chiavi di richiesta firmate.
Espandi la sezione seguente per vedere un esempio che esegue il deployment di Cloud CDN tramite Ingress, quindi verifica che i contenuti dell'applicazione vengano memorizzati nella cache.
Timeout per svuotamento della connessione
Puoi configurare il timeout per lo svuotamento della connessione utilizzando un BackendConfig. Il timeout per 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 completare. Il bilanciatore del carico non invia nuove richieste al backend rimosso. Una volta raggiunta la durata del timeout, tutte le altre connessioni al backend vengono chiuse. La durata del timeout può essere compresa tra 0 e 3600 secondi. Il valore predefinito è 0, che disabilita anche lo svuotamento della connessione.
Il seguente manifest BackendConfig specifica un timeout di 60 secondi per lo svuotamento della connessione:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
connectionDraining:
drainingTimeoutSec: 60
Configurazione personalizzata del controllo di integrità
GKE configura i controlli di integrità del bilanciatore del carico Google Cloud in vari modi durante il deployment tramite Ingress. Per scoprire di più su come GKE Ingress esegue il deployment dei controlli di integrità, consulta Controlli di integrità in entrata.
BackendConfig consente di controllare con precisione le impostazioni del controllo di integrità del bilanciatore del carico.
Puoi configurare più servizi GKE in modo che facciano riferimento allo stesso
BackendConfig come un modello riutilizzabile. Per i parametri healthCheck
, viene creato un controllo di integrità univoco di Google Cloud per ogni servizio di backend corrispondente a ciascun servizio GKE.
Il seguente manifest BackendConfig mostra tutti i campi disponibili durante la configurazione di un controllo di integrità BackendConfig:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
healthCheck:
checkIntervalSec: INTERVAL
timeoutSec: TIMEOUT
healthyThreshold: HEALTH_THRESHOLD
unhealthyThreshold: UNHEALTHY_THRESHOLD
type: PROTOCOL
requestPath: PATH
port: PORT
Sostituisci quanto segue:
INTERVAL
: specifica ilcheck-interval
, in secondi, per ogni prober del controllo di integrità. È il tempo che intercorre tra l'inizio di un controllo del prober e quello del successivo. Se ometti questo parametro, viene utilizzato il valore predefinito di Google Cloud di 5 secondi. Per ulteriori dettagli sull'implementazione, consulta Più probe e frequenza.TIMEOUT
: specifica il tempo di attesa di Google Cloud per una risposta a un probe. Il valore diTIMEOUT
deve essere minore o uguale al valore diINTERVAL
. Le unità sono i secondi. Ogni probe richiede la consegna di un codice di rispostaHTTP 200 (OK)
prima del timeout del probe.HEALTH_THRESHOLD
eUNHEALTHY_THRESHOLD
: specifica il numero di tentativi di connessione sequenziali che devono avere esito positivo o negativo, 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 dei probe per il controllo di integrità. L'BackendConfig
supporta solo la creazione di controlli di integrità utilizzando i protocolli HTTP, HTTPS o HTTP2. Per ulteriori informazioni, consulta i 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 il parametrorequest-path
a cui deve connettersi il sistema del probe. Se ometti questo parametro, Google Cloud utilizza il valore predefinito/
.PORT
: un BackendConfig supporta solo la specifica della porta per il controllo di integrità del bilanciatore del carico utilizzando un numero di porta. Se ometti questo parametro, Google Cloud utilizza il valore predefinito80
.Quando utilizzi il bilanciamento del carico nativo del container, devi selezionare una porta corrispondente a
containerPort
di un pod di pubblicazione (indipendentemente dal fatto che un valoretargetPort
del servizio faccia riferimento acontainerPort
). Poiché il bilanciatore del carico invia i probe direttamente all'indirizzo IP del pod, non hai limitazioni aicontainerPort
indicati nel valoretargetPort
di un servizio. I sistemi probe del controllo di integrità si connettono all'indirizzo IP di un pod di gestione sulla porta specificata.Per i backend di gruppi di istanze, devi selezionare una porta corrispondente a una
nodePort
esposta dal servizio. I sistemi probe del controllo di integrità si connettono a ciascun nodo su quella porta.
Per configurare GKE Ingress con un controllo di integrità HTTP personalizzato, consulta GKE Ingress con controllo di integrità HTTP personalizzato.
Criterio di sicurezza in entrata di Google Cloud Armor
I criteri di sicurezza di Google Cloud Armor consentono di proteggere le applicazioni con bilanciamento del carico dagli attacchi basati sul web. Dopo aver configurato un criterio di sicurezza di Google Cloud Armor, puoi farvi riferimento utilizzando 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"
Due fonti di verità
Sebbene siano configurate tramite GKE, le API BackendService
di Compute Engine sottostanti possono comunque essere utilizzate per modificare direttamente il criterio di sicurezza da applicare. Questo crea due origini 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 e comportamenti imprevisti, consigliamo di utilizzare l'BackendConfig
di GKE per gestire i criteri di sicurezza da utilizzare.
Campo BackendConfig | Valore | Comportamento |
---|---|---|
spec.securityPolicy.name |
CloudArmorPolicyName |
Il controller GKE Ingress imposta il criterio Google Cloud Armor denominato CloudArmorPolicyName sul bilanciatore del carico. Il controller GKE Ingress sovrascrive qualsiasi criterio impostato in precedenza. |
spec.securityPolicy.name |
Stringa vuota ("" ) |
Il controller GKE Ingress rimuove dal bilanciatore del carico qualsiasi criterio Google Cloud Armor configurato. |
spec.securityPolicy |
nil |
Il controller GKE Ingress 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 di Google Cloud Armor, consulta Google Cloud Armor abilitato per Ingress.
Logging degli accessi HTTP
Ingress può registrare tutte le richieste HTTP dai client in Cloud Logging. Puoi abilitare e disabilitare il logging degli accessi utilizzando BackendConfig e impostando la frequenza di campionamento del logging degli accessi.
Per configurare il logging degli accessi, utilizza il campo logging
in BackendConfig. Se logging
viene omesso, il logging degli accessi assume il comportamento predefinito. Dipende dalla versione di GKE.
Puoi configurare i seguenti campi:
enable
: se impostato sutrue
, il logging degli accessi sarà abilitato per questo Ingress e i log saranno disponibili in Cloud Logging. In caso contrario, 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 stati registrati pacchetti e 1,0 indica che viene registrato il 100% dei pacchetti. Questo campo è pertinente solo seenable
è impostato sutrue
.sampleRate
è un campo facoltativo, ma se è configurato, ancheenable: true
deve essere impostato, altrimenti viene interpretato comeenable: false
.
Il seguente manifest BackendConfig consente il logging 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
in BackendConfig. Per specificare questi valori, assicurati di disporre dell'autorizzazione compute.backendServices.update
.
Il seguente manifest BackendConfig abilita Identity-Aware Proxy:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
iap:
enabled: true
oauthclientCredentials:
secretName: my-secret
Abilita IAP con client OAuth gestito da Google
A partire da GKE 1.29.2-gke.1035000, IAP può essere configurato per l'utilizzo del client OAuth gestito da Google mediante BackendConfig. Per decidere se utilizzare il client Google OAuth o un client OAuth personalizzato, vedi Quando utilizzare una configurazione OAuth personalizzata nella documentazione di IAP.
Per abilitare IAP con il client OAuth gestito da Google, non fornire le credenziali OAuth in BackendConfig. Per gli utenti che hanno già configurato IAP utilizzando credenziali OAuth, non esiste un percorso di migrazione per passare all'utilizzo del client OAuth gestito da Google, devi ricreare il backend (rimuovere il servizio da Ingress e ricollegarlo). Ti consigliamo di eseguire questa operazione durante un periodo di manutenzione perché causerà tempi di inattività. Il percorso di migrazione opposto è il passaggio da OAuthClient 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 le istruzioni complete, consulta Abilitazione di IAP per GKE nella documentazione di IAP.
Identity-Aware Proxy con Ingress interno
Per configurare Ingress 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. Devi anche avere un abbonamento a BeyondCorp Enterprise per utilizzare Ingress interno per IAP.
Per configurare GKE Ingress sicuro con l'autenticazione basata su Identity-Aware Proxy, vedi un esempio In entrata abilitato per IAP.
Affinità sessione
Puoi utilizzare un BackendConfig per impostare l'affinità sessione sull'IP client o sul cookie generato.
Affinità IP client
Per utilizzare un BackendConfig per impostare
l'affinità IP client,
imposta affinityType
su "CLIENT_IP"
, come nell'esempio seguente:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
sessionAffinity:
affinityType: "CLIENT_IP"
Affinità cookie generata
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 deve rimanere attivo.
Il seguente manifest imposta il tipo di affinità sul cookie generato e fornisce 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 le intestazioni delle richieste definite dall'utente. Il bilanciatore del carico aggiunge le intestazioni specificate alle richieste inoltrate ai backend.
Per abilitare le intestazioni delle richieste definite dall'utente, devi specificare un elenco di intestazioni nella proprietà customRequestHeaders
della risorsa BackendConfig. Specifica ogni
intestazione come una stringa header-name:header-value
.
Il seguente manifest BackendConfig aggiunge tre intestazioni di richiesta:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
customRequestHeaders:
headers:
- "X-Client-Region:{client_region}"
- "X-Client-City:{client_city}"
- "X-Client-CityLatLong:{client_city_lat_long}"
Intestazioni delle risposte personalizzate
Per abilitare intestazioni delle risposte personalizzate, specifica un elenco di intestazioni nella proprietà customResponseHeaders
della risorsa BackendConfig. Specifica ogni
intestazione come una stringa header-name:header-value
.
Le intestazioni delle risposte personalizzate sono disponibili solo nei cluster GKE versione 1.25 e successive.
Il seguente manifest BackendConfig è un esempio di aggiunta di un'intestazione della 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 Ingress mediante un servizio di backend
L'esercizio seguente mostra i passaggi necessari per configurare i timeout e lo svuotamento della connessione con una risorsa Ingress con una risorsa BackendConfig.
Per configurare le proprietà di backend di una risorsa Ingress, completa le seguenti attività:
- Crea un deployment.
- Crea un BackendConfig.
- Crea un servizio e associa una delle sue porte al BackendConfig.
- Crea un oggetto Ingress e associa quest'ultimo alla coppia (Servizio, porta).
- Convalida le proprietà del servizio di backend.
- Esegui la pulizia.
Creazione di un deployment
Prima di creare un BackendConfig e un Service, devi creare un Deployment.
Il manifest di esempio seguente è 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 BackendConfig
Usa il tuo BackendConfig per specificare le funzionalità di Ingress che vuoi usare.
Questo manifest BackendConfig, denominato my-backendconfig.yaml
, specifica:
- Uno timeout di 40 secondi.
- Un timeout di 60 secondi per lo svuotamento della connessione.
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
timeoutSec: 40
connectionDraining:
drainingTimeoutSec: 60
Crea il backendConfig eseguendo questo comando:
kubectl apply -f my-backendconfig.yaml
Crea un Service
Un BackendConfig corrisponde a una singola combinazione Service-Port, anche se un servizio ha più porte. Ogni porta può essere associata a un singolo CRD BackendConfig. Se una porta del servizio fa riferimento a una porta in entrata e se la porta del servizio è associata a un BackendConfig, il servizio di backend di bilanciamento del carico HTTP(S) utilizza parte della sua configurazione da BackendConfig.
Di seguito è riportato un esempio di manifest del servizio denominato my-service.yaml
:
# my-service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
purpose: bsc-config-demo
annotations:
cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
cloud.google.com/neg: '{"ingress": true}'
spec:
type: ClusterIP
selector:
purpose: bsc-config-demo
ports:
- port: 80
protocol: TCP
targetPort: 8080
L'annotazione cloud.google.com/backend-config
specifica una mappatura tra porte
e oggetti BackendConfig. Tra my-service.yaml
:
- Qualsiasi pod con l'etichetta
purpose: bsc-config-demo
è membro del servizio. - La porta TCP 80 del servizio è associata a un BackendConfig denominato
my-backendconfig
. È specificato dall'annotazionecloud.google.com/backend-config
. - Una richiesta inviata alla porta 80 del servizio viene inoltrata a uno dei pod membri sulla porta 8080.
Per creare il servizio, esegui questo comando:
kubectl apply -f my-service.yaml
Creare una risorsa Ingress
Di seguito è riportato un manifest Ingress denominato my-ingress.yaml.
. In questo esempio, le richieste in entrata vengono instradate alla porta 80 del servizio denominato my-service
.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: my-service
port:
number: 80
Per creare l'oggetto Ingress, esegui questo comando:
kubectl apply -f my-ingress.yaml
Attendi qualche minuto affinché il controller Ingress configuri un bilanciatore del carico delle applicazioni esterno e un servizio di backend associato. Al termine, avrai configurato Ingress in modo che utilizzi un timeout di 40 secondi e un timeout per lo svuotamento della connessione di 60 secondi.
Convalida delle proprietà del servizio di backend
Puoi verificare che le impostazioni corrette del bilanciatore del carico siano state applicate tramite BackendConfig. Per farlo, identifica il servizio di backend di cui è stato eseguito il deployment di Ingress e controlla le sue impostazioni per verificare che corrispondano ai manifest del deployment.
Innanzitutto, descrivi la risorsa my-ingress
e il filtro per l'annotazione che elenca i servizi di backend associati all'oggetto 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 Kubernetesmy-service
.k8s1-27fde173
è un hash utilizzato per descrivere il cluster.default
è lo spazio dei nomi di Kubernetes.HEALTHY
indica che il backend è integro.
"k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"
fornisce informazioni sul servizio di backend associato al backend predefinito (404-server).k8s1-27fde173
è un hash utilizzato per descrivere il cluster.kube-system
è lo spazio dei nomi.default-http-backend
è il nome del servizio Kubernetes.80
è la porta host.HEALTHY
indica che il backend è integro.
Quindi, controlla il servizio di backend associato a my-service
utilizzando gcloud
.
Filtra per "drainingTimeoutSec"
e "timeoutSec"
per confermare che siano stati impostati nel piano di controllo del bilanciatore del carico Google Cloud. Ad esempio:
# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500
# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"
Output:
drainingTimeoutSec: 60
timeoutSec: 40
La visualizzazione di drainingTimeoutSec
e timeoutSec
nell'output conferma che i relativi valori sono stati impostati correttamente tramite BackendConfig.
esegui la pulizia
Per evitare che al tuo account vengano addebitati costi indesiderati, 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
I BackendConfig hanno le seguenti limitazioni:
- Solo una coppia (servizio, porta) può consumare 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.
- Non è possibile abilitare IAP e Cloud CDN per lo stesso servizio di backend di bilanciamento del carico HTTP(S). Ciò significa che non puoi configurare sia IAP sia Cloud CDN nello stesso BackendConfig.
- Devi utilizzare
kubectl
1.7 o versioni successive per interagire con BackendConfig.
Rimozione della configurazione specificata in un FrontendConfig o BackendConfig
Per revocare una funzionalità Ingress, devi disabilitare esplicitamente la relativa configurazione 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 di false
, a seconda del tipo di campo.
Il seguente manifest BackendConfig disabilita un criterio di sicurezza di Google Cloud Armor e Cloud CDN:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
cdn:
enabled: false
securityPolicy:
name: ""
Eliminazione di un FrontendConfig o BackendConfig
FrontendConfig
Per eliminare un FrontendConfig:
Rimuovi il nome di FrontendConfig dall'annotazione
networking.gke.io/v1beta1.FrontendConfig
nel manifest Ingress.Applica al cluster il manifest Ingress modificato. Ad esempio, utilizza
kubectl apply
.Elimina FrontendConfig. Ad esempio, utilizza
kubectl delete frontendconfig config my-frontendconfig
.
BackendConfig
Per eliminare un BackedConfig, segui questi passaggi:
Rimuovi il nome di BackendConfig dall'annotazione
cloud.google.com/backend-config
nel manifest del servizio.Applica al cluster il manifest del servizio modificato. Ad esempio, utilizza
kubectl apply
.Elimina BackendConfig. Ad esempio, utilizza
kubectl delete backendconfig my-backendconfig
.
Risoluzione dei problemi
Puoi rilevare gli errori di configurazione più comuni usando lo 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 nell'annotazione di servizio viene specificato un BackendConfig per una porta del 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 questo problema, assicurati di non aver creato la risorsa BackendConfig nello spazio dei nomi sbagliato o di non aver scritto correttamente il relativo 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 il tuo BackendConfig specifica un criterio di sicurezza che non esiste, periodicamente viene emesso 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 questo problema, specifica il nome corretto del criterio di sicurezza in BackendConfig.
Affrontare gli errori della serie 500 con i NEG durante la scalabilità dei carichi di lavoro in GKE
Sintomo:
Quando utilizzi i NEG di cui è stato eseguito il provisioning di GKE per il bilanciamento del carico, potresti riscontrare errori 502 o 503 per i servizi durante lo fare lo scale down del carico di lavoro. Gli errori 502 si verificano quando i pod vengono terminati prima della chiusura delle connessioni esistenti, mentre gli errori 503 si verificano quando il traffico viene indirizzato ai pod eliminati.
Questo problema può interessare i cluster se utilizzi prodotti di bilanciamento del carico gestiti da GKE che utilizzano NEG, tra cui gateway, Ingress e NEG autonomi. Se scali frequentemente i tuoi carichi di lavoro, il rischio del cluster è maggiore di essere interessato.
Diagnosi:
La rimozione di un pod in Kubernetes senza svuotare l'endpoint e la sua rimozione dal NEG genera prima errori di tipo 500. Per evitare problemi durante la terminazione
del pod, devi considerare l'ordine delle operazioni. Nelle immagini seguenti
vengono visualizzati scenari quando il criterio BackendService Drain Timeout
non viene configurato e
BackendService Drain Timeout
è impostato su BackendConfig
.
Scenario 1: l'impostazione BackendService Drain Timeout
non è attiva.
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 scollegamento API NEG: la latenza di scollegamento dell'API NEG rappresenta il tempo attuale necessario per finalizzare l'operazione di scollegamento in Google Cloud. Ciò è influenzato da una serie di fattori esterni a Kubernetes, tra cui il tipo di bilanciatore del carico e la zona specifica.
Latenza di svuotamento: la latenza di svuotamento rappresenta il tempo impiegato dal bilanciatore del carico per iniziare a indirizzare il traffico da una determinata parte del sistema. Una volta avviato il download, il bilanciatore del carico smette di inviare nuove richieste all'endpoint, ma è ancora presente 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 più sensibili del controllo di integrità riducono la durata degli errori 503, in quanto possono indicare al bilanciatore del carico di interrompere l'invio di richieste agli endpoint anche se l'operazione di scollegamento non è terminata.
Periodo di tolleranza per la risoluzione: il periodo di tolleranza per la terminazione determina il periodo di tempo massimo concesso per uscire da un pod. Tuttavia, un pod può uscire prima del completamento del periodo di tolleranza per la terminazione. Se un pod impiega più tempo di questo periodo, viene forzata l'uscita dal pod alla fine di questo periodo. Questa è un'impostazione sul pod e deve essere configurata nella definizione del carico di lavoro.
Potenziale risoluzione:
Per evitare questi errori 5XX, applica le seguenti impostazioni. I valori di timeout sono indicativi e potresti dover modificarli per la tua applicazione specifica. La seguente sezione illustra il processo di personalizzazione.
L'immagine seguente mostra come mantenere attivo il pod con preStopHook
:
Per evitare errori della serie 500, segui questi passaggi:
Imposta
BackendService Drain Timeout
per il tuo servizio su 1 minuto.Per gli utenti Ingress, consulta Impostare il timeout in BackendConfig.
Per gli utenti del gateway, consulta Configurare il timeout in GCPBackendPolicy.
Per coloro che gestiscono direttamente i propri servizi di backend quando utilizzano NEG autonomi, consulta Impostare il timeout direttamente nel servizio di backend.
Estendi
terminationGracePeriod
nel pod.Imposta
terminationGracePeriodSeconds
sul pod su 3,5 minuti. Se combinata con le impostazioni consigliate, ciò consente ai pod una finestra di 30-45 secondi per un arresto controllato dopo che l'endpoint del pod è stato rimosso dal NEG. Se hai bisogno di più tempo per l'arresto controllato, puoi estendere il periodo di tolleranza o seguire le istruzioni indicate nella sezione Personalizzare i timeout.Il seguente manifest
BackendConfig
specifica un timeout per lo svuotamento della connessione di 210 secondi (3,5 minuti):apiVersion: v1 kind: BackendConfig metadata: name: my-backendconfig spec: terminationGracePeriodSeconds: 210 containers: - name: my-app image: my-app-image:latest ports: - containerPort: 80
Applica un'istruzione
preStopHook
a tutti i contenitori.Applica un valore
preStopHook
per garantire 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.apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-app # Container configuration details... lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 120s"]
Personalizza i 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. Per evitare errori di tipo 502 e 503, ti consigliamo di implementare una combinazione di timeout e preStopHook
.
Per mantenere attivo il pod più a lungo durante il processo di arresto, aggiungi un preStopHook
al
pod. Esegui preStopHook
prima che venga indicato l'uscita di un pod, in modo che preStopHook
possa essere utilizzato per mantenere il pod a disposizione fino a quando l'endpoint corrispondente non viene rimosso dal NEG.
Per estendere il periodo di tempo in cui un pod rimane attivo durante il processo di arresto, inserisci un valore preStopHook
nella configurazione del pod in questo modo:
spec:
containers:
- name: my-app
...
lifecycle:
preStopHook:
exec:
command: ["/bin/sh", "-c", "sleep <latency time>"]
Puoi configurare i timeout e le relative impostazioni per gestire l'arresto controllato dei pod durante lo scale down dei carichi di lavoro. Puoi regolare i timeout in base
a casi d'uso specifici. Ti consigliamo di iniziare con timeout più lunghi e di ridurre la durata in base alle necessità. Puoi personalizzare i timeout configurando i parametri correlati al timeout e preStopHook
nei seguenti modi:
Timeout dello 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 il routing delle nuove richieste all'endpoint e attende il timeout prima di terminare le connessioni esistenti.
Puoi impostare il parametro Backend Service Drain Timeout
utilizzando BackendConfig
con Ingress, GCPBackendPolicy
con il gateway o manualmente su BackendService
con NEG autonomi. Il timeout dovrebbe essere da 1,5 a 2 volte più lungo del tempo necessario per elaborare una richiesta. Ciò garantisce che se una richiesta
venga inviata poco 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 consente di mitigare gli errori 503 perché non vengono inviate nuove richieste agli endpoint di cui è stata pianificata la rimozione. Affinché questo timeout sia effettivo, devi utilizzarlo insieme a preStopHook
per assicurarti che il pod rimanga attivo durante lo svuotamento. Senza questa combinazione, le richieste esistenti non completate riceveranno un errore 502.
preStopHook
volta
preStopHook
deve ritardare l'arresto del pod a sufficienza affinché la latenza di svuotamento
e il timeout dello svuotamento del servizio di backend vengano completati, garantendo
un corretto svuotamento della connessione 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 o uguale alla somma di Backend Service Drain Timeout
e della latenza di svuotamento.
Può essere calcolato utilizzando la formula:
preStopHook >= Backend Service Drain Timeout + Drain Latency
Ti consigliamo di impostare la latenza di svuotamento su 1 minuto. Se persistono 500 errori, stima la durata totale dell'occorrenza e aggiungi il doppio di questo tempo alla latenza. Ciò garantisce che il pod abbia tempo a sufficienza per essere scaricato prima di essere rimosso dal servizio. Puoi modificare questo valore se è troppo lungo per il tuo caso d'uso specifico.
In alternativa, puoi stimare i tempi esaminando il timestamp di eliminazione dal pod e il timestamp in cui l'endpoint è stato rimosso dal NEG in Cloud Audit Logs.
Parametro del periodo di tolleranza per la risoluzione
Devi configurare il parametro terminationGracePeriod
per concedere tempo sufficiente per il completamento di preStopHook
e per il completamento di un arresto controllato dal pod.
Per impostazione predefinita, se non è impostata esplicitamente, terminationGracePeriod
è di 30 secondi.
Puoi calcolare il valore ottimale di terminationGracePeriod
utilizzando la formula:
terminationGracePeriod >= preStopHook Time + Pod shutdown time
Per definire terminationGracePeriod
all'interno della configurazione del pod come segue:
spec:
terminationGracePeriodSeconds: <terminationGracePeriod>
containers:
- name: my-app
...
...
NEG non trovato durante la creazione di una risorsa Ingress interna
Quando crei 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é il traffico in entrata per i bilanciatori del carico delle applicazioni interni richiede gruppi di endpoint di rete (NEG) come backend.
Negli ambienti o nei cluster VPC condivisi con criteri di rete abilitati, aggiungi l'annotazione cloud.google.com/neg: '{"ingress": true}'
al manifest del servizio.
504 Timeout gateway: 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 agli Application Load Balancer interni viene inviato tramite proxy dai proxy proxy nell'intervallo di subnet solo proxy.
Per consentire il traffico dall'intervallo di subnet solo proxy, crea una regola firewall su 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
Potrebbe verificarsi uno dei seguenti errori quando il piano di controllo GKE esegue l'upgrade o quando modifichi un oggetto Ingress:
"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."
Oppure:
Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid
Per risolvere questi problemi, prova a procedere nel seguente modo:
- Aggiungi il campo
hosts
nella sezionetls
del manifest Ingress, quindi elimina il file Ingress. Attendi cinque minuti affinché GKE elimini le risorse Ingress inutilizzate. Quindi, ricrea l'Ingress. Per ulteriori informazioni, consulta Il campo hosts di un oggetto Ingress. - Ripristina le modifiche apportate a Ingress. Quindi, aggiungi un certificato utilizzando un'annotazione o un secret di Kubernetes.
Problemi noti
Impossibile abilitare i reindirizzamenti HTTPS con lo schema di denominazione Ingress V1
Non puoi abilitare i reindirizzamenti HTTPS su risorse GKE Ingress create su GKE versione 1.16.8-gke.12 e precedenti. Devi ricreare l'oggetto Ingress prima di poter abilitare i reindirizzamenti HTTPS, altrimenti verrà creato un evento di errore e il traffico in entrata non verrà 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
Si è verificato un problema noto per cui l'aggiornamento di una risorsa BackendConfig mediante l'API v1beta1
rimuove un criterio di sicurezza attivo di Google Cloud Armor dal relativo 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 sulle tue risorse Ingress tramite BackendConfig, questo problema non interessa i tuoi cluster.
Per i cluster GKE che configurano Google 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 v1beta1
BackendConfig rimuoverà il criterio di sicurezza di Google Cloud Armor
dal servizio a cui fa riferimento.
Per limitare questo problema, aggiorna BackendConfig solo utilizzando l'API BackendConfig v1
. BackendConfig v1
supporta tutti gli stessi campi di v1beta1
e non apporta modifiche che provocano errori, in modo che il campo dell'API possa essere aggiornato in modo trasparente.
Sostituisci il campo apiVersion
di qualsiasi file manifest BackendConfig attivo con cloud.google.com/v1
e non utilizzare cloud.google.com/v1beta1
.
Il seguente manifest di esempio descrive una risorsa BackendConfig che utilizza l'API v1
:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backend-config
spec:
securityPolicy:
name: "ca-how-to-security-policy"
Se disponi di sistemi o strumenti CI/CD che aggiornano regolarmente le risorse BackendConfig, assicurati di utilizzare il gruppo API cloud.google.com/v1
in questi sistemi.
Se il tuo BackendConfig è già stato aggiornato con l'API v1beta1
,
il criterio di sicurezza di Google Cloud Armor potrebbe essere stato rimosso.
Puoi determinare se 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 cluster è interessato dal problema.
L'output di questo comando restituisce un elenco di risorse BackendConfig
(<namespace>/<name>
) interessate dal problema. Se l'output è vuoto,
significa che BackendConfig non è stato aggiornato utilizzando l'API v1beta1
da quando
è stato introdotto il problema. Eventuali aggiornamenti futuri a BackendConfig dovrebbero usare 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 o più dei tuoi cluster sono stati interessati, il problema può essere risolto eseguendo il push di un aggiornamento alla risorsa BackendConfig che utilizza l'API v1
.
Esegui l'upgrade del piano di controllo GKE
a una delle seguenti versioni aggiornate che corregge questo problema e consentono di utilizzare
v1beta1
le risorse BackendConfig in modo sicuro:
- 1.18.20-gke.5100 e versioni successive
- 1.19.14-gke.300 e versioni successive
- 1.20.9-gke.900 e versioni successive