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 events --for='pod/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 est soumis à une restriction zonale telle qu'un sélecteur de topologie, supprimez-la si possible. Pour obtenir des instructions, consultez la section Placer les pods GKE dans des zones spécifiques.
- Créez un cluster dans une autre région et relancez le déploiement.
- Essayez d'utiliser une autre classe de calcul. Les classes de calcul qui s'appuient sur des types de machines Compute Engine plus petits sont plus susceptibles 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 à l'emplacement de votre 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 PriorityClasses de Kubernetes pour provisionner de manière cohérente une capacité de calcul supplémentaire dans votre cluster. Pour en savoir plus, consultez la page Provisionner une capacité de calcul supplémentaire pour un scaling rapide des pods.
- Utilisez des réservations de capacité 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
Charges de travail bloquées avec une erreur de stockage éphémère
GKE ne crée pas de pods si vos requêtes de stockage éphémère de pods dépassent le maximum Autopilot de 10 Gio dans GKE 1.28.6-gke.1317000 et versions ultérieures.
Pour diagnostiquer ce problème, décrivez le contrôleur de charge de travail, tel que le déploiement ou la tâche :
kubectl describe CONTROLLER_TYPE/CONTROLLER_NAME
Remplacez les éléments suivants :
CONTROLLER_TYPE
: type de contrôleur de charge de travail, tel quereplicaset
oudaemonset
. Pour obtenir la liste des types de contrôleurs, consultez la section Gestion des charges de travail.CONTROLLER_NAME
: nom de la charge de travail bloquée.
Si le pod n'est pas créé parce que la demande de stockage éphémère dépasse la valeur maximale, le résultat ressemble à ce qui suit :
# 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'."]}
Pour résoudre ce problème, mettez à jour vos demandes de stockage éphémère de sorte que la quantité de stockage éphémère totale demandée par les conteneurs de charge de travail et les conteneurs injectés par des webhooks soit inférieure ou égale au maximum autorisé. Pour en savoir plus sur la valeur maximale, consultez la section Demandes de ressources dans Autopilot pour la configuration de la charge 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.
Pods bloqués lors de l'arrêt ou de la création
Un problème connu entraîne parfois le blocage des pods dans l'un des états suivants :
Terminating
CreateContainerError
Ce problème peut survenir lorsque vous utilisez des pods extensibles dans des environnements GKE qui répondent à toutes les conditions suivantes :
- Vos nœuds exécutent les versions de GKE de la version 1.29.2-gke.1060000 jusqu'à la version 1.30.2-gke.1394000, non incluse.
- Votre pod utilise l'une des classes de calcul suivantes :
- Classe de calcul à usage général par défaut
- Classe de calcul
Balanced
- Classe de calcul
Scale-Out
Pour résoudre ce problème, mettez à niveau votre plan de contrôle vers GKE version 1.30.2-gke.1394000 ou ultérieure. Les pods déjà bloqués dans l'état Terminating
ou CreateContainerError
seront déployés correctement après que GKE recrée les pods sur les nœuds qui exécutent une version corrigée.
Lorsque vous mettez à niveau un cluster Autopilot, GKE met à niveau les nœuds de calcul pour qu'ils correspondent à la version du plan de contrôle au fil du temps. Un redémarrage du plan de contrôle est nécessaire pour activer l'utilisation intensive et doit se produire une fois que tous les nœuds exécutent une version compatible. Le plan de contrôle redémarre automatiquement environ une fois par semaine lors d'opérations telles que le scaling, les mises à niveau ou la maintenance.
Pour déclencher manuellement un redémarrage du plan de contrôle, procédez comme suit :
Vérifiez si tous vos nœuds exécutent la version 1.30.2-gke.1349000 ou ultérieure :
kubectl get nodes
Le résultat ressemble à ce qui suit :
NAME STATUS ROLES AGE VERSION gk3-ap-cluster-1-default-pool-18092e49-mllk Ready <none> 4m26s v1.30.2-gke.1349000
Tous les nœuds de la sortie doivent afficher la version requise ou une version ultérieure.
Démarrez manuellement une mise à niveau du plan de contrôle vers la même version que celle utilisée par le cluster. Pour obtenir des instructions, consultez la page Mettre à jour manuellement le plan de contrôle.
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 programmation 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 n'a 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 ne comportant aucun 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
indique que votre cluster effectue un scaling à partir de zéro nœud vers autant de nœuds nécessaires pour exécuter la charge de travail déployée.
Erreur liée à l'autorisation lors de la tentative d'exécution de tcpdump à partir d'un pod dans GKE Autopilot
L'accès aux nœuds sous-jacents est interdit dans un cluster GKE Autopilot. Par conséquent, il est nécessaire d'exécuter l'utilitaire tcpdump
depuis un pod, puis de le copier à l'aide de la commande "kubectl cp".
Si vous exécutez généralement l'utilitaire tcpdump à partir d'un pod d'un cluster GKE Autopilot, l'erreur suivante peut s'afficher :
tcpdump: eth0: You don't have permission to perform this capture on that device
(socket: Operation not permitted)
En effet, GKE Autopilot, par défaut, applique un contexte de sécurité à tous les pods qui supprime la capacité NET_RAW
pour atténuer les failles potentielles. Exemple :
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
Pour remédier à ce problème, si votre charge de travail nécessite la fonctionnalité NET_RAW
, vous pouvez la réactiver comme suit :
Ajoutez la fonctionnalité
NET_RAW
à la sectionsecurityContext
de la spécification YAML de votre pod :securityContext: capabilities: add: - NET_RAW
Exécutez
tcpdump
à partir d'un pod :tcpdump port 53 -w packetcap.pcap tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
Utilisez la commande
kubectl cp
pour effectuer une copie sur votre ordinateur local afin de procéder à une analyse plus approfondie :kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAME
Utilisez
kubectl exec
pour exécuter la commandetcpdump
afin d'effectuer une capture de paquets réseau et de rediriger la sortie :kubectl exec -it POD_NAME -- bash -c "tcpdump port 53 -w -" > packet-new.pcap