Risoluzione dei problemi relativi ai cluster Autopilot

I problemi con i cluster Autopilot di Google Kubernetes Engine (GKE) possono influire sulla disponibilità e sull'efficienza operativa della tua applicazione. Questi problemi possono interrompere l'intero ciclo di vita delle tue applicazioni, dall'implementazione iniziale allo scaling sotto carico.

Utilizza questa pagina per diagnosticare e risolvere problemi comuni specifici dei cluster Autopilot. Trova indicazioni per la risoluzione dei problemi di creazione del cluster che impediscono il provisioning del cluster, problemi di scalabilità come gli errori out of resources e problemi specifici del workload, come errori di archiviazione temporanea o pod bloccati nello stato Pending.

Queste informazioni sono importanti per gli sviluppatori di applicazioni che devono assicurarsi che le loro applicazioni vengano implementate ed eseguite senza problemi, nonché per gli amministratori e gli operatori della piattaforma responsabili della salute generale e della gestione delle risorse dei cluster Autopilot. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Problemi relativi ai cluster

Impossibile creare un cluster: 0 nodi registrati

Il seguente problema si verifica quando tenti di creare un cluster Autopilot con un account di servizio IAM disattivato o privo delle autorizzazioni richieste. 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:

  1. Controlla se il service account Compute Engine predefinito o il account di servizio IAM personalizzato che vuoi utilizzare è disattivato:

    gcloud iam service-accounts describe SERVICE_ACCOUNT

    Sostituisci SERVICE_ACCOUNT con l'indirizzo email del account di servizio, ad esempio my-iam-account@my-first-project.iam.gserviceaccount.com.

    Se il account di servizio è disabilitato, l'output è simile al seguente:

    disabled: true
displayName: my-service-account
email: my-service-account@my-project.iam.gserviceaccount.com
...

  2. Se il account di servizio è disabilitato, abilitalo:

    gcloud iam service-accounts enable SERVICE_ACCOUNT

Se il account di servizio è abilitato e l'errore persiste, concedi al account di servizio le autorizzazioni minime richieste per GKE:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT" \
    --role roles/container.defaultNodeServiceAccount

Lo 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 che il cluster è stato ridotto 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 il problema, scala qualsiasi carico di lavoro per attivare la creazione di un nuovo nodo da parte di GKE. Quando il nodo è pronto, la richiesta di eliminazione dello spazio dei nomi viene completata automaticamente. Dopo che GKE elimina lo spazio dei nomi, ridimensiona di nuovo il workload.

Problemi di scalabilità

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 progettoGoogle Cloud . I cluster GKE Autopilot richiedono il logging della porta seriale per eseguire il debug in modo efficace dei problemi dei nodi. Se il logging della porta seriale è disabilitato, Autopilot non può eseguire il provisioning dei nodi per eseguire i workload.

Il messaggio di errore nel log eventi 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 disattivata a livello di organizzazione tramite una policy dell'organizzazione che applica il vincolo compute.disableSerialPortLogging. Il logging delle porte seriali può essere disattivato anche a livello di progetto o di istanza di macchina virtuale (VM).

Per risolvere il problema, segui questi passaggi:

  1. Chiedi all'amministratore delle policy dell'organizzazione Google Cloud di rimuovere il vincolo compute.disableSerialPortLogging nel progetto con il tuo cluster Autopilot.
  2. Se non hai un criterio dell'organizzazione che applica questo vincolo, prova ad attivare il logging della porta seriale nei metadati del progetto. Questa azione richiede l'autorizzazione IAM compute.projects.setCommonInstanceMetadata.

Scalabilità verticale del nodo non riuscita: Compute Engine ha esaurito le risorse

Il seguente problema si verifica quando i tuoi carichi di lavoro richiedono più risorse di quelle disponibili per l'utilizzo in quella regione o zona di Compute Engine. I tuoi Pod potrebbero rimanere nello stato Pending.

  • Controlla gli eventi del pod:

    kubectl events --for='pod/POD_NAME' --types=Warning

    Sostituisci RESOURCE_NAME con il nome della risorsa Kubernetes in attesa. Ad esempio pod/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 zona diversa. Se il tuo pod ha una limitazione zonale, ad esempio un selettore di topologia, rimuovila se puoi. Per istruzioni, consulta Posiziona i pod GKE in zone specifiche.
  • Crea un cluster in una regione diversa e riprova il deployment.
  • Prova a utilizzare una classe di calcolo diversa. Le classi di calcolo supportate da 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 posizione del nodo. Prova a eseguire il deployment del workload in una località diversa o a richiedere un tipo di GPU diverso.

Per evitare problemi di scalabilità causati dalla disponibilità delle risorse in futuro, valuta i seguenti approcci:

Impossibile fare lo scale up dei nodi: risorse di zona 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:

Workload pianificato su serie di macchine precedenti o bloccato nello stato Pending a causa dell'incompatibilità dello spazio di archiviazione

Questo problema si verifica quando un carico di lavoro stateful utilizza un tipo di volume Persistent Disk precedente, ad esempio volumi Standard Persistent Disk (pd-standard) o SSD Persistent Disk (pd-ssd). Questi tipi di volumi non sono compatibili con le serie di macchine più recenti, come C3 o E4.

Questo problema si manifesta in due modi:

  • Sintomo 1: un workload che prevedi di eseguire su una serie di macchine per uso generico più recente (ad esempio C3) viene pianificato automaticamente su un nodo E2.
  • Sintomo 2: un pod che richiede esplicitamente una serie di macchine più recente (ad esempio utilizzando i campi nodeSelector o una ComputeClass personalizzata) rimane bloccato nello stato Pending.

Causa principale

GKE Autopilot applica la compatibilità tra i tipi di archiviazione richiesti e la serie di macchine dei nodi. Le serie di macchine più recenti come C3 ed E4 richiedono l'archiviazione Google Cloud Hyperdisk (ad esempio il tipo di disco hyperdisk-balanced). Queste serie di macchine non supportano i tipi di volumi di Persistent Disk precedenti, come i volumi di Standard Persistent Disk (pd-standard) o SSD Persistent Disk (pd-ssd).

  • Se non specifichi una serie di macchine, GKE Autopilot pianifica automaticamente il workload su un nodo E2 perché i nodi E2 supportano questi tipi di volumi Persistent Disk. Il carico di lavoro torna automaticamente all'hardware più recente predefinito.
  • Se richiedi esplicitamente una serie di macchine più recente (come C3 o E4), ma colleghi un tipo di volume Persistent Disk precedente, ad esempio volumi Standard Persistent Disk (pd-standard) o SSD Persistent Disk (pd-ssd), GKE Autopilot non può soddisfare entrambi i requisiti. Il pod rimane bloccato nello stato Pending.

Verifica

Per verificare se il tuo workload è interessato da questo vincolo di compatibilità, segui questi passaggi:

  1. Controlla la configurazione del volume del pod per verificare se utilizza un tipo di volume Persistent Disk precedente, ad esempio volumi Standard Persistent Disk (pd-standard) o SSD Persistent Disk (pd-ssd).

  2. Se il pod è bloccato nello stato Pending, controlla i log di visibilità del gestore della scalabilità automatica dei cluster. Cerca log di valutazione del provisioning automatico dei nodi (NAP) simili ai seguenti:

    NAP: injected node groups for requirements...

  3. Esamina il messaggio di log per l'elenco families="...". Controlla se nell'elenco mancano famiglie di macchine più recenti (ad esempio identificatori e4 o c3). Gli identificatori mancanti indicano che GKE ha filtrato queste famiglie durante la pianificazione a causa del requisito di archiviazione. L'identificatore e4 viene utilizzato nei log interni per la serie di macchine E4.

Risoluzione

Per risolvere il problema, esegui una delle seguenti azioni:

  • Utilizza l'archiviazione Hyperdisk: aggiorna la definizione di StorageClass o del volume per utilizzare l'archiviazione Google Cloud Hyperdisk (ad esempio il tipo di disco hyperdisk-balanced), compatibile con le serie di macchine più recenti.
  • Consenti la pianificazione su serie precedenti: se devi utilizzare tipi di volumi Persistent Disk precedenti (ad esempio volumi Persistent Disk standard (pd-standard) o Persistent Disk SSD (pd-ssd)), rimuovi eventuali richieste esplicite per serie di macchine più recenti (ad esempio campi nodeSelector o ComputeClass personalizzate). La rimozione di queste richieste consente a GKE Autopilot di pianificare il pod su nodi compatibili come E2.

Problemi relativi al workload

Workload bloccati con errore di spazio di archiviazione temporaneo

GKE non creerà pod se le richieste di archiviazione temporanea dei pod superano il massimo di 10 GiB di Autopilot in GKE versione 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 del workload, ad esempio replicaset o daemonset. Per un elenco dei tipi di controller, vedi Gestione dei carichi di lavoro.
  • CONTROLLER_NAME: il nome del workload bloccato.

Se il pod non viene creato perché la richiesta di spazio di archiviazione temporaneo supera il 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 l'archiviazione temporanea totale richiesta dai container del workload e dai container inseriti dagli webhook sia inferiore o uguale al massimo consentito. Per saperne di più sul valore massimo, consulta Richieste di risorse in Autopilot per la configurazione del workload.

Pod bloccati nello stato In attesa

Un pod potrebbe bloccarsi 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 l'assegnazione dello stato Pending al pod, che rimarrà non pianificato.

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 regolari.

Prestazioni del workload costantemente inaffidabili su un nodo specifico

In GKE 1.24 e versioni successive, se i tuoi carichi di lavoro su un nodo specifico subiscono costantemente interruzioni, arresti anomali o un comportamento inaffidabile simile, puoi comunicare a GKE il nodo problematico 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 workload esistenti dal nodo e interrompe la pianificazione dei workload su questo nodo.
  • Ricrea automaticamente tutti i workload eliminati 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 tutti i PodDisruptionBudget configurati.

La pianificazione dei pod richiede più tempo del previsto sui cluster vuoti

Questo evento si verifica quando esegui il deployment di un workload in un cluster Autopilot che non ha altri workload. I cluster Autopilot iniziano con zero nodi utilizzabili e vengono scalati a zero nodi se il cluster è vuoto per evitare di avere risorse di calcolo inutilizzate nel cluster. Il deployment di un workload in un cluster con zero nodi attiva un evento di scalabilità verso l'alto.

Se si verifica questo problema, Autopilot funziona come previsto e non è necessaria alcuna azione. Il deployment del workload verrà eseguito come previsto dopo l'avvio dei nuovi nodi.

Controlla se i pod sono in attesa di nuovi nodi:

  1. Descrivi il tuo pod in attesa:

    kubectl describe pod POD_NAME

    Sostituisci POD_NAME con il nome del pod in attesa.

  2. 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 indica che il cluster sta scalando da zero nodi al numero di nodi necessari per eseguire il workload di cui è stato eseguito il deployment.

Impossibile pianificare i pod di sistema sui cluster vuoti

Questo evento si verifica quando nessuno dei tuoi workload è in esecuzione in un cluster, il che comporta lo scale down del cluster a zero nodi. I cluster Autopilot iniziano con zero nodi utilizzabili e fare lo scale down a zero nodi se non esegui alcuno dei tuoi carichi di lavoro nel cluster. Questo comportamento riduce al minimo lo spreco di risorse di calcolo nel cluster.

Quando un cluster viene ridotto a zero nodi, i workload di sistema GKE non vengono pianificati e rimangono nello stato Pending. Si tratta di un comportamento previsto e non è necessaria alcuna azione. La volta successiva che esegui il deployment di un carico di lavoro nel cluster, GKE aumenterà le dimensioni 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:

  1. Controlla se il cluster ha nodi:

    kubectl get nodes

    L'output è il seguente, che indica che il cluster ha zero nodi:

    No resources found

  2. Controlla lo stato dei pod di sistema:

    kubectl get pods --namespace=kube-system

    L'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          9d

  3. Controlla il motivo per cui i pod di sistema hanno lo stato Pending:

    kubectl describe pod --namespace=kube-system SYSTEM_POD_NAME

    Sostituisci SYSTEM_POD_NAME con il nome di un pod di sistema dall'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 pods nel campo Message per l'evento FailedScheduling indica che il pod di sistema non è stato pianificato perché il cluster è vuoto.

L'accesso ai nodi sottostanti è vietato in un cluster GKE Autopilot. Pertanto, è necessario eseguire l'utilità tcpdump dall'interno di 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)

Ciò accade perché GKE Autopilot, per impostazione predefinita, applica un contesto di sicurezza a tutti i pod 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:
        # This section drops NET_RAW to mitigate security vulnerabilities
        drop:
        - NET_RAW

Come soluzione, se il tuo workload richiede la funzionalità NET_RAW, puoi riattivarla:

  1. Aggiungi la funzionalità NET_RAW alla sezione securityContext della specifica YAML del pod:

    securityContext:
  capabilities:
    add:
    - NET_RAW

  2. 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

  3. Utilizza il comando kubectl cp per copiarlo sulla tua macchina locale per un'analisi più approfondita:

    kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAME

  4. Utilizza kubectl exec per eseguire il comando tcpdump per 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

Impossibile eseguire i pod su un nodo a causa dell'errore NRI RunPodSandbox

In rari casi, un nodo Autopilot nelle classi di calcolo predefinite, bilanciate, di scalabilità orizzontale, autopilot e autopilot-spot può entrare in uno stato in cui i pod di sistema, come anetd, e potenzialmente i pod utente assegnati al nodo, non riescono a passare allo stato di esecuzione. Quando anetd non può passare a uno stato di esecuzione, la rete dei pod è parzialmente o completamente interrotta sul nodo. Questo stato di errore viene attivato solo durante determinati upgrade del control plane del cluster.

Se noti il problema, puoi mitigarne gli effetti su un determinato nodo seguendo la procedura per mitigare le prestazioni inaffidabili del workload su un nodo specifico.

Per evitare che il problema si ripresenti, esegui l'upgrade manuale del cluster a una delle seguenti versioni patch di GKE:

  • 1.35: tutte le versioni patch
  • 1.34: 1.34.1-gke.3899000 o versioni successive
  • 1.33: 1.33.5-gke.2392000 o versioni successive

Se sospetti che un nodo si trovi in questo stato di errore, puoi confermarlo procedendo nel seguente modo:

  1. Trova il pod efficiency-daemon in esecuzione sul nodo sospetto:

    DAEMON_POD_NAME=$(kubectl get pods \
  --namespace kube-system \
  --selector k8s-app=efficiency-daemon \
  --field-selector spec.nodeName=NODE_NAME \
  --output custom-columns=":metadata.name" \
  --no-headers)
echo $DAEMON_POD_NAME

    Se sul nodo non è presente alcun pod efficiency-daemon, il nodo non è interessato da questo particolare problema.

  2. Controlla la presenza di errori specifici nel pod efficiency-daemon:

    kubectl logs -n kube-system $DAEMON_POD_NAME | grep "connect: operation not permitted" | wc -l

    Se l'output è maggiore di 10, è molto probabile che il nodo sia interessato da questo problema.

Se osservi continuamente il seguente messaggio di errore negli eventi del pod per un pod assegnato al nodo, è un segno che il nodo è interessato da questo problema: Failed to create pod sandbox: rpc error: code = Unknown desc = NRI RunPodSandbox failed: rpc error: code = Unknown desc = internal error: reconciliation failed.

Passaggi successivi