Questa pagina fornisce una panoramica completa di ciò che è supportato e configurabile tramite Kubernetes Ingress su Google Cloud.
Confronto delle funzioni
La tabella seguente fornisce un elenco di funzionalità supportate per Ingress su Google Cloud. La disponibilità della funzionalità, Disponibilità generale (GA) o beta dell'immagine.
Classe in entrata | Ingress esterno | Ingress interno | Ingress multi-cluster | ||
---|---|---|---|---|---|
Controller Ingress | Controller Ingress ospitato da Google | Controller GKE Ingress | |||
Tipo di bilanciatore del carico Google Cloud | Bilanciatore del carico HTTP(S) esterno | Bilanciatore del carico HTTP(S) interno | Bilanciatore del carico HTTP(S) esterno | ||
Ambito cluster | Cluster singolo | Cluster singolo | Cluster multipli | ||
Ambito del bilanciatore del carico | Globale | Regionale | Globale | ||
Assistenza per l'ambiente | GKE | GKE | GKE | ||
Supporto di VPC condivisi | GA | GA | GA | ||
Annotazioni del servizio | |||||
Bilanciamento del carico (NEG) nativo del container | GA | GA | GA | ||
HTTPS dal bilanciatore del carico ai backend | GA | GA | GA | ||
HTTP/2 | GA | GA Solo TLS |
GA | ||
Annotazioni Ingress | |||||
Indirizzi IP statici | GA | GA | GA | ||
Certificati basati su secret di Kubernetes | GA | GA | GA | ||
Certificati SSL con gestione indipendente | GA | GA | GA | ||
Certificati SSL gestiti da Google | GA | GA | |||
FrontendConfig | |||||
Criterio SSL | GA | GA con gateway | GA | ||
Reindirizzamento da HTTP a HTTPS | GA
1.17.13-gke.2600+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.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. Funzionalità senza una versione elencata sono supportati per tutte le versioni GKE disponibili.
G Questa funzionalità è supportata in disponibilità generale a partire dalla versione specificata.
Configurazione di Ingress mediante il controller predefinito
Non puoi configurare manualmente le funzionalità di LoadBalancer utilizzando Google Cloud SDK o la console Google Cloud. Devi utilizzare BackendConfig o Risorse Kubernetes 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 consentono di definire funzionalità aggiuntive del bilanciatore del carico in modo gerarchico, in modo più strutturato rispetto alle annotazioni. Per utilizzare Ingress (e questi CRD), devi su cui è abilitato il componente aggiuntivo per il bilanciamento del carico HTTP. I cluster GKE Bilanciamento del carico HTTP abilitato per impostazione predefinita; non devi disattivarla.
Ai frontendConfig viene fatto riferimento in un oggetto Ingress e possono essere utilizzati solo con risorse Ingress esterne. Le configurazioni BackendConfig a cui fa riferimento un oggetto Service. Agli stessi CRD è possibile fare riferimento Oggetti Service o Ingress per garantire la coerenza della configurazione. Lo strumento FrontendConfig I CRD BackendConfig condividono lo stesso ciclo di vita dei file Ingress e delle risorse di servizio, spesso ne viene eseguito il deployment 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 un CRD BackendConfig. Il CRD BackendConfig specifica le impostazioni personalizzate per dal controllo di integrità del servizio di backend corrispondente.
Associazione di FrontendConfig alla tua risorsa Ingress
FrontendConfig può essere utilizzato solo con risorse Ingress esterne.
Puoi associare un FrontendConfig a una risorsa Ingress o a 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 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.
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
Sia per Ingress che per MultiClusterIngress, puoi specificare una configurazione BackendConfig personalizzata 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 elemento esistente BackendConfig.BACKENDCONFIG_REFERENCE_B
: il nome di un elemento esistente BackendConfig.SERVICE_REFERENCE_A
: utilizza il valore diPORT_NUMBER_1
oPORT_NAME_1
. Questo perché l'annotazione BackendConfig di un servizio può fare riferimento a il nome della porta (spec.ports[].name
) o il numero della porta (spec.ports[].port
).SERVICE_REFERENCE_B
: utilizza il valore diPORT_NUMBER_2
oPORT_NAME_2
. Questo perché l'annotazione BackendConfig di un servizio può fare riferimento a il nome della porta (spec.ports[].name
) o il 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 caricamento nativo del container del cloud, Il bilanciatore del carico invia il traffico a un endpoint in un gruppo di endpoint di rete. (corrispondente a un indirizzo IP di pod) sulla porta del servizio di riferimento
targetPort
(che deve corrispondere a uncontainerPort
per un pod di pubblicazione). Altrimenti, il carico Il bilanciatore invia il traffico all'indirizzo IP di un nodo sulla porta del servizio di 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 maggiori dettagli sui numeri di porta per per i controlli di integrità, consulta Configurazione del controllo di integrità personalizzato.
Configurazione di funzionalità Ingress tramite i parametri FrontendConfig
La seguente sezione mostra come impostare FrontendConfig per attivare specifici 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
crea un criterio SSL
all'esterno di GKE. Una volta creato, puoi farvi riferimento in un
CRD FrontendConfig
.
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 una risorsa Ingress con i reindirizzamenti da HTTP a HTTPS abilitati, vengono creati entrambi i bilanciatori del carico automaticamente. Richieste all'indirizzo IP esterno della porta Ingress sulla porta 80 vengono reindirizzati 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 una risorsa Ingress traffico sia HTTP che HTTPS. Se HTTP o HTTPS è disabilitato, il reindirizzamento non funzioneranno.
I reindirizzamenti da HTTP a HTTPS vengono configurati utilizzando il campo redirectToHttps
in una
FrontendConfig
risorsa personalizzata. I reindirizzamenti sono abilitati per l'intero traffico in entrata
in modo che tutti i servizi a cui fa riferimento l'oggetto Ingress abbiano reindirizzamenti HTTPS
in un bucket con il controllo
delle versioni attivo.
Il seguente manifest FrontendConfig
abilita i reindirizzamenti da HTTP a HTTPS. Imposta il parametro
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 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 Ingress.
La risposta mostra il codice di risposta di reindirizzamento che hai configurato. Ad esempio:
l'esempio seguente si riferisce a un FrontendConfig
configurato con un
Reindirizzamento 301: MovedPermanently
:
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>
Configurazione delle funzionalità Ingress mediante i parametri BackendConfig
Le seguenti sezioni mostrano come impostare BackendConfig per abilitare funzionalità specifiche di Ingress. 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 abilitare Cloud CDN utilizzando una BackendConfig.
Il seguente manifest BackendConfig mostra tutti i campi disponibili quando abilitando 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 questa opzione. Backend in entrata.INCLUDE_HOST
: se impostato sutrue
, le richieste a host diversi vengono memorizzati nella cache separatamente.INCLUDE_PROTOCOL
: se impostato sutrue
, le richieste HTTP e HTTPS vengono memorizzati nella cache separatamente.INCLUDE_QUERY_STRING
: se impostato sutrue
, i parametri della stringa di query sono inclusi nella chiave cache in base aqueryStringBlacklist
oqueryStringWhitelist
. Se nessuno dei due valori è impostato, viene inclusa l'intera stringa di query. Se il criterio viene impostato sufalse
, l'intera stringa di query viene esclusa dalla chiave cache.QUERY_STRING_DENYLIST
: specifica un array di stringhe con i nomi della query parametri stringa 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 della query i parametri di stringa da includere nelle chiavi cache. Tutti gli altri parametri sono esclusi. PuoiqueryStringBlacklist
oqueryStringWhitelist
, ma non entrambe.
I seguenti campi sono supportati solo nelle versioni GKE 1.23.3-gke.900 e versioni successive con GKE Ingress. Non supportata mediante Ingress multi-cluster:
CACHE_MODE
: il modalità cache.CLIENT_TTL
,DEFAULT_TTL
, eMAX_TTL
: configurazione TTL. Per ulteriori informazioni, consulta la sezione Utilizzare le impostazioni e gli override TTL.NEGATIVE_CACHING
: se impostato sutrue
, memorizzazione nella cache negativa sia abilitato. Per ulteriori informazioni, vedi Utilizzo della memorizzazione nella cache negativa.NEGATIVE_CACHING_CODE
eNEGATIVE_CACHING_TTL
: configurazione della memorizzazione nella cache negativa. Per ulteriori informazioni, vedi Utilizzo della memorizzazione nella cache negativa.REQ_COALESCING
: se è impostata sutrue
, la compressione è in un bucket con il controllo delle versioni attivo. Per ulteriori informazioni, vedi Richiedi compressione (coalescing).SERVE_WHILE_STALE
: tempo, in secondi, dopo il è scaduta perché Cloud CDN continua a gestire una versione obsoleta. Per ulteriori informazioni, vedi Pubblicazione di contenuti obsoleti.SIGNED_MAX_AGE
: il tempo massimo per cui le risposte possono essere memorizzate nella cache. in pochi secondi. Per ulteriori informazioni, vedi Facoltativamente, personalizza il tempo massimo della cache.KEY_NAME
,KEY_VALUE
eSECRET_NAME
: configurazione della chiave URL firmata. Per ulteriori informazioni, vedi Creazione di chiavi di richiesta firmate.
Espandi la sezione seguente per vedere un esempio di deployment di Cloud CDN tramite Ingress e verifica che i contenuti dell'applicazione siano memorizzati nella cache.
Timeout per svuotamento della connessione
Puoi configurare timeout per svuotamento della connessione utilizzando una struttura BackendConfig. Il timeout per lo svuotamento della connessione è di attesa, in secondi, per lo svuotamento delle connessioni. Per la durata specificata del timeout, alle richieste esistenti al backend rimosso viene concesso il tempo completato. 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, il che disabilita anche lo svuotamento della connessione.
Il seguente manifest BackendConfig specifica uno svuotamento della connessione di 60 secondi:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
connectionDraining:
drainingTimeoutSec: 60
Configurazione del controllo di integrità personalizzato
GKE configura diversi modi Controlli di integrità dei bilanciatori 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.
BackendConfig ti consente di controllare con precisione il controllo di integrità del bilanciatore del carico impostazioni.
Puoi configurare più servizi GKE per fare riferimento allo stesso
BackendConfig come modello riutilizzabile. Per i parametri healthCheck
, viene restituito un valore
Viene creato il controllo di integrità di Google Cloud per ogni servizio di backend
corrispondenti a ogni servizio GKE.
Il seguente manifest BackendConfig mostra tutti i campi disponibili quando configurando 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 il parametrocheck-interval
in secondi, per ogni prober del controllo di integrità. Si tratta del tempo dall'inizio il controllo di un prober all'inizio del successivo controllo. Se ometti questo parametro, viene utilizzato il valore predefinito di Google Cloud di 5 secondi. 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 diTIMEOUT
deve essere inferiore a o uguale aINTERVAL
. Le unità sono in secondi. Ogni probe richiede Codice di rispostaHTTP 200 (OK)
da consegnare prima del timeout del probe.HEALTH_THRESHOLD
eUNHEALTHY_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 salutare a uno non integro o viceversa. Se ometti uno di questi parametri, Google Cloud utilizza il valore predefinito 2.PROTOCOL
: specifica un valore protocollo usati dai sistemi di probe per il controllo di integrità.BackendConfig
supporta solo creando controlli di integrità utilizzando i protocolli HTTP, HTTPS o HTTP2. Per ulteriori 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, specificarequest-path
a cui deve connettersi il sistema di sonda. 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 predefinito80
.Quando utilizzi il caricamento nativo del container del cloud, devi selezionare una porta corrispondente a
containerPort
di un pod di gestione (a prescindere dal fatto checontainerPort
faccia riferimento o meno atargetPort
di al Servizio). Poiché il bilanciatore del carico invia probe all'IP del pod, direttamente un indirizzo, non sei limitato acontainerPort
a cui fa riferimento untargetPort
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 di gruppi di istanze, devi selezionare una porta corrispondente a un
nodePort
esposte dal Servizio. I sistemi di probe del controllo di integrità si connettono 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
Guida ai criteri di sicurezza di Google Cloud Armor per proteggere le applicazioni con bilanciamento del carico dagli attacchi basati sul web. Dopo aver ottenuto configurato un criterio di sicurezza di Google Cloud Armor, puoi farvi riferimento utilizzando una struttura BackendConfig.
Aggiungi il nome del criterio di sicurezza a BackendConfig. Le seguenti
Il 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 sia configurato tramite GKE, l'infrastruttura
Le API BackendService
di Compute Engine possono essere ancora utilizzate per modificare direttamente
quale criterio di sicurezza applicare. Questo crea due fonti di dati:
GKE e Compute Engine. Ingress GKE
Comportamento del titolare in risposta al campo securityPolicy
in
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 GKE Ingress utilizza la configurazione impostata nella 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 Ingresso abilitato per Google Cloud Armor.
Logging degli accessi HTTP
Ingress può registrare tutte le richieste HTTP dai client 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
logging
è stato omesso e il logging degli accessi utilizza il comportamento predefinito. Questo è
dipende dalla versione di GKE.
Puoi configurare i seguenti campi:
enable
: se impostato sutrue
, il logging degli accessi verrà abilitato per questo Ingress e sono disponibili in Cloud Logging. Altrimenti, il logging degli accessi disabilitata 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 seenable
impostata sutrue
.sampleRate
è un campo facoltativo, ma se configurato, ancheenable: true
deve essere impostato, altrimenti viene interpretato comeenable: false
.
Il seguente manifest BackendConfig abilita 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
Identity-Aware Proxy IAP
devi specificare i valori enabled
e secretName
per il blocco iap
in BackendConfig. Per specificare questi valori, assicurati di avere
Autorizzazione compute.backendServices.update
.
Il seguente manifest BackendConfig abilita Identity-Aware Proxy:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
iap:
enabled: true
oauthclientCredentials:
secretName: my-secret
Abilita IAP con il client OAuth gestito da Google
A partire da GKE 1.29.4-gke.1043000, IAP può essere configurate per l'utilizzo del client OAuth gestito da Google tramite BackendConfig. Per decidere se utilizzare il client OAuth di Google o un client OAuth personalizzato, vedi 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 con OAuthCredentials non esiste un percorso di migrazione a cui passare utilizzando un client OAuth gestito da Google, devi ricreare il backend (rimuovere servizio dalla risorsa Ingress e ricollegalo). Ti consigliamo di eseguire questa operazione durante un periodo di manutenzione, poiché ciò causerà tempi di inattività. 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.
Identity-Aware Proxy con Ingress interno
Per configurare il traffico interno in entrata per IAP, devi utilizzare il metodo 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 BackendConfig per impostare affinità sessione all'IP del client o al cookie generato.
Affinità IP client
Per utilizzare BackendConfig per impostare
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 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 manifest seguente imposta il tipo di affinità sul cookie generato e fornisce al parametro cookie per 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 che inoltra dai backend.
Il bilanciatore del carico aggiunge intestazioni delle richieste personalizzate solo alle richieste del client, non ai probe del controllo di integrità. Se il backend richiede un'intestazione specifica dell'autorizzazione mancante dal pacchetto di 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
come stringa header-name:header-value
.
Le intestazioni delle risposte personalizzate sono disponibili solo in GKE di cluster alla versione 1.25 e 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 una risorsa Ingress, completa i seguenti passaggi attività:
- Creare un deployment.
- Crea una BackendConfig.
- Crea un servizio e associa una delle sue porte a BackendConfig.
- Crea una risorsa Ingress e associala alla coppia (servizio, porta).
- Convalida le proprietà del servizio di backend.
- Esegui la pulizia.
Creazione di un deployment
Prima di creare una configurazione BackendConfig e un servizio, devi creare un'istanza 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 una BackendConfig
Utilizza il tuo BackendConfig per specificare le funzionalità Ingress che vuoi usare.
Il manifest BackendConfig, denominato my-backendconfig.yaml
, specifica:
- Un timeout di 40 secondi.
- Un timeout per svuotamento della connessione di 60 secondi.
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
timeoutSec: 40
connectionDraining:
drainingTimeoutSec: 60
Crea BackendConfig eseguendo questo comando:
kubectl apply -f my-backendconfig.yaml
Crea un Service
Un BackendConfig corrisponde a una singola combinazione Service-Port, anche se un Il servizio ha più porte. Ogni porta può essere associata a un CRD BackendConfig. Se una porta di servizio fa riferimento a una porta Ingress e se La porta del servizio è associata a BackendConfig, quindi al bilanciamento del carico HTTP(S) servizio di backend 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 BackendConfig. Tra 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
.cloud.google.com/backend-config
specifica questo aspetto. - Le richieste inviate alla porta 80 del servizio vengono inoltrate a uno dei 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
In questo esempio, le richieste in entrata vengono instradate alla porta 80 del servizio denominato
my-service
.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: my-service
port:
number: 80
Per creare la risorsa Ingress, esegui questo comando:
kubectl apply -f my-ingress.yaml
Attendi qualche minuto affinché il controller Ingress configuri un bilanciatore del carico delle applicazioni esterno e un servizio di backend associato. 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 siano state applicate le impostazioni corrette del bilanciatore del carico tramite BackendConfig. A questo scopo, identifica servizio di backend di cui è stato eseguito il deployment di Ingress e controllarne le impostazioni per verificare che corrispondano ai manifest del deployment.
Innanzitutto, descrivi la risorsa my-ingress
e filtra per l'annotazione che
elenca i servizi di backend associati 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 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.
Quindi, ispeziona il servizio di backend associato a my-service
utilizzando gcloud
.
Filtra per "drainingTimeoutSec"
e "timeoutSec"
per verificare che abbiano
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
siano state impostate correttamente tramite
BackendConfig.
esegui la pulizia
Per evitare addebiti indesiderati sul tuo account, elimina il cluster Kubernetes creati per questo esercizio:
kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment
Limitazioni di BackendConfig
Le configurazioni BackendConfig presentano le seguenti limitazioni:
- Solo una coppia (servizio, porta) può utilizzare una sola coppia BackendConfig, anche se più Gli oggetti in entrata fanno riferimento a (servizio, porta). Ciò significa che tutti gli oggetti Ingress che fanno riferimento allo stesso (servizio, porta) devono utilizzare la stessa configurazione per Google Cloud Armor, IAP e Cloud CDN.
- Impossibile abilitare IAP e Cloud CDN per gli stessi HTTP(S) Servizio di backend di bilanciamento del carico. Ciò significa che non puoi configurare IAP e Cloud CDN nello stesso BackendConfig.
- Devi utilizzare
kubectl
1.7 o versioni successive per interagire con BackendConfig.
Rimozione della configurazione specificata in FrontendConfig o BackendConfig
Per revocare una funzionalità Ingress, devi disabilitarla esplicitamente in modo esplicito 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 BackendConfig disabilita una 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:
Rimuovi il nome di FrontendConfig dal Annotazione
networking.gke.io/v1beta1.FrontendConfig
in Ingress del file manifest.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 BackendConfig dal
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 utilizzando Strumento di diagnostica di Ingress. Devi inoltre assicurarti Eventuali 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 questo comando:
kubectl get event
L'output di esempio seguente indica che BackendConfig non è stato trovato:
KIND ... SOURCE
Ingress ... loadbalancer-controller
MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists
Per risolvere 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 la creazione dell'oggetto Ingress, se il criterio di sicurezza non è correttamente associato al servizio LoadBalancer, valuta l'evento Kubernetes per vedere se c'è 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 questo comando:
kubectl get event
L'output di esempio seguente indica che il criterio di sicurezza non è stato trovato:
KIND ... SOURCE
Ingress ... loadbalancer-controller
MESSAGE
Error during sync: The given security policy "my-policy" does not exist.
Per risolvere il problema, specifica il nome del criterio di sicurezza corretto nel BackendConfig.
Gestione degli errori della serie 500 con i NEG durante la scalabilità dei carichi di lavoro in GKE
Sintomo:
Quando utilizzi i NEG di cui è stato eseguito il provisioning di GKE per il bilanciamento del carico, potresti rilevare errori 502 o 503 per i servizi durante lo fare lo scale down del carico di lavoro. 502 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 il carico gestito da GKE bilanciamento di prodotti che utilizzano NEG, inclusi gateway, Ingress e NEG autonomi. Se scala frequentemente i carichi di lavoro, il rischio di impatto sul cluster è maggiore.
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
la risoluzione, devi considerare l'ordine delle operazioni. Le seguenti immagini
scenari in cui vengono mostrati quando BackendService Drain Timeout
non è impostato e
BackendService Drain Timeout
è impostato su BackendConfig
.
Scenario 1: il criterio BackendService Drain Timeout
non è impostato.
La seguente immagine mostra uno scenario in cui BackendService Drain Timeout
è
non impostato.
Scenario 2: BackendService Drain Timeout
è impostato.
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 è è influenzato da una varietà 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 viene avviato lo svuotamento, il bilanciatore del carico smette di inviare nuove richieste nell'endpoint, ma c'è ancora una latenza nell'attivazione dello svuotamento (Drain latenza) che possono 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 la risoluzione: il periodo di tolleranza in base alla risoluzione determina la il periodo di tempo massimo in cui un pod può uscire. Tuttavia, un pod può uscire prima il periodo di tolleranza per la chiusura è terminato. Se un pod richiede più tempo di questo periodo, forzata l'uscita alla fine 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 il processo di personalizzazione.
La seguente immagine mostra come mantenere attivo il pod con preStopHook
:
Per evitare errori relativi alla serie 500:
Imposta
BackendService Drain Timeout
per il servizio su 1 minuto.Per gli utenti in entrata, vedi Impostare il timeout nella BackendConfig.
Per gli utenti gateway, consulta la sezione su come configurare il timeout sulla 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.
Estendi
terminationGracePeriod
sul pod.Imposta
terminationGracePeriodSeconds
sul pod su 3,5 minuti. Quando combinato con le impostazioni consigliate, consente ai pod di ottenere finestra per un arresto controllato 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 ... ...
Applica un'istruzione
preStopHook
a tutti i container.Applica un
preStopHook
che garantirà che il pod sia attivo per 120 secondi più a lungo mentre l'endpoint del pod viene svuotato nel bilanciatore del carico l'endpoint viene rimosso dal NEG.spec: containers: - name: my-app ... lifecycle: preStopHook: exec: command: ["/bin/sh", "-c", "sleep 120s"] ...
Personalizza timeout
Per garantire la continuità del pod ed evitare errori della serie 500, il pod deve essere attivo
finché l'endpoint non viene rimosso dal NEG. In particolare per evitare errori 502 e 503,
valuta la possibilità di implementare una combinazione di timeout e preStopHook
.
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 prolungare il periodo di tempo durante il quale un pod rimane attivo durante il processo di arresto,
inserisci 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
e 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 il parametro Backend Service Drain Timeout
e attivi
il bilanciatore del carico interrompe l'instradamento di 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. Ciò garantisce che
è entrato poco prima dell'inizio dello svuotamento, l'operazione sarà completata prima
il timeout è completato. 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
non completati riceverà un errore 502.
preStopHook
volta
preStopHook
deve ritardare l'arresto del pod sufficientemente per lo svuotamento
di latenza e lo svuotamento del servizio di backend da completare, assicurando che
drenaggio della connessione e rimozione degli endpoint dal NEG prima dell'arresto del pod
verso il basso.
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 svuotamento 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 la chiusura
Devi configurare il parametro terminationGracePeriod
per consentire un numero sufficiente di
per il completamento di preStopHook
e per il completamento di una
arrestato.
Per impostazione predefinita, se non viene configurato in modo esplicito, il valore di terminationGracePeriod
è di 30 secondi.
Puoi calcolare il valore ottimale di terminationGracePeriod
utilizzando la formula:
terminationGracePeriod >= preStopHook Time + Pod shutdown time
Per definire terminationGracePeriod
all'interno della configurazione del pod come segue:
spec:
terminationGracePeriodSeconds: <terminationGracePeriod>
containers:
- name: my-app
...
...
NEG non trovato durante la creazione di una risorsa Ingress interna
Quando crei una risorsa Ingress interna in un'istanza, potrebbe verificarsi il seguente errore GKE:
Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound
Questo errore si verifica perché il traffico in entrata per i bilanciatori del carico delle applicazioni interni richiede gruppi di endpoint di rete (NEG) come backend.
In ambienti o cluster VPC condivisi in cui sono abilitati i criteri di rete,
aggiungi l'annotazione cloud.google.com/neg: '{"ingress": true}'
al servizio
del file manifest.
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 eseguito tramite proxy da proxy Envoy nella configurazione proxy un intervallo di subnet.
Per consentire il traffico dall'intervallo di subnet solo proxy,
crea una regola firewall
in targetPort
del Servizio.
Errore 400: valore non valido per il campo "resource.target"
Potrebbe verificarsi il seguente errore quando accedi a un servizio da 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 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 controllo GKE gli upgrade dei piani 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 l'oggetto Ingress. Attendi cinque minuti per consentire a GKE di eliminare risorse Ingress inutilizzate. Quindi, ricrea la risorsa Ingress. Per ulteriori informazioni, vedi Il campo hosts di un oggetto Ingress. - Ripristina le modifiche apportate a Ingress. Quindi, aggiungi un certificato utilizzando un o secret Kubernetes.
Problemi noti
Impossibile abilitare i reindirizzamenti HTTPS con lo schema di denominazione Ingress V1
Non puoi abilitare i reindirizzamenti HTTPS sulle risorse GKE Ingress creato su GKE versioni 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.
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'v1beta1
L'API rimuove un criterio di sicurezza Google Cloud Armor attivo dal proprio 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, ti consigliamo vivamente di aggiornare solo le risorse BackendConfig utilizzando
API v1
. Applicazione di una BackendConfig al cluster utilizzando v1beta1
Le risorse BackendConfig rimuoverà il criterio di sicurezza di Google Cloud Armor
dal Servizio a cui fa riferimento.
Per limitare il problema, aggiorna la tua BackendConfig solo utilizzando l'v1
l'API BackendConfig. BackendConfig di v1
supporta gli stessi campi di v1beta1
senza apportare modifiche che provocano un errore, in modo che il campo dell'API possa essere aggiornato in modo trasparente.
Sostituisci il campo apiVersion
di qualsiasi BackendConfig attivo
con cloud.google.com/v1
e non utilizzano cloud.google.com/v1beta1
.
Il seguente manifest di esempio descrive una risorsa BackendConfig che utilizza v1
API:
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 BackendConfig
assicurati di utilizzare il gruppo API cloud.google.com/v1
in
questi sistemi.
Se BackendConfig è già stato aggiornato con l'API v1beta1
,
il criterio di sicurezza di Google Cloud Armor potrebbe essere stato rimosso.
Per determinare se ciò si è verificato, puoi eseguire questo comando:
kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'
Se la risposta restituisce un output, il cluster è interessato dal problema.
L'output di questo comando restituisce un elenco di risorse BackendConfig
(<namespace>/<name>
) interessati 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 dovrebbero solo
usa 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 della risorsa BackendConfig che utilizza l'API v1
.
Esegui l'upgrade del piano di controllo GKE
a una delle seguenti versioni aggiornate che correggeranno il problema
v1beta1
Risorse BackendConfig da usare 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