Risolvere i problemi del server dell'API Kubernetes

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

Questa pagina è dedicata agli amministratori IT e agli operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante e rispondono agli avvisi e alle pagine quando gli obiettivi del livello di servizio (SLO) non vengono raggiunti o le applicazioni non funzionano. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise. Google Cloud

Timeout webhook e chiamate webhook non riuscite

Questi errori possono essere visualizzati in diversi modi. Se riscontri uno dei seguenti sintomi, è possibile che le chiamate webhook non vadano a buon fine:

  • Connessione rifiutata:se kube-apiserver segnala errori di timeout per la chiamata del webhook, nei log viene segnalato 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

  • Context deadline exceeded: nei log potrebbe essere segnalato anche 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 webhook o chiamate webhook non riuscite, utilizza uno dei seguenti metodi per confermare il problema:

  • Controlla il log del server API per verificare se si è verificato un problema di rete.

    • Controlla il log per errori correlati alla rete, ad esempio TLS handshake error.
    • Verifica se l'IP/la porta corrisponde a ciò a cui è configurato per rispondere il server API.

  • Monitora la latenza del webhook seguendo questi passaggi:

    1. Nella console, vai alla pagina Cloud Monitoring.

      Vai alla pagina Cloud Monitoring

    2. Seleziona Esplora metriche.

    3. Seleziona la metrica apiserver_admission_webhook_admission_duration_seconds.

Per risolvere il problema, esamina i seguenti suggerimenti:

  • Per il webhook potrebbero essere necessarie regole firewall aggiuntive. Per saperne di più, scopri come aggiungere regole firewall per casi d'uso specifici.

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

  • Se l'errore del webhook blocca la disponibilità del cluster o il webhook è innocuo da rimuovere e mitiga la situazione, controlla se è possibile impostare temporaneamente failurePolicy su Ignore o rimuovere il webhook problematico.

Errore di connessione o latenza del server API

Questo errore può 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 è necessaria 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

  • Latenza elevata durante la connessione al server API:la connessione al server API potrebbe andare a buon fine, ma le richieste scadono lato client. In questo scenario, il client di solito stampa messaggi di errore contenenti context deadline exceeded.

Se la connessione al server API non va a buon fine, prova la connessione nello stesso ambiente in cui il client segnala l'errore. I container effimeri di Kubernetes possono essere utilizzati 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 autenticazione:

    kubectl get -v999 --raw /healthz

  2. Se la richiesta non va a buon fine o kubectl non è disponibile, puoi ottenere l'URL dall'output ed eseguire manualmente la richiesta con curl. Ad esempio, se l'host del 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 indica in genere la causa principale di un errore di connessione.

    Se la connessione viene stabilita, ma è lenta o si verifica un timeout, significa che il server API è sovraccarico. Per confermare, nella console esamina le metriche di latenza delle richieste e API Server Request Rate in Cloud Kubernetes > Anthos > Cluster > K8s Control Plane.

Per risolvere questi errori di connessione o 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 è in genere temporaneo e si risolve dopo la ricreazione o la riprogrammazione di un pod.

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

  • Se il server API è sovraccarico, di solito 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 correttezza. Esamina il carico di lavoro per le seguenti aree:

    • Funziona a livello di pod. È più comune creare e dimenticare per errore i pod rispetto alle risorse di livello superiore.
    • Modifica il numero di repliche tramite un calcolo errato.
    • Un webhook che esegue il loop della richiesta o amplifica il carico creando più richieste di quelle che gestisce.

Passaggi successivi

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

Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui: