Risolvere i problemi relativi ai controlli di integrità Ingress

Se i controlli di integrità di Ingress in Google Kubernetes Engine (GKE) non vengono superati, il traffico potrebbe non raggiungere l'applicazione, anche se i pod sono in esecuzione.

Leggi questo documento per scoprire come funzionano i controlli di integrità di Ingress, comprendere le considerazioni relative a BackendConfig e ai probe di idoneità e diagnosticare problemi come applicazioni che non rispondono o regole firewall mancanti.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma e per gli sviluppatori di applicazioni che configurano e gestiscono le risorse Ingress e devono assicurarsi che le loro applicazioni segnalino correttamente lo stato di integrità al bilanciatore del carico. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE.

Comprendere il funzionamento dei controlli di integrità di Ingress

Prima di procedere con i passaggi per la risoluzione dei problemi, può essere utile comprendere il funzionamento dei controlli di integrità in GKE e quali considerazioni tenere presenti per garantire che i controlli di integrità vengano superati.

Quando esponi uno o più servizi tramite un Ingress utilizzando il controller Ingress predefinito, GKE crea un bilanciatore del carico delle applicazioni classico o un bilanciatore del carico delle applicazioni interno. Entrambi questi bilanciatori del carico supportano più servizi di backend su una singola mappa URL. Ciascuno dei servizi di backend corrisponde a un servizio Kubernetes e deve fare riferimento a un Google Cloud controllo di integrità. Questo controllo di integrità è diverso da un probe di attività o di idoneità di Kubernetes perché viene implementato al di fuori del cluster.

I controlli di integrità del bilanciatore del carico vengono specificati per servizio di backend. Sebbene sia possibile utilizzare lo stesso controllo di integrità per tutti i servizi di backend del bilanciatore del carico, il riferimento al controllo di integrità non viene specificato per l'intero bilanciatore del carico (nell'oggetto Ingress stesso).

GKE crea i controlli di integrità in base a uno dei seguenti metodi:

  • CRD BackendConfig: una definizione di risorsa personalizzata (CRD) che ti consente di controllare con precisione il modo in cui i tuoi servizi interagiscono con il bilanciatore del carico. Le CRD BackendConfig ti consentono di specificare impostazioni personalizzate per il controllo di integrità associato al servizio di backend corrispondente. Queste impostazioni personalizzate offrono maggiore flessibilità e controllo sui controlli di integrità sia per il bilanciatore del carico delle applicazioni classico sia per il bilanciatore del carico delle applicazioni interno creato da un Ingress.
  • Probe di idoneità: un controllo diagnostico che determina se un container all'interno di un pod è pronto a gestire il traffico. Il controller Ingress di GKE crea il controllo di integrità per il servizio di backend del servizio in base al probe di idoneità utilizzato dai pod di gestione del servizio. Puoi derivare i parametri del controllo di integrità, come percorso, porta e protocollo, dalla definizione del probe di idoneità.
  • Valori predefiniti: i parametri utilizzati quando non configuri una BackendConfig CRD o non definisci gli attributi per il probe di idoneità.
Best practice:

Utilizza una CRD BackendConfig per avere il massimo controllo sulle impostazioni del controllo di integrità del bilanciatore del carico.

GKE utilizza la seguente procedura per creare un controllo di integrità per ogni servizio di backend corrispondente a un servizio Kubernetes:

  • Se il servizio fa riferimento a una BackendConfig CRD con healthCheck informazioni, GKE la utilizza per creare il controllo di integrità. Sia il controller Ingress di GKE Enterprise sia il controller Ingress di GKE supportano la creazione di controlli di integrità in questo modo.

  • Se il servizio non fa riferimento a una CRD BackendConfig:

    • GKE può dedurre alcuni o tutti i parametri per un controllo di integrità se i pod di gestione utilizzano un modello di pod con un container il cui probe di idoneità ha attributi che possono essere interpretati come parametri del controllo di integrità. Consulta la sezione Parametri di un probe di idoneità per i dettagli di implementazione e la sezione Parametri predefiniti e dedotti per un elenco degli attributi che possono essere utilizzati per creare i parametri del controllo di integrità. Solo il controller Ingress di GKE supporta la deduzione dei parametri da un probe di idoneità.

    • Se il modello di pod per i pod di gestione del servizio non ha un container con un probe di idoneità i cui attributi possono essere interpretati come parametri del controllo di integrità, vengono utilizzati i valori predefiniti per creare il controllo di integrità. Sia il controller Ingress di GKE Enterprise sia il controller Ingress di GKE possono creare un controllo di integrità utilizzando solo i valori predefiniti.

Considerazioni

Questa sezione descrive alcune considerazioni da tenere presenti quando configuri una CRD BackendConfig o utilizzi un probe di idoneità.

CRD BackendConfig

Quando configuri le CRD BackendConfig, tieni presente le seguenti considerazioni:

  • Se utilizzi il bilanciamento del carico nativo per i container, assicurati che la porta del controllo di integrità nel manifest BackendConfig corrisponda a containerPort di un pod di gestione.
  • Per i backend dei gruppi di istanze, assicurati che la porta del controllo di integrità nel manifest BackendConfig corrisponda a nodePort esposta dal servizio.
  • Ingress non supporta gRPC per le configurazioni personalizzate controllo di integrità. BackendConfig supporta solo la creazione di controlli di integrità utilizzando i protocolli HTTP, HTTPS o HTTP2. Per un esempio di come utilizzare il protocollo in una BackendConfig CRD, consulta gke-networking-recipes.

Per saperne di più, consulta Quando utilizzare le CRD BackendConfig.

Probe di idoneità

Quando utilizzi GKE Ingress con il bilanciamento del carico HTTP o HTTPS, GKE invia i probe del controllo di integrità per determinare se l'applicazione è in esecuzione correttamente. Questi probe del controllo di integrità vengono inviati alla porta specifica dei pod definita nella sezione spec.containers[].readinessProbe.httpGet.port della configurazione YAML del pod, a condizione che siano soddisfatte le seguenti condizioni:

  • Il numero di porta del probe di idoneità specificato in spec.containers[].readinessProbe.httpGet.port deve corrispondere alla porta effettiva su cui l'applicazione è in ascolto all'interno del container, definita nel campo containers[].spec.ports.containerPort della configurazione del pod.
  • containerPort del pod di gestione deve corrispondere a targetPort del servizio. In questo modo, il traffico viene indirizzato dal servizio alla porta corretta dei pod.
  • La specifica della porta di backend del servizio Ingress deve fare riferimento a una porta valida dalla sezione spec.ports[] della configurazione del servizio. Questa operazione può essere eseguita in due modi:
    • spec.rules[].http.paths[].backend.service.port.name in Ingress corrisponde a spec.ports[].name definito nel servizio corrispondente.
    • spec.rules[].http.paths[].backend.service.port.number in Ingress corrisponde a spec.ports[].port definito nel servizio corrispondente.

Risolvere i problemi comuni controllo di integrità

Utilizza il seguente diagramma di flusso per la risoluzione dei problemi per identificare eventuali problemi relativi controllo di integrità:

Risoluzione dei problemi relativi ai controlli di integrità in entrata.
Figura: Risolvere i problemi dei controlli di integrità

In questo diagramma di flusso, le seguenti indicazioni per la risoluzione dei problemi ti aiutano a determinare la causa del problema:

  1. Esamina l'integrità dei pod: se il controllo di integrità non viene superato, esamina lo stato dei pod di gestione del servizio. Se i pod non sono in esecuzione e non sono integri:

    • Controlla i log dei pod per verificare la presenza di errori o problemi che impediscono la loro esecuzione.
    • Controlla lo stato dei probe di idoneità e di attività.

  2. Logging del controllo di integrità: assicurati di aver abilitato il logging del controllo di integrità.

  3. Verifica la configurazione del firewall: assicurati che le regole firewall consentano ai probe del controllo di integrità di raggiungere i pod. In caso contrario:

    • Controlla le regole firewall per verificare che consentano il traffico in entrata dagli intervalli di indirizzi IP dei probe del controllo di integrità.
    • Modifica le regole firewall in base alle esigenze per adattarle a questi intervalli di indirizzi IP.

  4. Analizza l'acquisizione dei pacchetti: se il firewall è configurato correttamente, esegui un'acquisizione dei pacchetti per verificare se l'applicazione risponde ai controlli di integrità. Se l'acquisizione dei pacchetti mostra una risposta riuscita, contatta Google Cloud l'assistenza per ricevere ulteriore assistenza.

  5. Risolvi i problemi dell'applicazione: se l'acquisizione dei pacchetti non mostra una risposta riuscita, esamina il motivo per cui l'applicazione non risponde correttamente alle richieste di controllo di integrità. Verifica che il controllo di integrità sia destinato al percorso e alla porta corretti dei pod ed esamina i log delle applicazioni, i file di configurazione e le dipendenze. Se non riesci a trovare l'errore, contatta Google Cloud l'assistenza.

Applicazione che non risponde ai controlli di integrità

L'applicazione non risponde con il codice di stato previsto (200 OK per HTTP o SYN, ACK per TCP) durante i controlli di integrità sul percorso e sulla porta configurati.

Se l'applicazione non risponde correttamente ai controlli di integrità, il motivo potrebbe essere uno dei seguenti:

  • Gruppi di endpoint di rete(NEG):
    • L'applicazione non è in esecuzione correttamente all'interno del pod.
    • L'applicazione non è in ascolto sulla porta o sul percorso configurati.
    • Esistono problemi di connettività di rete che impediscono al controllo di integrità di raggiungere il pod.
  • Gruppo di istanze:
    • I nodi del gruppo di istanze non sono integri.
    • L'applicazione non è in esecuzione correttamente sui nodi.
    • Le richieste di controllo di integrità non raggiungono i nodi.

Se i controlli di integrità non vengono superati, risolvi il problema in base alla configurazione:

Per i NEG:

  1. Accedi a un pod utilizzando kubectl exec:

    kubectl exec -it pod-name -- command

    Il flag -it fornisce una sessione di terminale interattiva (i per interattiva, t per TTY).

    Sostituisci quanto segue:

    • pod-name: il nome del pod.
    • command: il comando che vuoi eseguire all'interno del pod. Il comando più comune è bash o sh per ottenere una shell interattiva.

  2. Esegui i comandi curl per testare la connettività e la reattività dell'applicazione:

    • curl localhost:<Port>/<Path>
    • curl -v http://<POD_IP>/[Path configured in HC]
    • curl http://localhost/[Path configured in HC]

Per i gruppi di istanze:

  1. Assicurati che i nodi siano integri e rispondano ai probe di controllo di integrità predefiniti.
  2. Se i nodi sono integri, ma il pod dell'applicazione non risponde, esamina ulteriormente l'applicazione.
  3. Se le richieste non raggiungono i pod, potrebbe trattarsi di un problema di networking di GKE. Contatta l'assistenza per ricevere aiuto. Google Cloud

Errore durante la modifica del probe di idoneità sul pod

Quando tenti di modificare il probe di idoneità su un pod per cambiare i parametri del controllo di integrità, si verifica un errore simile al seguente:

Pod "pod-name" is invalid: spec: Forbidden: pod updates may not change fields

Se modifichi il probe di idoneità dei pod associati a un servizio già collegato a un Ingress (e al relativo bilanciatore del carico), GKE non aggiorna automaticamente la configurazione del controllo di integrità sul bilanciatore del carico. Ciò comporta una mancata corrispondenza tra il controllo di idoneità del pod e il controllo di integrità del bilanciatore del carico, causando il fallimento del controllo di integrità.

Per risolvere il problema, riesegui il deployment dei pod e della risorsa Ingress. In questo modo, GKE ricrea il bilanciatore del carico e i relativi controlli di integrità e incorpora le nuove impostazioni del probe di idoneità.

Impossibile avviare il deployment e il bilanciatore del carico

Se il deployment non viene avviato e i servizi di backend dietro il bilanciatore del carico del controller Ingress sono contrassegnati come non integri, il motivo potrebbe essere un errore del probe di idoneità.

Potresti visualizzare il seguente messaggio di errore che indica un errore del probe di idoneità:

Readiness probe failed: connection refused

L'applicazione all'interno del pod non risponde correttamente al probe di idoneità configurato nella configurazione YAML del pod. Questo può dipendere da vari motivi, ad esempio l'applicazione non si avvia correttamente, è in ascolto sulla porta sbagliata o si verifica un errore durante l'inizializzazione.

Per risolvere il problema, esamina e correggi eventuali discrepanze nella configurazione o nel comportamento dell'applicazione procedendo nel seguente modo:

  • Assicurati che l'applicazione sia configurata correttamente e risponda sul percorso e sulla porta specificati nei parametri del probe di idoneità.
  • Esamina i log delle applicazioni e risolvi eventuali problemi o errori di avvio.
  • Verifica che containerPort nella configurazione del pod corrisponda a targetPort nel servizio e alla porta di backend specificata in Ingress.

Regole firewall Ingress automatiche mancanti

Hai creato una risorsa Ingress, ma il traffico non raggiunge il servizio di backend.

Le regole firewall Ingress automatiche, che in genere GKE crea quando viene creata una risorsa Ingress, non sono presenti o sono state eliminate inavvertitamente.

Per ripristinare la connettività al servizio di backend, segui questi passaggi:

  • Verifica l'esistenza delle regole firewall Ingress automatiche nella tua rete VPC.
  • Se le regole non sono presenti, puoi ricrearle manualmente o eliminare e ricreare la risorsa Ingress per attivarne la creazione automatica.
  • Assicurati che le regole firewall consentano il traffico sulle porte e sui protocolli appropriati definiti nella risorsa Ingress.

Protocollo errato utilizzato nel manifest BackendConfig

Se configuri una CRD BackendConfig con un protocollo di tipo TCP, viene visualizzato il seguente errore:

Error syncing to GCP: error running backend syncing routine:
error ensuring health check: Protocol "TCP" is not valid, must be one of ["HTTP","HTTPS","HTTP2"]'

BackendConfig supporta la creazione di controlli di integrità utilizzando solo i protocolli HTTP, HTTPS o HTTP/2. Per saperne di più, consulta Criteri di esito positivo per HTTP, HTTPS e HTTP/2.

Passaggi successivi