Risolvere i problemi relativi ai controlli di integrità di Ingress

Questa pagina mostra come risolvere i problemi relativi ai controlli di integrità di Ingress in Google Kubernetes Engine (GKE).

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

Informazioni sul funzionamento dei controlli di integrità di Ingress

Prima di procedere con i passaggi per la risoluzione dei problemi, può essere utile capire come funzionano i controlli di integrità in GKE e quali considerazioni tenere a mente per garantire il buon esito dei controlli.

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

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

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

  • BackendConfig CRD: 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 stato associato al servizio di backend corrispondente. Queste impostazioni personalizzate offrono maggiore flessibilità e controllo sui controlli di integrità sia per l'Application Load Balancer classico sia per l'Application Load Balancer 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 servizio. Puoi ricavare i parametri di controllo di integrità, come percorso, porta e protocollo, dalla definizione del probe di idoneità.
  • Valori predefiniti: i parametri utilizzati quando non configuri un BackendConfig CRD o non definisci gli attributi per il test di idoneità.
Best practice:

Utilizza un BackendConfig CRD 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 un BackendConfig CRD con informazioni su healthCheck, GKE lo utilizza per creare il controllo di stato. Sia il controller Ingress di GKE Enterprise sia il controller GKE Ingress supportano la creazione di controlli di integrità in questo modo.

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

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

    • Se il modello di pod per i pod di servizio in esecuzione non ha un contenitore con un controllo di idoneità i cui attributi possono essere interpretati come parametri di 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 illustra alcune considerazioni da tenere presenti quando configuri un BackendConfig CRD o utilizzi un probe di idoneità.

BackendConfig CRD

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

  • Se utilizzi il bilanciamento del carico nativo del container, assicurati che la porta di controllo di integrità nel file manifest BackendConfig corrisponda al containerPort di un pod di servizio.
  • Per i backend del gruppo di istanze, assicurati che la porta del controllo di integrità nel manifest BackendConfig corrisponda a nodePort esposto dal servizio.
  • Ingress non supporta gRPC per le configurazioni controllo di integrità personalizzati. 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 un BackendConfig CRD, consulta gke-networking-recipes.

Per ulteriori informazioni, consulta Quando utilizzare i BackendConfig CRD.

Probe di idoneità

Quando utilizzi GKE Ingress con il bilanciamento del carico HTTP o HTTPS, GKE invia i controlli di integrità per determinare se l'applicazione è in esecuzione correttamente. Questi probe di controllo dell'integrità vengono inviati alla porta specifica dei pod che hai definito 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 controllo di idoneità specificato in spec.containers[].readinessProbe.httpGet.port deve corrispondere alla porta effettiva su cui l'applicazione è in ascolto all'interno del contenitore, definita nel containers[].spec.ports.containerPort campo della configurazione del pod.
  • Il valore containerPort del pod di pubblicazione deve corrispondere al valore targetPort del servizio. In questo modo, il traffico viene indirizzato dal servizio alla porta corretta sui pod.
  • La specifica della porta del backend del servizio di ingresso deve fare riferimento a una porta valida della sezione spec.ports[] della configurazione del servizio. Puoi farlo in uno dei due modi:
    • spec.rules[].http.paths[].backend.service.port.name nell'elemento 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 di controllo di integrità:

Risoluzione dei problemi relativi ai controlli di integrità di Ingress.
Figura: risolvere i problemi relativi ai controlli di stato

In questo diagramma di flusso, le seguenti indicazioni per la risoluzione dei problemi aiutano a determinare dove si trova il problema:

  1. Esamina l'integrità dei pod: se il controllo di integrità non va a buon fine, esamina lo stato dei pod di servizio. Se i pod non sono in esecuzione e sono in stato corretto:

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

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

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

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

  4. Esegui l'analisi dell'acquisizione dei pacchetti: se il firewall è configurato correttamente, esegui un'acquisizione dei pacchetti per verificare se l'applicazione risponde ai controlli di stato. Se la cattura dei pacchetti mostra una risposta positiva, contatta l'assistenza di Google Cloud per ulteriore assistenza.

  5. Risolvi i problemi dell'applicazione: se la cattura dei pacchetti non mostra una risposta positiva, scopri perché l'applicazione non risponde correttamente alle richieste di controllo di integrità. Verifica che il controllo di integrità abbia come target il percorso e la porta corretti sui pod ed esamina i log, i file di configurazione e le dipendenze dell'applicazione. Se non riesci a trovare l'errore, contatta l'assistenza Google Cloud.

L'applicazione 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 la tua applicazione non risponde correttamente ai controlli di integrità, la causa potrebbe essere uno dei seguenti motivi:

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

Se i controlli di integrità non vanno a buon fine, risolvi il problema in base alla tua configurazione come segue:

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 da eseguire all'interno del pod. Il comando più comune è bash o sh per ottenere una shell interattiva.

  2. Esegui i comandi curl per verificare 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 meglio l'applicazione.
  3. Se le richieste non raggiungono i pod, potrebbe trattarsi di un problema di rete GKE. Contatta l'assistenza Google Cloud per ricevere supporto.

Errore durante la modifica del controllo di idoneità nel pod

Quando provi a modificare il probe di idoneità su un pod per modificare i parametri di controllo di integrità, viene visualizzato un errore simile al seguente:

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

Se modifichi il controllo 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, esegui nuovamente il deployment dei pod e della risorsa Ingress. In questo modo, GKE viene costretto a ricreare il bilanciatore del carico e i relativi controlli di integrità, nonché a incorporare le nuove impostazioni del probe di idoneità.

Il deployment e il bilanciatore del carico non riescono ad avviarsi

Se il deployment non riesce ad avviarsi e i servizi di backend dietro il bilanciatore del carico del controller Ingress sono contrassegnati come non operativi, la causa potrebbe essere un errore del probe di idoneità.

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

Readiness probe failed: connection refused

L'applicazione all'interno del pod non risponde correttamente al controllo di idoneità configurato nella configurazione YAML del pod. Ciò può essere dovuto a vari motivi, come l'avvio non corretto dell'applicazione, l'ascolto sulla porta sbagliata o l'incontro con un errore durante l'inizializzazione.

Per risolvere il problema, esamina e correggi eventuali discrepanze nella configurazione o nel comportamento della tua applicazione nel seguente modo:

  • Assicurati che l'applicazione sia configurata correttamente e risponda sul percorso e sulla porta specificati nei parametri del controllo di idoneità.
  • Esamina i log dell'applicazione 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 in entrata 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:

  • Verifica l'esistenza delle regole del firewall Ingress automatico nella 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 del firewall consentano il traffico sulle porte e sui protocolli appropriati, come definito nella risorsa Ingress.

Passaggi successivi

Per configurare controlli di integrità personalizzati per Ingress in un singolo cluster, consulta le ricette di networking GKE.