Risolvi i problemi di bilanciamento del carico in GKE

Questa pagina mostra come risolvere i problemi relativi al bilanciamento del carico in Cluster Google Kubernetes Engine (GKE) che utilizzano Service, Ingress o Gateway Google Cloud.

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.

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.

Il timeout dello svuotamento di BackendService non è impostato

Scenario 2: BackendService Drain Timeout è impostato.

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

Il timeout dello svuotamento di BackendService è impostato

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:

Il timeout dello svuotamento di BackendService è impostato

Per evitare errori relativi alla serie 500:

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

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

  3. 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 sezione tls 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.

Una risorsa Ingress esterna produce errori HTTP 502

Utilizza le seguenti indicazioni per risolvere i problemi relativi agli errori HTTP 502 con indirizzi Risorse in entrata:

  1. Abilita i log per ciascun servizio di backend associato a ciascun servizio GKE. a cui fa riferimento l'oggetto Ingress.
  2. Utilizza le funzionalità di dettagli sullo stato per identificare le cause delle risposte HTTP 502. I dettagli di stato che indicano La risposta HTTP 502 proveniente dal backend richiede la risoluzione dei problemi all'interno ai pod di gestione, non al bilanciatore del carico.

Gruppi di istanze non gestite

Potresti riscontrare errori HTTP 502 con risorse Ingress esterne se le tue La risorsa Ingress esterno utilizza backend di gruppi di istanze non gestite. Questo problema si verifica quando sono soddisfatte tutte le seguenti condizioni:

  • Il cluster ha un numero totale di nodi elevato tra tutti i pool di nodi.
  • I pod di gestione per uno o più servizi a cui fa riferimento l'oggetto Ingress si trovano solo su pochi nodi.
  • I servizi a cui fa riferimento l'oggetto Ingress utilizzano externalTrafficPolicy: Local.

Per determinare se la tua risorsa Ingress esterna utilizza backend di gruppi di istanze non gestite: procedi nel seguente modo:

  1. Vai alla pagina Ingress nella console Google Cloud.

    Vai a Ingress

  2. Fai clic sul nome della risorsa Ingress esterna.

  3. Fai clic sul nome del bilanciatore del carico. La sezione Dettagli del bilanciamento del carico vengono visualizzate nella pagina di destinazione.

  4. Controlla la tabella nella sezione Servizi di backend per determinare se le tue l'in entrata esterna utilizza NEG o gruppi di istanze.

Per risolvere il problema, utilizza una delle seguenti soluzioni:

  • Utilizza un cluster nativo di VPC.
  • Utilizza externalTrafficPolicy: Cluster per ogni servizio a cui fa riferimento un'istanza in entrata esterna. Questa soluzione ti fa perdere l'IP client originale nelle origini del pacchetto.
  • Usa node.kubernetes.io/exclude-from-external-load-balancers=true annotazione. Aggiungi l'annotazione ai nodi o ai pool di nodi che non eseguono di gestione dei pod per qualsiasi servizio a cui viene fatto riferimento da un qualsiasi elemento Ingress esterno LoadBalancer servizio nel tuo cluster.

Utilizzare i log del bilanciatore del carico per risolvere i problemi

Puoi utilizzare Log del bilanciatore del carico di rete passthrough interno e log del bilanciatore del carico di rete passthrough esterno per risolvere i problemi relativi ai bilanciatori del carico e correlare il traffico proveniente bilanciatori alle risorse GKE.

I log vengono aggregati per connessione ed esportati quasi in tempo reale. I log sono generate per ciascun nodo GKE coinvolto nel percorso dei dati di un Servizio LoadBalancer, sia per il traffico in entrata che per quello in uscita. Le voci di log includono campi aggiuntivi per le risorse GKE, ad esempio: - Nome cluster - Località del cluster - Nome servizio - Spazio dei nomi servizio - Nome pod - Spazio dei nomi pod

Prezzi

Non sono previsti costi aggiuntivi per l'utilizzo dei log. In base a come importi i log, sui prezzi standard per Cloud Logging BigQuery o Pub/Sub. L'abilitazione dei log non ha alcun effetto sulla delle prestazioni del bilanciatore del carico.

Utilizzare gli strumenti di diagnostica per risolvere i problemi

Lo strumento di diagnostica check-gke-ingress controlla le risorse Ingress per trovare configurazioni errate. Puoi utilizzare lo strumento check-gke-ingress nelle seguenti modi:

  • Esegui l' Strumento a riga di comando gcpdiag sul tuo cluster. I risultati in entrata vengono visualizzati nella regola di controllo gke/ERR/2023_004 .
  • Usa lo strumento check-gke-ingress da solo o come plug-in kubectl seguendo le istruzioni riportate le istruzioni in check-gke-ingress.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.