Questa pagina mostra come risolvere i problemi relativi ai cluster Autopilot di Google Kubernetes Engine (GKE).
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.Problemi relativi ai cluster
Impossibile creare un cluster: 0 nodi registrati
Il seguente problema si verifica quando si tenta di creare un cluster Autopilot con un account di servizio IAM disattivato o che non dispone delle autorizzazioni richieste. La creazione del cluster non riesce con il seguente messaggio di errore:
All cluster resources were brought up, but: only 0 nodes out of 2 have registered.
Per risolvere il problema:
Verifica se l'account di servizio Compute Engine predefinito o l'account di servizio IAM personalizzato che vuoi utilizzare è disattivato:
gcloud iam service-accounts describe SERVICE_ACCOUNTSostituisci
SERVICE_ACCOUNTcon l'indirizzo email del service account, ad esempiomy-iam-account@my-first-project.iam.gserviceaccount.com.Se l'account di servizio è disattivato, l'output è simile al seguente:
disabled: true displayName: my-service-account email: my-service-account@my-project.iam.gserviceaccount.com ...Se l'account di servizio è disattivato, attivalo:
gcloud iam service-accounts enable SERVICE_ACCOUNT
Se l'account di servizio è abilitato e l'errore persiste, concedi 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
Lo spazio dei nomi è bloccato nello stato di terminazione quando il cluster non ha nodi
Il seguente problema si verifica quando elimini uno spazio dei nomi in un cluster dopo lo scale down del cluster a zero nodi. Il componente metrics-server non può accettare la richiesta di eliminazione del nome spazio perché non ha repliche.
Per diagnosticare il problema, esegui il seguente 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 il problema, esegui la scalabilità di qualsiasi carico di lavoro per attivare GKE in modo che crei 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, riduci nuovamente il carico di lavoro.
Problemi di scalabilità
Lo scale up del nodo non è riuscito: il pod rischia di non essere pianificato
Il seguente problema si verifica quando il logging della porta seriale è disabilitato nel tuo Google Cloud progetto. I cluster GKE Autopilot richiedono il logging della porta seriale per eseguire il debug dei problemi relativi ai nodi in modo efficace. Se il logging della porta seriale è disabilitato, 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
La registrazione della porta seriale potrebbe essere disabilitata a livello di organizzazione tramite un criterio dell'organizzazione che applica il vincolo compute.disableSerialPortLogging. Il logging della porta seriale può essere disattivato anche a livello di progetto o di istanza della macchina virtuale (VM).
Per risolvere il problema:
- Chiedi all' Google Cloud amministratore delle norme dell'organizzazione di
rimuovere il vincolo
compute.disableSerialPortLoggingnel progetto con il cluster Autopilot. - Se non hai un criterio dell'organizzazione che applichi questo vincolo, prova
a
abilitare il logging delle porte seriali nei metadati del progetto.
Questa azione richiede l'
compute.projects.setCommonInstanceMetadataautorizzazione IAM.
Lo scale up dei nodi non è riuscito: risorse GCE esaurite
Il seguente problema si verifica quando i carichi di lavoro richiedono più risorse di quelle disponibili per l'utilizzo nella regione o nella zona Compute Engine. I pod potrebbero rimanere
nello stato Pending.
Controlla gli eventi del pod:
kubectl events --for='pod/POD_NAME' --types=WarningSostituisci
RESOURCE_NAMEcon il nome della risorsa Kubernetes in attesa. 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 quanto segue:
- Esegui il deployment del pod in una regione o una zona diversa. Se il pod ha una limitazione di zona, ad esempio un selettore di topologia, rimuovila se possibile. Per le istruzioni, consulta Posizionare i pod GKE in zone specifiche.
- Crea un cluster in una regione diversa e riprova a eseguire il deployment.
- Prova a utilizzare una classe di calcolo diversa. Le classi di calcolo basate su tipi di macchine Compute Engine più piccoli hanno maggiori probabilità di avere risorse disponibili. Ad esempio, il tipo di macchina predefinito per Autopilot ha la disponibilità più elevata. Per un elenco delle classi di calcolo e dei tipi di macchine corrispondenti, consulta Quando utilizzare classi di calcolo specifiche.
- Se esegui carichi di lavoro GPU, la GPU richiesta potrebbe non essere disponibile nella località del tuo node. Prova a eseguire il deployment del tuo carico di lavoro in una posizione diversa o richiedi un altro tipo di GPU.
Per evitare problemi di scalabilità causati dalla disponibilità delle risorse in futuro, valuta i seguenti approcci:
- Utilizza PriorityClasses di Kubernetes per eseguire il provisioning coerente di una maggiore capacità di calcolo nel tuo cluster. Per maggiori dettagli, consulta Provisioning di capacità di calcolo aggiuntiva per il ridimensionamento rapido dei pod.
- Utilizza le prenotazioni della capacità di Compute Engine con le classi di calcolo Performance o Accelerator. Per maggiori dettagli, consulta Consumi risorse di zona prenotate.
Impossibile eseguire lo scale up dei nodi: risorse zonali del 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 un evento noScaleUp, in cui il provisioning automatico dei nodi non ha eseguito il provisioning di alcun gruppo di nodi per il pod nella zona.
Se si verifica questo errore, verifica quanto segue:
- I pod dispongono di memoria e CPU sufficienti.
- L'intervallo CIDR dell'indirizzo IP del pod è sufficientemente ampio da supportare la dimensione massima del cluster prevista.
Problemi relativi al carico di lavoro
Carichi di lavoro bloccati con errore di archiviazione temporanea
GKE non crea pod se le richieste di archiviazione temporanea dei pod superano il massimo di 10 GB di Autopilot nella versione GKE 1.28.6-gke.1317000 e successive.
Per diagnosticare il 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 esempioreplicasetodaemonset. Per un elenco dei tipi di controller, consulta Gestione del carico di lavoro.CONTROLLER_NAME: il nome del carico di lavoro bloccato.
Se il pod non viene creato perché la richiesta di spazio di archiviazione temporaneo supera il valore 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 archiviazione temporanea in modo che lo spazio di archiviazione temporaneo totale richiesto dai container dei carichi di lavoro e dai container iniettati dai webhook sia inferiore o uguale al massimo consentito. Per ulteriori informazioni sul valore massimo, consulta Richieste di risorse in Autopilot per la configurazione del carico di lavoro.
Pod bloccati nello stato In attesa
Un pod potrebbe rimanere bloccato nello stato Pending se selezioni un nodo specifico da utilizzare per il pod, ma la somma delle richieste di risorse nel pod e nei DaemonSet che devono essere eseguiti sul nodo supera la capacità allocabile massima del nodo. Ciò potrebbe causare lo stato Pending del pod e mantenerlo senza pianificazione.
Per evitare questo problema, valuta le dimensioni dei workload di cui è stato eseguito il deployment per assicurarti che rientrino nelle richieste di risorse massime supportate per Autopilot.
Puoi anche provare a pianificare i DaemonSet prima di pianificare i pod di workload normali.
Prestazioni del carico di lavoro in modo incoerente su un nodo specifico
In GKE 1.24 e versioni successive, se i carichi di lavoro su un determinato nodo presentano costantemente interruzioni, arresti anomali o comportamenti inaffidabili simili, puoi segnalare il nodo problematico a GKE isolandolo 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 esegue le seguenti operazioni:
- Rimuove i carichi di lavoro esistenti dal nodo e interrompe la pianificazione dei carichi di lavoro su quel nodo.
- Ricrea automaticamente tutti i carichi di lavoro espulsi gestiti da un controller, ad esempio un deployment o un StatefulSet, su altri nodi.
- Termina tutti i carichi di lavoro rimanenti sul nodo e ripara o ricrea il nodo nel tempo.
- Se utilizzi Autopilot, GKE arresta e sostituisce immediatamente il nodo 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 nodi utilizzabili e hanno scalabilità fino a zero nodi se il cluster è vuoto per evitare di avere risorse di calcolo inutilizzate nel cluster. Il deployment di un carico di lavoro in un cluster con zero nodi attiva un evento di scalabilità verticale.
In questo caso, Autopilot funziona come previsto e non è necessaria alcuna azione. Il carico di lavoro verrà implementato come previsto dopo l'avvio dei nuovi nodi.
Controlla se i pod sono in attesa di nuovi nodi:
Descrivi il pod in attesa:
kubectl describe pod POD_NAMESostituisci
POD_NAMEcon il nome del pod in attesa.Controlla la sezione
Eventsdell'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
TriggeredScaleUpindica che il cluster sta eseguendo il ridimensionamento da zero nodi al numero di nodi necessari per eseguire il tuo carico di lavoro di cui è stato eseguito il deployment.
La pianificazione dei pod di sistema non riesce nei cluster vuoti
Questo evento si verifica quando nessuno dei tuoi carichi di lavoro è in esecuzione in un cluster, con conseguente riduzione del cluster a zero nodi. I cluster Autopilot iniziano con zero nodi utilizzabili e scalano fino a zero nodi se non esegui nessuno dei tuoi carichi di lavoro nel cluster. Questo comportamento riduce al minimo lo spreco di risorse di calcolo nel cluster.
Quando un cluster riduce le dimensioni a zero nodi, i workload di sistema GKE non vengono pianificati e rimangono nello stato Pending. Si tratta di un comportamento previsto e non è richiesta alcuna azione. La volta successiva che esegui il deployment di un
caricamento di lavoro nel cluster, GKE eseguirà l'aumento di scala del cluster e i
pod di sistema in attesa verranno eseguiti su questi nodi.
Per verificare se i pod di sistema sono in attesa a causa di un cluster vuoto:
Controlla se il cluster ha nodi:
kubectl get nodesL'output è il seguente, il che indica che il cluster non ha nodi:
No resources foundControlla lo stato dei pod di sistema:
kubectl get pods --namespace=kube-systemL'output è simile al seguente:
NAME READY STATUS RESTARTS AGE antrea-controller-horizontal-autoscaler-6d97f7cf7c-ngfd2 0/1 Pending 0 9d egress-nat-controller-84bc985778-6jcwl 0/1 Pending 0 9d event-exporter-gke-5c5b457d58-7njv7 0/2 Pending 0 3d5h event-exporter-gke-6cd5c599c6-bn665 0/2 Pending 0 9d konnectivity-agent-694b68fb7f-gws8j 0/2 Pending 0 3d5h konnectivity-agent-7d659bf64d-lp4kt 0/2 Pending 0 9d konnectivity-agent-7d659bf64d-rkrw2 0/2 Pending 0 9d konnectivity-agent-autoscaler-5b6ff64fcd-wn7fw 0/1 Pending 0 9d konnectivity-agent-autoscaler-cc5bd5684-tgtwp 0/1 Pending 0 3d5h kube-dns-65ccc769cc-5q5q7 0/5 Pending 0 3d5h kube-dns-7f7cdb9b75-qkq4l 0/5 Pending 0 9d kube-dns-7f7cdb9b75-skrx4 0/5 Pending 0 9d kube-dns-autoscaler-6ffdbff798-vhvkg 0/1 Pending 0 9d kube-dns-autoscaler-8b7698c76-mgcx8 0/1 Pending 0 3d5h l7-default-backend-87b58b54c-x5q7f 0/1 Pending 0 9d metrics-server-v1.31.0-769c5b4896-t5jjr 0/1 Pending 0 9dControlla il motivo per cui i pod di sistema hanno lo stato
Pending:kubectl describe pod --namespace=kube-system SYSTEM_POD_NAMESostituisci
SYSTEM_POD_NAMEcon il nome di qualsiasi pod di sistema nell'output del comando precedente.L'output è simile al seguente:
... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 4m35s (x27935 over 3d5h) default-scheduler no nodes available to schedule pods ...Nell'output, il valore
no nodes available to schedule podsnel campoMessageper l'eventoFailedSchedulingindica che il pod di sistema non è stato pianificato perché il cluster è vuoto.
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 da un pod e poi copiarla utilizzando il comando kubectl cp.
Se in genere esegui l'utilità tcpdump da 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 rimuove la funzionalità NET_RAW per mitigare 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 tuo carico di lavoro richiede la funzionalità NET_RAW, puoi riattivarla:
Aggiungi la funzionalità
NET_RAWalla sezionesecurityContextdella specifica YAML del pod:securityContext: capabilities: add: - NET_RAWEsegui
tcpdumpda un pod:tcpdump port 53 -w packetcap.pcap tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytesUtilizza il comando
kubectl cpper copiarlo sulla tua macchina locale per ulteriori analisi:kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAMEUsa
kubectl execper eseguire il comandotcpdumpper eseguire l'acquisizione di pacchetti di rete e reindirizzare l'output:kubectl exec -it POD_NAME -- bash -c "tcpdump port 53 -w -" > packet-new.pcap