Questa pagina mostra come risolvere i problemi relativi a Google Kubernetes Engine (GKE) Autopilot.
Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.Problemi relativi ai cluster
Impossibile creare un cluster: 0 nodi registrati
Il problema seguente si verifica quando provi a creare un cluster Autopilot con un account di servizio IAM disabilitato o che non dispone delle autorizzazioni necessarie. La creazione del cluster non riesce e viene visualizzato il seguente messaggio di errore:
All cluster resources were brought up, but: only 0 nodes out of 2 have registered.
Per risolvere il problema:
Controlla se l'account di servizio Compute Engine predefinito o l'account di servizio IAM personalizzato che vuoi utilizzare disattivata:
gcloud iam service-accounts describe SERVICE_ACCOUNT
Sostituisci
SERVICE_ACCOUNT
con l'indirizzo email dell'account di servizio indirizzo email, ad esempio[email protected]
.Se l'account di servizio è disabilitato, l'output è simile al seguente:
disabled: true displayName: my-service-account email: [email protected] ...
Se l'account di servizio è disabilitato, abilitalo:
gcloud iam service-accounts enable SERVICE_ACCOUNT
Se l'account di servizio è abilitato e l'errore persiste, concedi la all'account di servizio le autorizzazioni minime richieste per GKE:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SERVICE_ACCOUNT" \
--role roles/container.nodeServiceAccount
Spazio dei nomi bloccato nello stato di terminazione quando il cluster ha 0 nodi
Il seguente problema si verifica quando elimini uno spazio dei nomi in un cluster dopo
fa lo scale down di un cluster a zero nodi. Il componente metrics-server
non può accettare
la richiesta di eliminazione dello spazio dei nomi perché il componente ha zero repliche.
Per diagnosticare il problema, esegui questo comando:
kubectl describe ns/NAMESPACE_NAME
Sostituisci NAMESPACE_NAME
con il nome dello spazio dei nomi.
L'output è il seguente:
Discovery failed for some groups, 1 failing: unable to retrieve the complete
list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to
handle the request
Per risolvere questo problema, fai lo scale up di qualsiasi carico di lavoro per attivare GKE in per creare un nuovo nodo. Quando il nodo è pronto, la richiesta di eliminazione dello spazio dei nomi viene completata automaticamente. Dopo che GKE ha eliminato lo spazio dei nomi, per il carico di lavoro.
Problemi di scalabilità
Impossibile fare lo scale up del nodo: il pod rischia di non essere pianificato
Il seguente problema si verifica quando il logging delle porte seriali è disabilitato nel tuo progetto Google Cloud. I cluster GKE Autopilot richiedono il logging delle porte seriali per eseguire efficacemente il debug dei problemi dei nodi. Se il logging delle porte seriali è disabilitata, Autopilot non può eseguire il provisioning dei nodi per eseguire i tuoi carichi di lavoro.
Il messaggio di errore nel log eventi di Kubernetes è simile al seguente:
LAST SEEN TYPE REASON OBJECT MESSAGE
12s Warning FailedScaleUp pod/pod-test-5b97f7c978-h9lvl Node scale up in zones associated with this pod failed: Internal error. Pod is at risk of not being scheduled
Il logging delle porte seriali potrebbe essere disabilitato a livello di organizzazione tramite una
criterio dell'organizzazione che applica compute.disableSerialPortLogging
di blocco. Il logging delle porte seriali potrebbe essere disabilitato anche a livello di progetto o di macchina virtuale
di macchina virtuale (VM).
Per risolvere il problema:
- Chiedi all'amministratore dei criteri dell'organizzazione di Google Cloud di
rimuovi il vincolo
compute.disableSerialPortLogging
nel progetto con il tuo cluster Autopilot. - Se non hai un criterio dell'organizzazione che applica questo vincolo, prova
a
abilitare il logging delle porte seriali nei metadati di progetto.
Questa azione richiede
compute.projects.setCommonInstanceMetadata
Autorizzazione IAM.
Impossibile fare lo scale up del nodo: risorse GCE esaurite
Il seguente problema si verifica quando i carichi di lavoro richiedono più risorse di quelle
disponibili per l'uso nella regione o
zona di Compute Engine. I pod potrebbero rimanere
nello stato Pending
.
Controlla gli eventi dei pod:
kubectl events --for='pod/POD_NAME' --types=Warning
Sostituisci
RESOURCE_NAME
con il nome dell'evento in attesa di una risorsa Kubernetes. Ad esempiopod/example-pod
.L'output è simile al seguente:
LAST SEEN TYPE REASON OBJECT Message 19m Warning FailedScheduling pod/example-pod gke.io/optimize-utilization-scheduler 0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling. 14m Warning FailedScheduling pod/example-pod gke.io/optimize-utilization-scheduler 0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling. 12m (x2 over 18m) Warning FailedScaleUp cluster-autoscaler Node scale up in zones us-central1-f associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled. 34s (x3 over 17m) Warning FailedScaleUp cluster-autoscaler Node scale up in zones us-central1-b associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.
Per risolvere il problema, prova a procedere nel seguente modo:
- Esegui il deployment del pod in un'altra regione o zona. Se il tuo pod ha un servizio di gestione come un selettore di topologia, rimuovila, se possibile. Per istruzioni, vedi collocare i pod GKE in zone specifiche.
- Crea un cluster in una regione diversa e riprova a eseguire il deployment.
- Prova a utilizzare un'altra classe di computing. Classi di calcolo supportate è più probabile che siano disponibili tipi di macchine Compute Engine più piccoli Google Cloud. Ad esempio, il tipo di macchina predefinito per Autopilot la disponibilità più elevata. Per un elenco di classi di computing e i valori corrispondenti quali tipi di macchina, Quando utilizzare classi di computing specifiche.
- Se esegui carichi di lavoro GPU, la GPU richiesta potrebbe non essere disponibile nel tuo del nodo. Prova a eseguire il deployment del carico di lavoro in una località diversa richiedendo un tipo diverso di GPU.
Per evitare problemi di scale up causati dalla disponibilità delle risorse in futuro, considera i seguenti approcci:
- Usare PriorityClass di Kubernetes per eseguire in modo coerente il provisioning di capacità di calcolo aggiuntiva nel tuo cluster. Per maggiori dettagli, vedi Esegui il provisioning di capacità di calcolo aggiuntiva per una rapida scalabilità dei pod.
- Utilizza le prenotazioni di capacità di Compute Engine con il riquadro Classi di calcolo dell'acceleratore. Per maggiori dettagli, vedi Utilizza risorse di zona riservate.
Impossibile fare lo scale up dei nodi: risorse di zona dei pod superate
Il seguente problema si verifica quando Autopilot non esegue il provisioning di nuovi nodi per un pod in una zona specifica, perché un nuovo nodo violerebbe i limiti delle risorse.
Il messaggio di errore nei log è simile al seguente:
"napFailureReasons": [
{
"messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
...
Questo errore si riferisce a noScaleUp
in cui il provisioning automatico dei nodi non ha eseguito il provisioning di alcun gruppo di nodi per il pod nella zona.
Se riscontri questo errore, verifica quanto segue:
- I pod hanno memoria e CPU sufficienti.
- L'intervallo CIDR degli indirizzi IP dei pod sia abbastanza grande da supportare la dimensione massima prevista del cluster.
Problemi relativi al carico di lavoro
Carichi di lavoro bloccati con un errore di archiviazione temporanea
GKE non creerà pod se l'archiviazione temporanea dei pod delle richieste superano il limite massimo di 10 GiB in GKE versione 1.28.6-gke.1317000 e successive.
Per diagnosticare questo problema, descrivi il controller del carico di lavoro, ad esempio il deployment o il job:
kubectl describe CONTROLLER_TYPE/CONTROLLER_NAME
Sostituisci quanto segue:
CONTROLLER_TYPE
: il tipo di controller dei carichi di lavoro, ad esempioreplicaset
odaemonset
. Per un elenco dei tipi di controller, vedi Carico di lavoro dei modelli.CONTROLLER_NAME
: il nome del carico di lavoro bloccato.
Se il pod non viene creato a causa della richiesta di archiviazione temporanea che ha superato massimo, l'output è simile al seguente:
# lines omitted for clarity
Events:
{"[denied by autogke-pod-limit-constraints]":["Max ephemeral-storage requested by init containers for workload '' is higher than the Autopilot maximum of '10Gi'.","Total ephemeral-storage requested by containers for workload '' is higher than the Autopilot maximum of '10Gi'."]}
Per risolvere il problema, aggiorna le richieste di spazio di archiviazione temporaneo in modo che il totale archiviazione temporanea richiesta dai container dei carichi di lavoro e dai container l'inserimento di webhook è inferiore o uguale al valore massimo consentito. Per maggiori informazioni informazioni sul limite massimo, Richieste di risorse in Autopilot. per la configurazione del carico di lavoro.
Pod bloccati in stato In attesa
Un pod potrebbe rimanere bloccato nello stato Pending
se selezioni un nodo specifico
utilizzabili dal pod, ma la somma delle richieste di risorse nel pod
I DaemonSet che devono essere eseguiti sul nodo superano la capacità massima allocabile di
nel nodo. Di conseguenza, il pod potrebbe ottenere lo stato Pending
e rimanere
non pianificate.
Per evitare questo problema, valuta le dimensioni dei carichi di lavoro di cui hai eseguito il deployment per assicurarti che rientrano nel numero massimo di richieste di risorse per Autopilot.
Puoi anche provare a pianificare i tuoi DaemonSet prima di programmare il tuo dei carichi di lavoro.
Pod bloccati durante l'arresto o la creazione
Un problema noto causa il blocco dei pod in uno dei seguenti casi: stati:
Terminating
CreateContainerError
Questo problema ha una piccola probabilità che si verifichi quando utilizzi i pod con possibilità di burst Ambienti GKE che soddisfano tutte le condizioni seguenti:
- I nodi eseguono versioni GKE a partire da 1.29.2-gke.1060000 fino a, ma escluso 1.30.2-gke.1394000.
- Il pod utilizza una delle seguenti classi di calcolo:
- La classe di computing per uso generico predefinita
- La classe di computing
Balanced
- La classe di computing
Scale-Out
Per limitare questo problema, esegui l'upgrade del piano di controllo alla versione GKE
1.30.2-gke.1394000 o versioni successive. Pod già bloccati in Terminating
oppure lo stato CreateContainerError
verrà implementato correttamente dopo
GKE ricrea i pod sui nodi che eseguono una versione fissa.
Quando esegui l'upgrade di un cluster Autopilot, GKE esegue l'upgrade nodi worker in modo che corrispondano alla versione del piano di controllo nel tempo. Un piano di controllo. è necessario riavviare per abilitare il bursting e deve avvenire dopo l'esecuzione di tutti i nodi una versione supportata. Il piano di controllo si riavvia automaticamente circa una volta alla settimana durante operazioni come scalabilità, upgrade o manutenzione.
Per attivare manualmente il riavvio di un piano di controllo:
Controlla se tutti i nodi eseguono la versione 1.30.2-gke.1349000 o successiva:
kubectl get nodes
L'output è simile al seguente:
NAME STATUS ROLES AGE VERSION gk3-ap-cluster-1-default-pool-18092e49-mllk Ready <none> 4m26s v1.30.2-gke.1349000
Tutti i nodi nell'output devono mostrare la versione richiesta o successiva.
Avvia manualmente l'upgrade di un piano di controllo alla stessa versione di un cluster Kubernetes. Per istruzioni, vedi Upgrade manuale del piano di controllo.
Prestazioni del carico di lavoro costantemente inaffidabili su un nodo specifico
In GKE 1.24 e versioni successive, se i tuoi carichi di lavoro su una subiscono costantemente interruzioni, arresti anomali o simili comportamenti inaffidabili, puoi informare GKE del nodo problematico contrassegnandolo come non pianificabile utilizzando il seguente comando:
kubectl drain NODE_NAME --ignore-daemonsets
Sostituisci NODE_NAME
con il nome del nodo problematico.
Puoi trovare il nome del nodo eseguendo kubectl get nodes
.
GKE fa quanto segue:
- Rimuove i carichi di lavoro esistenti dal nodo e interrompe la pianificazione dei carichi di lavoro il giorno su quel nodo.
- Ricrea automaticamente tutti i carichi di lavoro eliminati che sono gestiti da un come un Deployment o uno StatefulSet, su altri nodi.
- Termina tutti i carichi di lavoro rimasti sul nodo e ripara o ricrea i carichi di lavoro il nodo nel tempo.
- Se usi Autopilot, GKE si arresta e sostituisce il nodo immediatamente e ignora eventuali PodDisruptionBudget configurati.
La pianificazione dei pod su cluster vuoti richiede più tempo del previsto
Questo evento si verifica quando esegui il deployment di un carico di lavoro in un cluster Autopilot che non ha altri carichi di lavoro. I cluster Autopilot iniziano con zero utilizzabili nodi e scalare fino a zero nodi se il cluster è vuoto per evitare di risorse di computing nel cluster. Eseguendo il deployment di un carico di lavoro in un cluster zero nodi attiva un evento di scale up.
In questo caso, la modalità Autopilot funziona come previsto e necessaria un'azione. Il deployment del carico di lavoro verrà eseguito come previsto dopo i nuovi nodi l'avvio.
Controlla se i tuoi pod sono in attesa di nuovi nodi:
Descrivi il pod in attesa:
kubectl describe pod POD_NAME
Sostituisci
POD_NAME
con il nome del pod in attesa.Controlla la sezione
Events
dell'output. Se il pod è in attesa di nuovi nodi, l'output è simile al seguente:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 11s gke.io/optimize-utilization-scheduler no nodes available to schedule pods Normal TriggeredScaleUp 4s cluster-autoscaler pod triggered scale-up: [{https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-9293c6db-grp 0->1 (max: 1000)} {https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-d99371e7-grp 0->1 (max: 1000)}]
L'evento
TriggeredScaleUp
mostra che il cluster sta eseguendo lo scale up da zero al numero di nodi necessario per eseguire il carico di lavoro di cui è stato eseguito il deployment.
Errore relativo all'autorizzazione durante il tentativo di eseguire tcpdump da un pod in GKE Autopilot
L'accesso ai nodi sottostanti è vietato in un cluster GKE Autopilot. Pertanto, è necessario eseguire l'utilità tcpdump
dall'interno di un pod e quindi copiarla utilizzando il comando kubectl cp.
Se in genere esegui l'utilità tcpdump dall'interno di un pod in un cluster GKE Autopilot, potresti visualizzare il seguente errore:
tcpdump: eth0: You don't have permission to perform this capture on that device
(socket: Operation not permitted)
Questo accade perché GKE Autopilot, per impostazione predefinita, applica a tutti i pod un contesto di sicurezza che elimina la funzionalità NET_RAW
per mitigare le potenziali vulnerabilità. Ad esempio:
apiVersion: v1
kind: Pod
metadata:
labels:
app: tcpdump
name: tcpdump
spec:
containers:
- image: nginx
name: nginx
resources:
limits:
cpu: 500m
ephemeral-storage: 1Gi
memory: 2Gi
requests:
cpu: 500m
ephemeral-storage: 1Gi
memory: 2Gi
securityContext:
capabilities:
drop:
- NET_RAW
Come soluzione, se il carico di lavoro richiede la funzionalità NET_RAW
, puoi riabilitarla:
Aggiungi la funzionalità
NET_RAW
alla sezionesecurityContext
della specifica YAML del tuo pod:securityContext: capabilities: add: - NET_RAW
Esegui
tcpdump
dall'interno di un pod:tcpdump port 53 -w packetcap.pcap tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
Utilizza il comando
kubectl cp
per copiarlo sul tuo computer locale per ulteriori analisi:kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAME
Usa
kubectl exec
per eseguire il comandotcpdump
al fine di eseguire l'acquisizione dei pacchetti di rete e reindirizzare l'output:kubectl exec -it POD_NAME -- bash -c "tcpdump port 53 -w -" > packet-new.pcap