Risoluzione dei problemi dei cluster Autopilot

Questa pagina mostra come risolvere i problemi relativi ai cluster Google Kubernetes Engine (GKE) Autopilot.

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

Problemi relativi ai cluster

Impossibile creare un cluster: 0 nodi registrati

Il seguente problema 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:

  1. Controlla se l'account di servizio Compute Engine predefinito o l'account di servizio IAM personalizzato che vuoi utilizzare è disabilitato:

    gcloud iam service-accounts describe SERVICE_ACCOUNT

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

    Se l'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 l'account di servizio è disabilitato, abilitalo:

    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

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 fa lo scale down a zero nodi. Il componente metrics-server non può accettare la richiesta di eliminazione dello spazio dei nomi perché il componente non ha 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 a 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, fai lo scale up del carico di lavoro.

Problemi di scalabilità

Fare lo scale up del nodo non riuscito: 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 in modo efficace il debug dei problemi dei nodi. Se il logging delle porte seriali è disabilitato, Autopilot non può eseguire il provisioning dei nodi per l'esecuzione dei 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 un criterio dell'organizzazione che applichi il vincolo compute.disableSerialPortLogging. Il logging delle porte seriali può essere disabilitato anche a livello di progetto o di istanza di macchina virtuale (VM).

Per risolvere il problema:

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

Fare lo scale up del nodo non riuscito: risorse esaurite di GCE

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

  • Controlla gli eventi del pod:

    kubectl get events --for='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 a procedere nel seguente modo:

  • Eseguire il deployment del pod in un'altra regione o zona. Se il pod ha una limitazione di zona, ad esempio un selettore di topologia, rimuovi la limitazione, se possibile. Per le istruzioni, consulta Posizionare i pod GKE in zone specifiche.
  • Crea un cluster in un'altra regione e riprova a eseguire il deployment.
  • Prova a utilizzare un'altra classe di computing. Le classi di computing supportate da tipi di macchine Compute Engine più piccoli hanno maggiori probabilità di disporre di risorse. Ad esempio, il tipo di macchina predefinito per Autopilot ha la disponibilità più elevata. Per un elenco delle classi di computing e dei tipi di macchine corrispondenti, vedi Quando utilizzare classi di computing specifiche.
  • Se esegui carichi di lavoro GPU, la GPU richiesta potrebbe non essere disponibile nella località del nodo. Prova a eseguire il deployment del carico di lavoro in una località diversa o richiedi un altro tipo di GPU.

Per evitare problemi di scale up causati in futuro dalla disponibilità delle risorse, prendi in considerazione i seguenti approcci:

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 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:

Problemi relativi al carico di lavoro

Pod bloccati in 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à massima allocabile del nodo. Di conseguenza, il pod potrebbe ottenere lo stato Pending e rimanere non pianificato.

Per evitare questo problema, valuta le dimensioni dei carichi di lavoro di cui hai eseguito il deployment per assicurarti che rientrino nel numero massimo di richieste di risorse supportate per Autopilot.

Puoi anche provare a pianificare i DaemonSet prima di pianificare i normali pod con carico di lavoro.

Pod bloccati durante la terminazione o la creazione

Un problema noto causa il blocco dei pod in uno dei seguenti stati:

  • Terminating
  • CreateContainerError

Questo problema ha una piccola probabilità che si verifichi quando utilizzi pod con possibilità di burst in ambienti GKE che soddisfano tutte le condizioni seguenti:

  1. La versione GKE del nodo è 1.29.2-gke.1060000 o successiva
  2. Il pod utilizza una delle seguenti classi di computing:
    • La classe di computing per uso generico predefinita
    • La classe di computing Balanced
    • La classe di computing Scale-Out

Per limitare questo problema, abbiamo temporaneamente disabilitato il bursting nei cluster GKE Autopilot che sono stati creati o sottoposti ad upgrade alla versione 1.29.2-gke.1060000 e successive il 24 aprile 2024 o in una data successiva. I cluster che abilitavano il bursting prima del 24 aprile 2024 continuano a supportarlo.

Se i tuoi pod sono già bloccati nello stato Terminating o CreateContainerError, segui questi passaggi:

  1. Descrivi il pod bloccato:

    kubectl describe pod POD_NAME

    Sostituisci POD_NAME con il nome del pod bloccato.

    Se il pod è bloccato a causa di questo problema, il campo Events nell'output non mostrerà un evento che spiega lo stato Terminating o CreateContainerError, come nell'output di esempio seguente:

    # Fields omitted for readability
Containers:
  startup-script:
    State:          Waiting
      Reason:       CreateContainerError
    Last State:     Terminated
      Reason:       Unknown
      Exit Code:    255
      Started:      Sun, 14 Apr 2024 20:04:08 +0000
      Finished:     Sun, 14 Apr 2024 20:04:17 +0000
    Ready:          False
# Fields omitted for readability
Events:
  Type    Reason   Age                      From     Message
  ----    ------   ----                     ----     -------
  Normal  Pulling  2m49s (x12236 over 46h)  kubelet  Pulling image "gcr.io/google-containers/startup-script:v1"

  2. Svuota i nodi interessati seguendo i passaggi descritti nella sezione Prestazioni dei carichi di lavoro costantemente inaffidabili su un nodo specifico.

Per richiedere un'esenzione in modo da poter utilizzare il bursting nelle versioni GKE interessate o per disabilitare il bursting in un cluster che supporta ancora il bursting, contatta l'assistenza clienti Google Cloud.

Prestazioni dei carichi di lavoro costantemente inaffidabili su un nodo specifico

In GKE 1.24 e versioni successive, se i carichi di lavoro su un nodo specifico riscontrano costantemente interruzioni, arresti anomali o comportamenti simili inaffidabili, puoi segnalare a GKE il 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 esegue le seguenti operazioni:

  • Elimina 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 rimossi che sono gestiti da un controller, come un deployment o uno StatefulSet, su altri nodi.
  • Termina tutti i carichi di lavoro rimasti sul nodo e ripara o ricrea il nodo nel tempo.
  • Se utilizzi Autopilot, GKE si arresta e sostituisce immediatamente il nodo e ignora eventuali PodDisruptionBudget configurati.

La pianificazione dei pod nei 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 scalano fino a zero nodi se il cluster è vuoto per evitare di avere risorse di calcolo non utilizzate nel cluster. Il deployment di un carico di lavoro in un cluster con zero nodi attiva un evento di scale up.

Se riscontri questo, la modalità Autopilot funziona come previsto e non è necessaria alcuna azione da parte tua. Il deployment del carico di lavoro verrà eseguito come previsto dopo l'avvio dei nuovi nodi.

Verifica se i tuoi pod sono in attesa di nuovi nodi:

  1. Descrivi il 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 mostra che lo scale up del cluster da zero nodi al numero di nodi necessario per eseguire il carico di lavoro di cui è stato eseguito il deployment è in corso.

Passaggi successivi

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