Risolvi i problemi del server API Kubernetes

Questa pagina mostra come risolvere i problemi relativi al server API Kubernetes (kube-apiserver) per Google Distributed Cloud.

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

Timeout del webhook e delle chiamate webhook non riuscite

Questi errori potrebbero essere visualizzati in diversi modi. Se si verificano i seguenti sintomi, è possibile che le chiamate webhook non vadano a buon fine:

  • Connessione rifiutata: se kube-apiserver segnala errori di timeout per la chiamata al webhook, nei log viene riportato il seguente errore:

    failed calling webhook "server.system.private.gdc.goog":
failed to call webhook: Post "https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s":
dial tcp 10.202.1.18:443: connect: connection refused

  • Scadenza contesto superata: nei log potresti anche visualizzare il seguente errore:

    failed calling webhook "namespaces.hnc.x-k8s.io": failed to call webhook: Post
"https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\":
context deadline exceeded"

Se ritieni di riscontrare timeout del webhook o chiamate webhook non riuscite, utilizza uno dei seguenti metodi per verificare il problema:

  • Controlla il log del server API per verificare se ci sono problemi di rete.

    • Controlla il log per verificare la presenza di errori relativi alla rete, come TLS handshake error.
    • Verifica che l'IP/la porta corrisponda a quello su cui il server API è configurato per rispondere.

  • Monitora la latenza del webhook con i seguenti passaggi:

    1. Nella console, vai alla pagina di Cloud Monitoring.

      Vai alla pagina di Cloud Monitoring

    2. Seleziona Esplora metriche.

    3. Seleziona la metrica apiserver_admission_webhook_admission_duration_seconds.

Per risolvere il problema, esamina i seguenti suggerimenti:

  • Potrebbero essere necessarie ulteriori regole firewall per il webhook. Per ulteriori informazioni, scopri come aggiungere regole firewall per casi d'uso specifici.

  • Se il webhook richiede più tempo per il completamento, puoi configurare un valore di timeout personalizzato. La latenza dei webhook aumenta la latenza delle richieste API, pertanto deve essere valutata il più rapidamente possibile.

  • Se l'errore del webhook blocca la disponibilità del cluster o se il webhook non riesce a rimuovere e mitiga la situazione, controlla se è possibile impostare temporaneamente failurePolicy su Ignore o rimuovere il webhook in questione.

Latenza o errore di connessione del server API

Questo errore potrebbe essere visualizzato in diversi modi:

  • Errori di risoluzione dei nomi esterni: un client esterno potrebbe restituire errori che contengono lookup nel messaggio, ad esempio:

    dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host

    Questo errore non si applica a un client in esecuzione all'interno del cluster. L'IP del servizio Kubernetes viene inserito, quindi non è richiesta alcuna risoluzione.

  • Errori di rete: il client potrebbe stampare un errore di rete generico quando tenta di chiamare il server API, come nei seguenti esempi:

    dial tcp 10.96.0.1:443: connect: no route to host
dial tcp 10.96.0.1:443: connect: connection refused
dial tcp 10.96.0.1:443: connect: i/o timeout

  • Connessione ad alta latenza al server API: la connessione al server API potrebbe riuscire, ma le richieste scadono sul lato client. In questo scenario, in genere il client stampa messaggi di errore contenenti context deadline exceeded.

Se la connessione al server API non riesce completamente, prova la connessione nello stesso ambiente in cui il client segnala l'errore. È possibile utilizzare i container temporanei Kubernetes per inserire un container di debug negli spazi dei nomi esistenti nel seguente modo:

  1. Da dove viene eseguito il client problematico, utilizza kubectl per eseguire una richiesta con un livello di dettaglio elevato. Ad esempio, una richiesta GET a /healthz di solito non richiede l'autenticazione:

    kubectl get -v999 --raw /healthz

  2. Se la richiesta non riesce o kubectl non è disponibile, puoi ottenere l'URL dall'output ed eseguire manualmente la richiesta con curl. Ad esempio, se l'host di servizio ottenuto dall'output precedente era https://192.0.2.1:36917/, puoi inviare una richiesta simile come segue:

    # Replace "--ca-cert /path/to/ca.pem" to "--insecure" if you are accessing
# a local cluster and you trust the connection cannot be tampered.
# The output is always "ok" and thus contains no sensentive information.

curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthz

    L'output di questo comando di solito indica la causa principale di una connessione non riuscita.

    Se la connessione riesce, ma è lenta o si verifica un timeout, indica un server API sovraccarico. Per conferma, controlla API Server Request Rate nella console e richiedi le metriche di latenza in Cloud Kubernetes > Anthos > Cluster > K8s Control Plane.

Per risolvere gli errori di connessione o i problemi di latenza, esamina le seguenti opzioni di correzione:

  • Se si verifica un errore di rete all'interno del cluster, potrebbe esserci un problema con il plug-in Container Network Interface (CNI). Questo problema è di solito temporaneo e si risolve automaticamente dopo la riprogrammazione o la ricreazione di un pod.

  • Se l'errore di rete proviene dall'esterno del cluster, controlla se il client è configurato correttamente per accedere al cluster oppure genera di nuovo la configurazione del client. Se la connessione passa attraverso un proxy o un gateway, verifica se funziona un'altra connessione che passa attraverso lo stesso meccanismo.

  • Se il server API è sovraccarico, in genere significa che molti client accedono al server API contemporaneamente. Un singolo client non può sovraccaricare un server API a causa della limitazione e della funzionalità Priorità e equità. Esamina il carico di lavoro per le seguenti aree:

    • Funziona a livello di pod. Per errore è più comune creare ed eliminare i pod per errore rispetto alle risorse di livello superiore.
    • Regola il numero di repliche tramite un calcolo errato.
    • Un webhook che ripete la richiesta in loop a se stessa o amplifica il carico creando più richieste di quante ne gestisce.

Passaggi successivi

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