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 il ciclo di vita dell'infrastruttura tecnologica di base e rispondono ad avvisi e 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
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.Timeout 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 la chiamata al webhook, nei log viene visualizzato 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 del contesto superata:nei log potrebbe essere visualizzato 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 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 ciò su cui è configurato il server API per rispondere.
- Controlla il log per verificare la presenza di errori relativi alla rete, ad esempio
Monitora la latenza del webhook seguendo questi passaggi:
Nella console, vai alla pagina Cloud Monitoring.
Seleziona Esplora metriche.
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 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
suIgnore
o rimuovere il webhook in questione.
Errore o latenza di chiamata del server API
Questo errore può 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 durante il tentativo di effettuare una chiamata al server API, ad esempio i 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
Tempi di latenza elevati durante la connessione al server API: la connessione al server API potrebbe essere andata a buon fine, ma le richieste scadono lato client. In questo scenario, solitamente il client stampa messaggi di errore contenenti
context deadline exceeded
.
Se la connessione al server API non va a buon fine, prova a eseguire la connessione nello stesso ambiente in cui il client segnala l'errore. I container temporanei Kubernetes possono essere utilizzati per iniettare un contenitore di debug negli spazi dei nomi esistenti come segue:
Da dove viene eseguito il client problematico, utilizza
kubectl
per eseguire una richiesta con un livello di dettagli elevato. Ad esempio, una richiestaGET
a/healthz
in genere non richiede l'autenticazione:kubectl get -v999 --raw /healthz
Se la richiesta non va a buon fine o
kubectl
non è disponibile, puoi ottenere l'URL dall'output ed eseguire manualmente la richiesta concurl
. Ad esempio, se l'https://192.0.2.1:36917/
��# 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 è riuscita, ma è lenta o scade il tempo, indica un server API sovraccaricato. Per confermare, nella console controlla
API Server Request Rate
e le metriche sulla latenza delle richieste inCloud 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 con il 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, controlla se il client è 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 funziona un'altra connessione che utilizza 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 a causa del throttling e della funzionalità Priorità e equità. 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.
- Modificare il numero di repliche tramite un calcolo errato.
- Un webhook che restituisce la richiesta a se stesso o amplifica il carico creando più richieste di quante ne possa gestire.