Risolvere i problemi di GKE Ingress

I problemi con Ingress in Google Kubernetes Engine (GKE) possono impedire al traffico esterno o interno di raggiungere i tuoi servizi.

Utilizza questo documento per trovare soluzioni agli errori relativi alla classe Ingress, alle annotazioni IP statici, alle dimensioni delle chiavi dei certificati e alle interazioni con i livelli di rete.

Queste informazioni sono destinate agli amministratori e agli operatori della piattaforma e agli sviluppatori di applicazioni che eseguono il deployment e gestiscono le applicazioni esposte utilizzando Ingress in GKE. Per maggiori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE.

Annotazione errata per la classe Ingress

Sintomo

Quando crei un Ingress, potresti visualizzare il seguente errore:

Missing one or more resources. If resource creation takes longer than expected, you might have an invalid configuration.

Possibili cause

Quando crei Ingress, potresti aver configurato in modo errato la classe Ingress nel manifest.

Risoluzione

Per specificare una classe Ingress, devi utilizzare l'annotazione kubernetes.io/ingress.class. Non puoi specificare un GKE Ingress utilizzando spec.ingressClassName.

  • Per eseguire il deployment di un bilanciatore del carico delle applicazioni interno, utilizza l'annotazione kubernetes.io/ingress.class: gce-internal.
  • Per eseguire il deployment di un bilanciatore del carico delle applicazioni esterno, utilizza l'annotazione kubernetes.io/ingress.class: gce.

Annotazione errata per l'indirizzo IP statico

Sintomo

Quando configuri un Ingress esterno per utilizzare un indirizzo IP statico, potresti visualizzare il seguente errore:

Error syncing to GCP: error running load balancer syncing routine: loadbalancer <Name of load balancer> does not exist: the given static IP name <Static IP> doesn't translate to an existing static IP.

Possibili cause

  • Non hai creato un indirizzo IP esterno statico prima di eseguire il deployment di Ingress.
  • Non stai utilizzando l'annotazione corretta per il tuo tipo di bilanciatore del carico.

Risoluzione

Se stai configurando un Ingress esterno:

Se stai configurando un Ingress interno:

  • Prenota un indirizzo IP interno statico regionale prima di eseguire il deployment dell'ingresso.
  • Utilizza l'annotazione kubernetes.io/ingress.regional-static-ip-name nella risorsa Ingress.

L'indirizzo IP statico è già in uso

Sintomo

Potresti visualizzare il seguente errore quando specifichi un indirizzo IP statico per il provisioning della risorsa Ingress interna o esterna:

Error syncing to GCP: error running load balancer syncing
routine: loadbalancer <LB name> does not exist:
googleapi: Error 409: IP_IN_USE_BY_ANOTHER_RESOURCE - IP ''<IP address>'' is already being used by another resource.

Possibili cause

L'indirizzo IP statico è già utilizzato da un'altra risorsa.

Errore durante la disattivazione di HTTP e l'utilizzo di un certificato gestito da Google

Sintomo

Se stai configurando un certificato SSL gestito da Google e disattivando il traffico HTTP sul tuo Ingress, viene visualizzato il seguente errore:

Error syncing to GCP: error running load balancer syncing
routine: loadbalancer <Load Balancer name> does not exist:
googleapi: Error 404: The resource ''projects/<Project>/global/sslPolicies/<Policy name>' was not found, notFound

Possibili cause

Non puoi utilizzare le seguenti annotazioni insieme quando configuri l'ingresso:

  • networking.gke.io/managed-certificates (per associare il certificato gestito da Google a un Ingress)
  • kubernetes.io/ingress.allow-http: false (per disattivare il traffico HTTP)

Risoluzione

Disattiva il traffico HTTP solo dopo che il bilanciatore del carico delle applicazioni esterno è stato completamente programmato. Puoi aggiornare l'ingresso e aggiungere l'annotazione kubernetes.io/ingress.allow-http: false al manifest.

Manca la subnet solo proxy per un Ingress interno

Sintomo

Quando esegui il deployment di un Ingress per un bilanciatore del carico delle applicazioni interno, potresti visualizzare il seguente errore:

Error syncing to GCP: error running load balancer syncing routine:
loadbalancer <LB name> does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/<Project ID>/regions/<Region>/targetHttpsProxies/<Target proxy>'.
An active proxy-only subnetwork is required in the same region and VPC as
the forwarding rule.

Possibili cause

Non hai creato una subnet solo proxy prima di creare la risorsa Ingress. Per i bilanciatori del carico delle applicazioni interni è necessaria una subnet solo proxy.

Risoluzione

Crea una subnet solo proxy prima di eseguire il deployment dell'ingresso interno.

La chiave del certificato SSL è troppo grande

Sintomo

Se la dimensione della chiave del certificato SSL del bilanciatore del carico è troppo grande, potresti visualizzare il seguente errore:

Error syncing to GCP: error running load balancer syncing routine: loadbalancer gky76k70-load-test-trillian-api-ingress-fliismmb does not exist: Cert creation failures - k8s2-cr-gky76k70-znz6o1pfu3tfrguy-f9be3a4abbe573f7 Error:googleapi: Error 400: The SSL key is too large., sslCertificateKeyTooLarge

Possibili cause

Google Cloud ha un limite di 2048 bit per le chiavi del certificato SSL.

Risoluzione

Riduci le dimensioni della chiave del certificato SSL a 2048 bit o meno.

Errore durante la creazione di una risorsa Ingress nel livello Standard

Sintomo

Se stai eseguendo il deployment di un Ingress in un progetto con il livello di rete predefinito del progetto impostato su Standard, viene visualizzato il seguente messaggio di errore:

Error syncing to GCP: error running load balancer syncing routine: load balancer <LB Name> does not exist: googleapi: Error 400: STANDARD network tier (the project''s default network tier) is not supported: STANDARD network tier is not supported for global forwarding rule., badRequest

Risoluzione

Configura il livello di rete predefinito del progetto su Premium.

Errore "Non trovato" previsto per k8s-ingress-svc-acct-permission-check-probe

Il controller Ingress esegue controlli periodici delle autorizzazioni del account di servizio recuperando una risorsa di test dal tuo progetto Google Cloud . Vedrai questo come un GET del BackendService globale (inesistente) con il nome k8s-ingress-svc-acct-permission-check-probe. Poiché questa risorsa normalmente non dovrebbe esistere, la richiesta GET restituirà "non trovata". Questo comportamento è previsto; il controller verifica che la chiamata API non venga rifiutata a causa di problemi di autorizzazione. Se crei un BackendService con lo stesso nome, GET avrà esito positivo anziché restituire "non trovato".

Errori durante l'utilizzo del bilanciamento del carico nativo del container

Utilizza le seguenti tecniche per verificare la configurazione di rete. Le sezioni seguenti spiegano come risolvere problemi specifici relativi al bilanciamento del carico nativo dei container.

  • Consulta la documentazione sul bilanciamento del carico per scoprire come elencare i gruppi di endpoint di rete.

  • Puoi trovare il nome e le zone del NEG corrispondente a un servizio nell'annotazione neg-status del servizio. Recupera la specifica del servizio con:

    kubectl get svc SVC_NAME -o yaml

    L'annotazione metadata:annotations:cloud.google.com/neg-status elenca il nome del NEG corrispondente del servizio e le zone del NEG.

  • Puoi controllare l'integrità del servizio di backend corrispondente a un NEG con il seguente comando:

    gcloud compute backend-services --project PROJECT_NAME \
    get-health BACKEND_SERVICE_NAME --global

    Il servizio di backend ha lo stesso nome del NEG.

  • Per stampare i log eventi di un servizio:

    kubectl describe svc SERVICE_NAME

    La stringa del nome del servizio include il nome e lo spazio dei nomi del servizio GKE corrispondente.

Impossibile creare un cluster con IP alias

Sintomi

Quando provi a creare un cluster con IP alias, potresti riscontrare il seguente errore:

ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
Possibili cause

Si verifica questo errore se tenti di creare un cluster con IP alias che utilizza anche una rete legacy.

Risoluzione

Assicurati di non creare un cluster con IP alias e una rete legacy abilitati contemporaneamente. Per ulteriori informazioni sull'utilizzo degli IP alias, consulta Crea un cluster nativo di VPC.

Il traffico non raggiunge gli endpoint

Sintomi
Errori 502/503 o connessioni rifiutate.
Possibili cause

I nuovi endpoint diventano generalmente raggiungibili dopo essere stati collegati al bilanciatore del carico, a condizione che rispondano ai controlli di integrità. Potresti riscontrare errori 502 o connessioni rifiutate se il traffico non riesce a raggiungere gli endpoint.

Gli errori 502 e le connessioni rifiutate possono anche essere causati da un container che non gestisce SIGTERM. Se un container non gestisce esplicitamente SIGTERM, termina immediatamente e smette di gestire le richieste. Il bilanciatore del carico continua a inviare il traffico in entrata al container terminato, causando errori.

Il bilanciatore del carico nativo del container ha un solo endpoint di backend. Durante un aggiornamento progressivo, il vecchio endpoint viene deprogrammato prima che venga programmato il nuovo endpoint.

I pod di backend vengono sottoposti a deployment in una nuova zona per la prima volta dopo il provisioning di un bilanciatore del carico nativo per i container. L'infrastruttura del bilanciatore del carico viene programmata in una zona quando è presente almeno un endpoint nella zona. Quando viene aggiunto un nuovo endpoint a una zona, l'infrastruttura del bilanciatore del carico viene programmata e causa interruzioni del servizio.

Risoluzione

Configura i container per gestire SIGTERM e continuare a rispondere alle richieste durante il periodo di tolleranza per la terminazione (30 secondi per impostazione predefinita). Configura i pod in modo che inizino a non superare i controlli di integrità quando ricevono SIGTERM. Questo indica al bilanciatore del carico di interrompere l'invio di traffico al pod mentre è in corso la riprogrammazione dell'endpoint.

Se la tua applicazione non si arresta normalmente e smette di rispondere alle richieste quando riceve un SIGTERM, l'hook preStop può essere utilizzato per gestire SIGTERM e continuare a gestire il traffico mentre è in corso la deprogrammazione dell'endpoint.

lifecycle:
  preStop:
    exec:
      # if SIGTERM triggers a quick exit; keep serving traffic instead
      command: ["sleep","60"]

Consulta la documentazione sulla terminazione dei pod.

Se il backend del bilanciatore del carico ha una sola istanza, configura la strategia di rollout per evitare di eliminare l'unica istanza prima che la nuova istanza sia completamente programmata. Per i pod delle applicazioni gestiti dal workload Deployment, questo può essere ottenuto configurando la strategia con il parametro maxUnavailable uguale a 0.

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Per risolvere i problemi relativi al traffico che non raggiunge gli endpoint, verifica che le regole firewall consentano il traffico TCP in entrata verso gli endpoint negli intervalli 130.211.0.0/22 e 35.191.0.0/16. Per saperne di più, consulta la sezione Aggiunta di controlli di integrità nella documentazione di Cloud Load Balancing.

Visualizza i servizi di backend nel tuo progetto. La stringa del nome del servizio di backend pertinente include il nome e lo spazio dei nomi del servizio GKE corrispondente:

gcloud compute backend-services list

Recupera lo stato di integrità del backend dal servizio di backend:

gcloud compute backend-services get-health BACKEND_SERVICE_NAME

Se tutti i backend non sono integri, il firewall, Ingress o il servizio potrebbero essere configurati in modo errato.

Se alcuni backend non sono integri per un breve periodo di tempo, la latenza della programmazione di rete potrebbe essere la causa.

Se alcuni backend non vengono visualizzati nell'elenco dei servizi di backend, la causa potrebbe essere la latenza di programmazione. Puoi verificarlo eseguendo questo comando, dove NEG_NAME è il nome del servizio di backend. (I NEG e i servizi di backend condividono lo stesso nome):

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Controlla se tutti gli endpoint previsti si trovano nel NEG.

Se hai selezionato un numero ridotto di backend (ad esempio, 1 pod) da un bilanciatore del carico nativo dei container, valuta la possibilità di aumentare il numero di repliche e distribuire i pod di backend in tutte le zone in cui si estende il cluster GKE. In questo modo, l'infrastruttura del bilanciatore del carico sottostante viene programmata completamente. In caso contrario, valuta la possibilità di limitare i pod di backend a una singola zona.

Se configuri una policy di rete per l'endpoint, assicurati che l'ingresso dalla subnet solo proxy sia consentito.

Implementazione bloccata

Sintomi
Il lancio di un deployment aggiornato si blocca e il numero di repliche aggiornate non corrisponde al numero di repliche scelto.
Possibili cause

I controlli di integrità del deployment non riescono. L'immagine container potrebbe essere danneggiata o il controllo di integrità potrebbe essere configurato in modo errato. La sostituzione in sequenza dei pod attende che il pod appena avviato superi il controllo di idoneità del pod. Ciò si verifica solo se il pod risponde ai controlli di integrità del bilanciatore del carico. Se il pod non risponde o se il controllo di integrità è configurato in modo errato, le condizioni del gate di preparazione non possono essere soddisfatte e l'implementazione non può continuare.

Se utilizzi kubectl 1.13 o versioni successive, puoi controllare lo stato dei readiness gate di un pod con il seguente comando:

kubectl get pod POD_NAME -o wide

Controlla la colonna READINESS GATES.

Questa colonna non esiste in kubectl 1.12 e versioni precedenti. Un pod contrassegnato come in stato READY potrebbe non aver superato il gate di idoneità. Per verificarlo, utilizza questo comando:

kubectl get pod POD_NAME -o yaml

I gate di preparazione e il relativo stato sono elencati nell'output.

Risoluzione

Verifica che l'immagine container nella specifica del pod del deployment funzioni correttamente e sia in grado di rispondere ai controlli di integrità. Verifica che i controlli di integrità siano configurati correttamente.

Errori della modalità con funzionalità ridotte

Sintomi

A partire dalla versione 1.29.2-gke.1643000 di GKE, potresti visualizzare i seguenti avvisi sul tuo servizio in Esplora log quando vengono aggiornati i NEG:

Entering degraded mode for NEG <service-namespace>/<service-name>-<neg-name>... due to sync err: endpoint has missing nodeName field
Possibili cause

Questi avvisi indicano che GKE ha rilevato errori di configurazione dell'endpoint durante un aggiornamento NEG basato su oggetti EndpointSlice, attivando un processo di calcolo più approfondito chiamato modalità degradata. GKE continua ad aggiornare i NEG nel miglior modo possibile, correggendo la configurazione errata o escludendo gli endpoint non validi dagli aggiornamenti dei NEG.

Alcuni errori comuni sono:

  • endpoint has missing pod/nodeName field
  • endpoint corresponds to an non-existing pod/node
  • endpoint information for attach/detach operation is incorrect
Risoluzione

In genere, questi eventi sono causati da stati transitori e vengono risolti autonomamente. Tuttavia, gli eventi causati da errori di configurazione negli oggetti EndpointSlice personalizzati rimangono irrisolti. Per comprendere la configurazione errata, esamina gli oggetti EndpointSlice corrispondenti al servizio:

kubectl get endpointslice -l kubernetes.io/service-name=<service-name>

Convalida ogni endpoint in base all'errore nell'evento.

Per risolvere il problema, devi modificare manualmente gli oggetti EndpointSlice. L'aggiornamento attiva di nuovo l'aggiornamento dei NEGs. Una volta che la configurazione errata non esiste più, l'output è simile al seguente:

NEG <service-namespace>/<service-name>-<neg-name>... is no longer in degraded mode

Errori durante l'utilizzo di certificati SSL gestiti da Google

Questa sezione fornisce informazioni su come risolvere i problemi relativi ai certificati gestiti da Google.

Controllare gli eventi su ManagedCertificate e le risorse Ingress

Se superi il numero di certificati consentiti, all'ManagedCertificate viene aggiunto un evento con motivo TooManyCertificates. Puoi controllare gli eventi su un oggetto ManagedCertificate utilizzando il seguente comando:

kubectl describe managedcertificate CERTIFICATE_NAME

Sostituisci CERTIFICATE_NAME con il nome del tuo ManagedCertificate.

Se colleghi un ManagedCertificate inesistente a un Ingress, all'Ingress viene aggiunto un evento con un motivo MissingCertificate. Puoi controllare gli eventi su un Ingress utilizzando il seguente comando:

kubectl describe ingress INGRESS_NAME

Sostituisci INGRESS_NAME con il nome del tuo Ingress.

Certificato gestito non sottoposto a provisioning quando il dominio viene risolto in indirizzi IP di più bilanciatori del carico

Quando il tuo dominio viene risolto in indirizzi IP di più bilanciatori del carico (più oggetti Ingress), devi creare un singolo oggetto ManagedCertificate e collegarlo a tutti gli oggetti Ingress. Se invece crei molti oggetti ManagedCertificate e li colleghi a un Ingress separato, l'autorità di certificazione potrebbe non essere in grado di verificare la proprietà del tuo dominio e alcuni dei tuoi certificati potrebbero non essere sottoposti a provisioning. Affinché la verifica vada a buon fine, il certificato deve essere visibile in tutti gli indirizzi IP a cui viene risolto il tuo dominio.

Nello specifico, quando il tuo dominio viene risolto in un indirizzo IPv4 e un indirizzo IPv6 configurati con oggetti Ingress diversi, devi creare un singolo oggetto ManagedCertificate e collegarlo a entrambi gli Ingress.

Interruzione della comunicazione tra i certificati gestiti da Google e Ingress

I certificati gestiti comunicano con Ingress utilizzando l'annotazione ingress.gcp.kubernetes.io/pre-shared-cert. Puoi interrompere questa comunicazione se, ad esempio:

  • Esegui un processo automatizzato che cancella l'annotazione ingress.gcp.kubernetes.io/pre-shared-cert.
  • Archivia uno snapshot di Ingress, quindi elimina e ripristina Ingress dallo snapshot. Nel frattempo, una risorsa SslCertificate elencata nell'annotazione ingress.gcp.kubernetes.io/pre-shared-cert potrebbe essere stata eliminata. L'ingresso non funziona se mancano certificati allegati.

Se la comunicazione tra i certificati gestiti da Google e Ingress viene interrotta, elimina i contenuti dell'annotazione ingress.gcp.kubernetes.io/pre-shared-cert e attendi che il sistema si riconcili. Per evitare che si ripresenti, assicurati che l'annotazione non venga modificata o eliminata inavvertitamente.

Errori di convalida durante la creazione di un certificato gestito da Google

ManagedCertificate vengono convalidate prima della creazione dell'oggetto ManagedCertificate. Se la convalida non va a buon fine, l'oggetto ManagedCertificate non viene creato e viene stampato un messaggio di errore. I diversi messaggi di errore e i motivi sono spiegati di seguito:

spec.domains in body should have at most 100 items

Il file manifest ManagedCertificate elenca più di 100 domini nel campo spec.domains. I certificati gestiti da Google supportano fino a 100 domini.

spec.domains in body should match '^(([a-zA-Z0-9]+|[a-zA-Z0-9][-a-zA-Z0-9]*[a-zA-Z0-9])\.)+[a-zA-Z][-a-zA-Z0-9]*[a-zA-Z0-9]\.?$'

Hai specificato un nome di dominio non valido o un nome di dominio con caratteri jolly nel campo spec.domains. L'oggetto ManagedCertificate non supporta i domini con caratteri jolly (ad esempio *.example.com).

spec.domains in body should be at most 63 chars long

Hai specificato un nome di dominio troppo lungo. I certificati gestiti da Google supportano nomi di dominio con un massimo di 63 caratteri.

Aggiornamento manuale di un certificato gestito da Google

Per aggiornare manualmente il certificato in modo che il certificato per il vecchio dominio continui a funzionare finché non viene eseguito il provisioning del certificato per il nuovo dominio, segui questi passaggi:

  1. Crea un ManagedCertificate per il nuovo dominio.
  2. Aggiungi il nome di ManagedCertificate all'annotazione networking.gke.io/managed-certificates in Ingress utilizzando un elenco separato da virgole. Non rimuovere il nome del vecchio certificato.
  3. Attendi che ManagedCertificate diventi attivo.
  4. Scollega il vecchio certificato dall'ingresso ed eliminalo.

Quando crei un ManagedCertificate, Google Cloud crea un certificato SSL gestito da Google. Non puoi aggiornare questo certificato. Se aggiorni ManagedCertificate, Google Cloud elimina e ricrea il certificato SSL gestito da Google.

Per fornire Ingress criptato HTTPS sicuro per i tuoi cluster GKE, consulta l'esempio Ingress sicuro.

Passaggi successivi