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 è rivolta agli amministratori IT e agli operatori che gestiscono ciclo di vita dell'infrastruttura tecnica sottostante e rispondere ad avvisi e pagine quando gli obiettivi del livello di servizio (SLO) non vengono soddisfatti o le applicazioni non vanno a buon fine. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

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

Timeout webhook e chiamate webhook non riuscite

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

  • Connessione rifiutata: se kube-apiserver segnala errori di timeout per chiamando il 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: potresti anche visualizzare il seguente errore nei log:

    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 o chiamate webhook non riuscite, utilizza uno dei seguenti metodi per confermare il problema:

  • Controlla il log del server API per verificare se si verificano problemi di rete.

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

  • Monitora la latenza del webhook seguendo questi 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 completamento del webhook richiede più tempo, puoi configurare un valore di timeout personalizzato. La latenza dei webhook si aggiunge alla latenza della richiesta dell'API, pertanto deve essere valutata il più rapidamente possibile.

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

Errore o latenza di chiamata del server API

Questo errore potrebbe essere visualizzato in diversi modi:

  • Errori di risoluzione dei nomi esterni: un client esterno potrebbe restituire errori contenenti 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 se tenta di connettersi per chiamare il server API, come negli esempi seguenti:

    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 avere esito positivo, ma le richieste scadono sul lato client. In questo scenario, solitamente il client stampa messaggi di errore contenenti context deadline exceeded.

Se la connessione al server API non riesce, prova a eseguire la connessione entro nello stesso ambiente in cui il client segnala l'errore. Container temporanei Kubernetes può essere utilizzato per inserire un container di debug negli spazi dei nomi esistenti che segue:

  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 in genere non richiede l'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'https://192.0.2.1:36917/hosting 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 una connessione non riuscita.

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

Per risolvere questi problemi di latenza o di connessione, esamina le seguenti opzioni di rimedio:

  • Se si verifica un errore di rete all'interno del cluster, potrebbe esserci un problema relativo Plug-in Container Network Interface (CNI). Questo problema è solitamente transitorio e si risolve dopo la ricreazione o la riprogrammazione del pod.

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

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

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

Passaggi successivi

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