Risolvere i problemi relativi ai controlli di integrità di Ingress

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

Come funzionano i controlli di integrità 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 la riuscita dei controlli di integrità.

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 in una singola mappa URL. Ciascuno dei servizi di backend corrisponde a un servizio Kubernetes e ogni servizio di backend deve fare riferimento a un Trusted 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 è 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 offre un controllo preciso sul 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 preparazione utilizzato dai pod di pubblicazione del servizio. Puoi derivare i parametri di controllo di integrità, come percorso, porta e protocollo, dalla definizione del probe di preparazione.
  • Valori predefiniti: i parametri utilizzati quando non configuri un BackendConfig CRD o non definisci attributi per il probe di preparazione.
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 CRD BackendConfig con informazioni healthCheck, GKE le utilizza per creare il controllo di integrità. Sia il controller GKE Enterprise Ingress sia il controller GKE Ingress 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 servizio utilizzano un modello di pod con un container la cui sonda di idoneità ha attributi che possono essere interpretati come parametri di controllo di integrità. Consulta Parametri di un probe di preparazione per i dettagli di implementazione e Parametri predefiniti e dedotti per un elenco degli attributi che possono essere utilizzati per creare parametri di controllo di integrità. Solo il controller GKE Ingress supporta l'inferenza dei parametri da un probe di disponibilità.

    • Se il modello di pod per i pod di pubblicazione del servizio non ha un container con un probe di idoneità i cui attributi possono essere interpretati come parametri di controllo di integrità, i valori predefiniti vengono utilizzati 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 quanto segue:

  • Se utilizzi il bilanciamento del carico nativo del container, assicurati che la porta del controllo di integrità nel manifest BackendConfig corrisponda alla containerPort di un pod di servizio.
  • Per i backend dei gruppi di istanze, assicurati che la porta del controllo di integrità nel manifest BackendConfig corrisponda alla porta 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 CRD BackendConfig, consulta gke-networking-recipes.

Per ulteriori informazioni, consulta la sezione Quando utilizzare i CRD BackendConfig.

Probe di idoneità

Quando utilizzi GKE Ingress con il bilanciamento del carico HTTP o HTTPS, GKE invia i probe di controllo di integrità per determinare se la tua applicazione è in esecuzione correttamente. Questi probe di 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.
  • Il containerPort del pod di pubblicazione deve corrispondere al targetPort del servizio. In questo modo, il traffico viene indirizzato dal servizio alla porta corretta dei pod.
  • La specifica della porta del backend del servizio di Ingress deve fare riferimento a una porta valida dalla sezione spec.ports[] della configurazione del servizio. Puoi farlo 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 di controllo di integrità:

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

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

  1. Esamina l'integrità dei pod: se il controllo di integrità non riesce, esamina lo stato dei pod di pubblicazione 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 pacchetti: se il firewall è configurato correttamente, esegui un'acquisizione pacchetti per verificare se la tua applicazione risponde ai controlli di integrità. Se l'acquisizione del pacchetto mostra una risposta riuscita, contatta l'assistenzaTrusted Cloud by S3NS per ulteriore aiuto.

  5. Risolvi i problemi dell'applicazione: se l'acquisizione di pacchetti non mostra una risposta riuscita, indaga sul motivo per cui l'applicazione non risponde correttamente alle richieste di controllo di integrità. Verifica che il controllo di integrità sia indirizzato al percorso e alla 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 Trusted Cloud by S3NS .

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à, il motivo potrebbe essere uno dei seguenti:

  • Gruppi di endpoint di rete(NEG):
    • L'applicazione non viene eseguita 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à'integrità di raggiungere il pod.
  • Gruppo di istanze:
    • I nodi nel gruppo di istanze non sono integri.
    • L'applicazione non viene eseguita correttamente sui nodi.
    • Le richieste di controllo di integrità non raggiungono i nodi.

Se i controlli di integrità non riescono, in base alla configurazione, risolvi il problema 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 interattivo, 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 l'applicazione più nel dettaglio.
  3. Se le richieste non raggiungono i pod, potrebbe trattarsi di un problema di rete GKE. Contatta l'assistenza di Trusted Cloud by S3NS per ricevere aiuto.

Errore durante la modifica del probe di preparazione sul pod

Quando tenti di modificare il probe di idoneità su un pod per cambiare i parametri del 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 probe di preparazione 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 l'esito negativo del controllo di integrità.

Per risolvere il problema, esegui nuovamente 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à.

Il deployment e il bilanciatore del carico non vengono avviati

Se l'avvio del deployment non riesce e i servizi di backend dietro il bilanciamento 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 preparazione:

Readiness probe failed: connection refused

L'applicazione all'interno del pod non risponde correttamente al probe di preparazione configurato nella configurazione YAML del pod. Ciò può essere dovuto a 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 della tua 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 preparazione.
  • 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 in entrata 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 firewall Ingress automatiche nella tua rete VPC.
  • Se le regole non sono presenti, puoi ricrearle manualmente o eliminare e ricreare la risorsa Ingress per attivare la loro creazione automatica.
  • Assicurati che le regole firewall consentano il traffico sulle porte e sui protocolli appropriati, come definito nella risorsa Ingress.

Protocollo errato utilizzato nel file 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