Résoudre les problèmes liés aux clusters Autopilot

Cette page explique comment résoudre les problèmes liés aux clusters Autopilot de Google Kubernetes Engine (GKE).

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.

Problèmes liés aux clusters

Impossible de créer un cluster : 0 nœud enregistré

Le problème suivant se produit lorsque vous essayez de créer un cluster Autopilot avec un compte de service IAM désactivé ou ne disposant pas des autorisations requises. La création du cluster échoue avec le message d'erreur suivant :

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

Pour identifier le problème, procédez comme suit :

Vérifiez si le compte de service Compute Engine par défaut ou le compte de service IAM personnalisé que vous souhaitez utiliser est désactivé :
```
gcloud iam service-accounts describe SERVICE_ACCOUNT
```
Remplacez SERVICE_ACCOUNT par l'adresse e-mail du compte de service (par exemple, my-iam-account@my-first-project.iam.gserviceaccount.com).

Si le compte de service est désactivé, le résultat ressemble à ce qui suit :
```
disabled: true
displayName: my-service-account
email: my-service-account@my-project.iam.gserviceaccount.com
...
```
Si le compte de service est désactivé, activez-le :
```
gcloud iam service-accounts enable SERVICE_ACCOUNT
```

Si le compte de service est activé et que l'erreur persiste, accordez-lui les autorisations minimales requises pour GKE :

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

Espace de noms bloqué à l'état de fin lorsque le cluster contient 0 nœud

Le problème suivant se produit lorsque vous supprimez un espace de noms dans un cluster après son scaling à la baisse à 0 nœud. Le composant metrics-server ne peut pas accepter la demande de suppression d'espace de noms, car il ne possède aucune instance répliquée.

Pour diagnostiquer ce problème, exécutez la commande suivante :

kubectl describe ns/NAMESPACE_NAME

Remplacez NAMESPACE_NAME par le nom de l'espace de noms.

Le résultat est le suivant :

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

Pour résoudre ce problème, effectuez le scaling à la hausse de n'importe quelle charge de travail afin de déclencher la création d'un nœud par GKE. Lorsque le nœud est prêt, la demande de suppression d'espace de noms s'arrête automatiquement. Une fois que GKE a supprimé l'espace de noms, effectuez le scaling à la baisse de la charge de travail.

Problèmes de scaling

Échec du scaling à la hausse du nœud : le pod risque d'être planifié

Le problème suivant se produit lorsque la journalisation du port série est désactivée dans votre projet Google Cloud. Les clusters GKE Autopilot nécessitent la journalisation du port série pour déboguer efficacement les problèmes de nœuds. Si la journalisation du port série est désactivée, Autopilot ne peut pas provisionner les nœuds pour exécuter vos charges de travail.

Le message d'erreur dans votre journal des événements Kubernetes est semblable à celui-ci :

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 journalisation du port série peut être désactivée au niveau de l'organisation via une règle d'administration qui applique la contrainte compute.disableSerialPortLogging. La journalisation du port série peut également être désactivée au niveau du projet ou de l'instance de machine virtuelle (VM).

Pour résoudre ce problème, procédez comme suit :

Demandez à votre administrateur des règles d'administration Google Cloud de supprimer la contrainte compute.disableSerialPortLogging du projet avec votre cluster Autopilot.
Si aucune règle d'administration n'applique cette contrainte, essayez d'activer la journalisation du port série dans vos métadonnées de projet. Cette action nécessite l'autorisation IAM compute.projects.setCommonInstanceMetadata.

Échec du scaling à la hausse du nœud : GCE manque de ressources

Le problème suivant se produit lorsque vos charges de travail demandent plus de ressources que celles disponibles dans cette région ou cette zone Compute Engine. Vos pods peuvent rester à l'état Pending.

Vérifiez les événements du pod :

kubectl get events --for='POD_NAME' --types=Warning

Remplacez RESOURCE_NAME par le nom de la ressource Kubernetes en attente. Par exemple, pod/example-pod.

Le résultat ressemble à ce qui suit :

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.

Pour résoudre ce problème, procédez comme suit :

Déployez le pod dans une région ou une zone différente. Si votre pod présente une restriction zonale telle qu'un sélecteur de topologie, supprimez la restriction si possible. Pour obtenir des instructions, consultez la page Placer les pods GKE dans des zones spécifiques.
Créez un cluster dans une autre région, puis relancez le déploiement.
Essayez d'utiliser une autre classe de calcul. Les classes Compute qui s'appuient sur des types de machines Compute Engine plus petits ont plus de chances de disposer de ressources disponibles. Par exemple, le type de machine par défaut pour Autopilot offre la plus haute disponibilité. Pour obtenir la liste des classes de calcul et des types de machines correspondants, consultez la section Quand utiliser des classes de calcul spécifiques.
Si vous exécutez des charges de travail GPU, le GPU demandé peut ne pas être disponible dans votre emplacement de nœud. Essayez de déployer votre charge de travail dans un autre emplacement ou de demander un autre type de GPU.

Pour éviter les problèmes de scaling à la hausse causés par la disponibilité des ressources à l'avenir, envisagez les approches suivantes :

Utilisez les PriorityClass de Kubernetes pour provisionner une capacité de calcul supplémentaire de manière cohérente dans votre cluster. Pour en savoir plus, consultez la page Provisionner une capacité de calcul supplémentaire pour le scaling rapide de pods.
Utilisez les réservations de capacité de Compute Engine avec les classes de calcul Performance ou Accelerator. Pour en savoir plus, consultez la section Consommer des ressources zonales réservées.

Échec du scaling à la hausse des nœuds : ressources zonales de pod dépassées

Le problème suivant se produit lorsqu'Autopilot ne provisionne pas de nouveaux nœuds pour un pod dans une zone spécifique, car cela enfreindrait les limites de ressources.

Le message d'erreur dans vos journaux est semblable à celui-ci :

    "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              ...

Cette erreur fait référence à un événement noScaleUp, dans lequel le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod de la zone.

Si vous rencontrez cette erreur, vérifiez les points suivants :

Vos pods disposent de suffisamment de ressources mémoire et processeur.
La plage CIDR de l'adresse IP du pod est suffisamment étendue pour contenir la taille de cluster maximale attendue.

Problèmes liés aux charges de travail

Pods bloqués à l'état "Pending"

Un pod peut rester bloqué à l'état Pending dans le cas où vous sélectionnez un nœud spécifique à utiliser pour le pod, mais la somme des demandes de ressources dans le pod et dans les objets DaemonSet devant être exécutés sur le nœud dépasse la capacité maximale pouvant être allouée au nœud : Il se peut alors que votre pod affiche l'état Pending et ne soit pas planifié.

Pour éviter ce problème, évaluez les tailles de vos charges de travail déployées afin de vous assurer qu'elles correspondent aux demandes de ressources maximales autorisées pour Autopilot.

Vous pouvez également essayer de planifier vos DaemonSets avant de programmer vos pods de charge de travail standards.

Performances des charges de travail systématiquement peu fiables sur un nœud spécifique

Dans la version 1.24 ou ultérieure de GKE, si vos charges de travail sur un nœud spécifique subissent systématiquement des perturbations, des plantages ou un comportement peu fiable similaire, vous pouvez signaler le nœud problématique à GKE en l'ordonnançant à l'aide de la commande suivante :

kubectl drain NODE_NAME --ignore-daemonsets

Remplacez NODE_NAME par le nom du nœud problématique. Vous pouvez trouver le nom du nœud en exécutant la commande kubectl get nodes.

GKE effectue les opérations suivantes :

Il supprime les charges de travail existantes du nœud et arrête la planification des charges de travail sur ce nœud.
Il recrée automatiquement toutes les charges de travail évincées qui sont gérées par un contrôleur, tel qu'un objet Deployment ou StatefulSet, sur d'autres nœuds.
Il arrête toutes les charges de travail qui restent sur le nœud et répare ou recrée le nœud au fil du temps.
Si vous utilisez Autopilot, GKE s'arrête et remplace le nœud immédiatement et ignore tous les PodDisruptionBudgets configurés.

La planification des pods prend plus de temps que prévu sur des clusters vides

Cet événement se produit lorsque vous déployez une charge de travail sur un cluster Autopilot qui ne comporte aucune autre charge de travail. Les clusters Autopilot démarrent avec zéro nœud utilisable et le scaling à zéro nœud si le cluster est vide pour éviter d'avoir des ressources de calcul non utilisées dans le cluster. Le déploiement d'une charge de travail dans un cluster comportant zéro nœud déclenche un événement de scaling à la hausse.

Si vous rencontrez ce problème, Autopilot fonctionne comme prévu et aucune action n'est nécessaire. Votre charge de travail sera déployée comme prévu après le démarrage des nouveaux nœuds.

Vérifiez si vos pods attendent de nouveaux nœuds :

Décrivez votre pod en attente :
```
kubectl describe pod POD_NAME
```
Remplacez POD_NAME par le nom de votre pod en attente.

Vérifiez la section Events du résultat. Si le pod attend de nouveaux nœuds, le résultat ressemble à ce qui suit :

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'événement TriggeredScaleUp montre que votre cluster effectue un scaling de zéro nœud à autant de nœuds que nécessaire pour exécuter votre charge de travail déployée.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.