Cette page explique comment diagnostiquer et résoudre les problèmes qui empêchent l'autoscaler de cluster de réduire vos nœuds Google Kubernetes Engine (GKE).
Cette page s'adresse aux développeurs d'applications qui souhaitent résoudre une situation inattendue ou négative avec leur application ou leur service, ainsi qu'aux administrateurs et opérateurs de plate-forme qui souhaitent éviter toute interruption de la livraison de produits et de services.
Comprendre quand l'autoscaler de cluster réduit vos nœuds
Avant de procéder au dépannage, il peut être utile de comprendre quand l'autoscaler de cluster tente de réduire la capacité de vos nœuds. Il est possible que l'autoscaler de cluster n'ait pas réduit la capacité, car cela n'était pas nécessaire.
L'autoscaler de cluster détermine si un nœud est sous-utilisé et éligible à une réduction de la capacité en calculant un facteur d'utilisation. Le facteur d'utilisation est calculé en divisant le vCPU et la mémoire demandés par les pods sur le nœud par le vCPU et la mémoire allouables sur le nœud.
Toutes les 10 secondes, l'autoscaler de cluster vérifie le facteur d'utilisation de vos nœuds pour voir s'il est inférieur au seuil requis. Si vous utilisez un profil d'autoscaling balanced, le seuil de facteur d'utilisation est de 0,5. Si vous utilisez le profil optimize-utilization, le facteur d'utilisation varie. Lorsque le facteur d'utilisation est inférieur au seuil requis pour le vCPU et la mémoire, l'autoscaler de cluster considère que le nœud est sous-utilisé.
Lorsqu'un nœud est sous-utilisé, l'autoscaler de cluster le marque pour suppression et le surveille pendant les 10 minutes suivantes afin de s'assurer que le facteur d'utilisation reste inférieur au seuil requis. Si le nœud est toujours sous-utilisé au bout de 10 minutes, l'autoscaler de cluster doit le supprimer.
Exemple: calcul du facteur d'utilisation
Vous disposez d'un cluster avec l'autoscaler de cluster activé et vous utilisez le profil d'autoscaling balanced. Un nœud de ce cluster est provisionné avec le type de machine e2-standard-4, qui offre quatre vCPU et 16 Go de mémoire. Un pod sur ce nœud demande 0, 5 vCPU et 10 Go de mémoire. L'autoscaler de cluster calcule donc les facteurs d'utilisation suivants:
- Facteur d'utilisation des vCPU: 0,5 vCPU / 4 vCPU = 0,125
- Facteur d'utilisation de la mémoire: 10 Go / 16 Go = 0,625
Dans ce scénario, l'autoscaler de cluster ne considère pas ce nœud comme sous-utilisé, car le facteur d'utilisation de la mémoire (0,625) dépasse le seuil de 0,5. Même si l'utilisation du processeur virtuel est faible, l'utilisation plus élevée de la mémoire empêche la réduction de la capacité pour s'assurer que suffisamment de ressources restent disponibles pour la charge de travail du pod.
Vérifier si le problème est dû à une limitation
Si vous observez un cluster dont l'utilisation est faible pendant plus de 10 minutes et qu'il n'effectue pas de scaling à la baisse, assurez-vous que votre problème n'est pas dû à l'une des limites de l'autoscaler de cluster.
Afficher les erreurs
Si votre problème n'est pas dû à une limitation, vous pouvez souvent en diagnostiquer la cause en consultant les messages d'erreur:
Si vous avez déjà reçu un message d'erreur, consultez le tableau des messages d'erreur pour obtenir des conseils sur la résolution de l'erreur.
Si vous n'avez pas encore reçu de message, utilisez l'une des options suivantes:
- Problèmes datant de moins de 72 heures: affichez les notifications d'erreur dans la console Google Cloud.
- Problèmes datant de plus de 72 heures: afficher les erreurs dans les événements de Cloud Logging
Afficher les erreurs dans les notifications
Si le problème que vous avez observé s'est produit il y a moins de 72 heures, consultez les notifications d'erreur dans la console Google Cloud. Ces notifications fournissent des informations précieuses sur les raisons pour lesquelles l'autoscaler de cluster n'a pas effectué de scaling à la baisse, et proposent des conseils pour résoudre l'erreur et afficher les journaux pertinents pour une enquête plus approfondie.
Pour afficher les notifications dans la console Google Cloud, procédez comme suit:
Dans Cloud Console, accédez à la page des clusters Kubernetes.
Consultez la colonne Notifications. Les notifications suivantes sont associées à des problèmes de scaling à la baisse :
Can't scale down nodesScale down blocked by pod
Cliquez sur la notification concernée pour afficher un volet contenant des informations sur la cause du problème et les actions recommandées pour le résoudre.
Facultatif: Pour afficher les journaux de cet événement, cliquez sur Journaux. Cette action vous redirige vers l'explorateur de journaux avec une requête préremplie pour vous aider à enquêter plus en détail sur l'événement de mise à l'échelle. Pour en savoir plus sur le fonctionnement des événements de scaling à la baisse, consultez la section Afficher les événements d'autoscaler de cluster.
Si le problème persiste après avoir lu les conseils de la notification, consultez les tables des messages d'erreur pour obtenir de l'aide.
Afficher les erreurs dans les événements
Si le problème que vous avez observé s'est produit il y a plus de 72 heures, consultez les événements dans Cloud Logging. En cas d'erreur, celle-ci est souvent enregistrée dans un événement.
Pour afficher les journaux de l'autoscaler de cluster dans la console Google Cloud, procédez comme suit:
Dans Cloud Console, accédez à la page des clusters Kubernetes.
Sélectionnez le nom du cluster que vous souhaitez examiner pour afficher la page Détails du cluster.
Sur la page Détails du cluster, cliquez sur l'onglet Journaux.
Dans l'onglet Journaux, cliquez sur l'onglet Journaux de l'autoscaler pour afficher les journaux.
Facultatif : Pour appliquer des filtres plus avancés afin d'affiner les résultats, cliquez sur le bouton situé à droite de la page pour afficher les journaux dans l'explorateur de journaux.
Pour en savoir plus sur le fonctionnement des événements de scaling à la baisse, consultez Afficher les événements d'autoscaler de cluster. Pour découvrir comment utiliser Cloud Logging, consultez l'exemple de dépannage suivant.
Exemple: Résoudre un problème datant de plus de 72 heures
L'exemple suivant montre comment vous pouvez examiner et résoudre un problème de cluster qui ne diminue pas de taille.
Scénario :
Il y a une semaine, vous avez consulté le tableau de bord GKE Enterprise et vous avez remarqué que votre cluster n'a utilisé que 10% de son processeur et de sa mémoire. Malgré cette faible utilisation, l'autoscaler de cluster n'a pas supprimé le nœud comme prévu. Lorsque vous consultez le tableau de bord, le problème semble avoir été résolu, mais vous décidez de découvrir ce qui s'est passé pour éviter que cela ne se reproduise.
Investigation :
- Comme le problème s'est produit il y a plus de 72 heures, vous examinez le problème à l'aide de Cloud Logging au lieu de consulter les messages de notification.
- Dans Cloud Logging, vous trouverez les détails de journalisation des événements de l'autoscaler de cluster, comme décrit dans Afficher les erreurs dans les événements.
- Vous recherchez des événements
scaleDowncontenant les nœuds appartenant au cluster que vous étudiez dans le champnodesToBeRemoved. Vous pouvez filtrer les entrées de journal, y compris en fonction d'une valeur de champ JSON particulière. Pour en savoir plus, consultez la page Requêtes de journaux avancées. - Vous ne trouvez aucun événement
scaleDown. Toutefois, si vous avez trouvé un événementscaleDown, vous pouvez rechercher un événementeventResultcontenant la valeureventIdassociée. Vous pouvez ensuite rechercher une erreur dans le champerrorMsg. Vous décidez de poursuivre votre enquête en recherchant les événements
noScaleDownqui contiennent le nœud que vous étudiez dans le champ "Nœuds".Vous trouvez un événement
noScaleDownqui contient un motif pour lequel votre nœud n'effectue pas de scaling à la baisse. L'ID du message est"no.scale.down.node.pod.not.backed.by.controller", et il n'existe qu'un seul paramètre:"test-single-pod".
Solution :
Vous consultez le tableau des messages d'erreur et vous constatez que ce message signifie que le pod bloque le scaling à la baisse, car il n'est pas appuyé par un contrôleur. Vous découvrez qu'une solution consiste à ajouter une annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" au pod. Vous examinez test-single-pod et constatez qu'un collègue a ajouté l'annotation. Après avoir appliqué l'annotation, l'autoscaler de cluster a effectué correctement le scaling à la baisse du cluster. Vous décidez d'ajouter l'annotation à tous les autres pods où cela est possible pour éviter que le problème ne se reproduise.
Résoudre les erreurs de scaling à la baisse
Une fois que vous avez identifié l'erreur, utilisez les tableaux suivants pour comprendre sa cause et la résoudre.
Erreurs liées aux événements scaleDown
Les messages d'erreur concernant les événements scaleDown se trouvent dans l'événement eventResult correspondant, dans le champ resultInfo.results[].errorMsg.
| Message d'événement | Détails | Paramètre | Atténuation |
|---|---|---|---|
"scale.down.error.failed.to.mark.to.be.deleted" |
Un nœud n'a pas pu être marqué pour suppression. | Nom du nœud défaillant. | Ce message devrait être temporaire. Si le problème persiste, contactez l'assistance Cloud Customer Care pour une analyse approfondie. |
"scale.down.error.failed.to.evict.pods" |
L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car certains des pods ne pouvaient pas être évincés d'un nœud. | Nom du nœud défaillant. | Examinez le PodDisruptionBudget du pod et assurez-vous que les règles autorisent l'éviction des instances répliquées d'applications lorsque cela est acceptable. Pour en savoir plus, consultez la section Spécifier un budget d'interruption pour votre application dans la documentation Kubernetes. |
"scale.down.error.failed.to.delete.node.min.size.reached" |
L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car le cluster étant déjà à sa taille minimale, aucun nœud n'a pu être supprimé. | Nom du nœud défaillant. | Examinez la valeur minimale définie pour l'autoscaling du pool de nœuds et ajustez les paramètres si nécessaire. Pour en savoir plus, consultez la section Erreur: les nœuds du cluster ont atteint la taille minimale. |
Motifs de survenue d'un événement noScaleDown
Un événement noScaleDown est émis régulièrement lorsque des nœuds ne peuvent pas être supprimés par l'autoscaler de cluster. Les événements noScaleDown reposent sur le principe du "meilleur effort" et ne couvrent pas tous les cas possibles.
Motifs de premier niveau pour les événements noScaleDown
Les messages de motif de premier niveau pour les événements noScaleDown s'affichent dans le champ noDecisionStatus.noScaleDown.reason. Le message contient un motif de premier niveau pour lequel l'autoscaler de cluster ne peut pas effectuer de scaling à la baisse du cluster.
| Message d'événement | Détails | Atténuation |
|---|---|---|
"no.scale.down.in.backoff" |
L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car cette opération est dans une période d'interruption (il est temporairement bloqué). | Cet événement est temporaire et peut se produire lorsqu'un événement de scaling à la hausse est récent. Si le message persiste, contactez l'assistance Cloud Customer Care pour une analyse plus approfondie. |
"no.scale.down.in.progress" |
L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car une opération de scaling à la baisse précédente était toujours en cours. |
Ce message devrait être temporaire, car le pod sera supprimé à terme. Si ce message apparaît fréquemment, vérifiez le délai de préavis de résiliation pour le scaling à la baisse des pods. Pour accélérer la résolution, vous pouvez également supprimer le pod s'il n'est plus nécessaire. |
Motifs de niveau nœud pour les événements noScaleDown
Les messages de motif de niveau nœud pour les événements noScaleDown s'affichent dans le champ noDecisionStatus.noScaleDown.nodes[].reason field. Le message contient un motif pour lequel l'autoscaler de cluster ne peut pas supprimer un nœud particulier.
| Message d'événement | Détails | Paramètres | Atténuation |
|---|---|---|---|
"no.scale.down.node.scale.down.disabled.annotation" |
L'autoscaler de cluster ne peut pas supprimer un nœud du pool de nœuds, car le nœud est annoté avec cluster-autoscaler.kubernetes.io/scale-down-disabled: true.
|
N/A | Cluster Autoscaler ignore les nœuds avec cette annotation sans tenir compte de leur utilisation. Ce message est consigné, quel que soit le facteur d'utilisation du nœud. Si vous souhaitez que l'autoscaler de cluster réduise le nombre de ces nœuds, supprimez l'annotation. |
"no.scale.down.node.node.group.min.size.reached" |
L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse lorsque la taille du groupe de nœuds a dépassé la limite minimale. Cela se produit, car la suppression de nœuds enfreindrait les limites minimales de ressources à l'échelle du cluster définies dans les paramètres de provisionnement automatique de vos nœuds. |
N/A | Vérifiez la valeur minimale définie pour l'autoscaling du pool de nœuds. Si vous souhaitez que l'autoscaler de cluster réduise la taille de ce nœud, ajustez la valeur minimale. |
"no.scale.down.node.minimal.resource.limits.exceeded" |
L'autoscaler de cluster ne peut pas réduire la taille des nœuds, car cela enfreindrait les limites de ressources minimales à l'échelle du cluster. Il s'agit des limites de ressources définies pour le provisionnement automatique des nœuds. |
N/A | Examinez vos limites de mémoire et de vCPU et, si vous souhaitez que l'autoscaler de cluster réduise la taille de ce nœud, augmentez les limites. |
"no.scale.down.node.no.place.to.move.pods" |
L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car il n'y a pas d'emplacement où déplacer les pods. | N/A | Si vous prévoyez de reprogrammer le pod, consultez les exigences de planification des pods sur le nœud sous-utilisé pour déterminer s'ils peuvent être déplacés vers un autre nœud du cluster. Pour en savoir plus, consultez la section Erreur : aucun emplacement pour déplacer les pods. |
"no.scale.down.node.pod.not.backed.by.controller" |
Le pod bloque le scaling à la baisse, car il n'est pas secondé par un contrôleur. Plus précisément, l'autoscaler de cluster ne peut pas effectuer de scaling à la baisse d'un nœud sous-utilisé en raison d'un pod qui ne dispose pas d'un contrôleur reconnu. Les contrôleurs autorisés incluent ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet. |
Nom du pod à l'origine du blocage. | Définissez l'annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" pour le pod ou définissez un contrôleur acceptable. |
"no.scale.down.node.pod.has.local.storage" |
Le pod bloque le scaling à la baisse, car il possède un stockage en local. | Nom du pod à l'origine du blocage. | Définissez une annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" pour le pod si les données de stockage local pour le pod ne sont pas critiques.
Cette erreur ne se produit que pour les clusters utilisant une version antérieure à la version 1.22. |
"no.scale.down.node.pod.not.safe.to.evict.annotation" |
Un pod sur le nœud comporte l'annotation safe-to-evict=false. |
Nom du pod à l'origine du blocage. | Si le pod peut être évincé en toute sécurité, modifiez le fichier manifeste du pod et mettez à jour l'annotation sur "cluster-autoscaler.kubernetes.io/safe-to-evict": "true". |
"no.scale.down.node.pod.kube.system.unmovable" |
Le pod bloque le scaling à la baisse, car il s'agit d'un pod non DaemonSet, non mis en miroir et sans PodDisruptionBudget dans l'espace de noms kube-system. |
Nom du pod à l'origine du blocage. | Par défaut, les pods de l'espace de noms Pour résoudre ce problème, ajoutez un PodDisruptionBudget pour les pods |
"no.scale.down.node.pod.not.enough.pdb" |
Le pod bloque le scaling à la baisse, car le PodDisruptionBudget n'est pas suffisant. | Nom du pod à l'origine du blocage. | Examinez le PodDisruptionBudget du pod et envisagez de le rendre moins restrictive. Pour en savoir plus, consultez Erreur : PodDisruptionBudget insuffisant. |
"no.scale.down.node.pod.controller.not.found" |
Le pod bloque le scaling à la baisse, car son contrôleur (par exemple, un déploiement ou un ReplicaSet) est introuvable. | N/A | Pour déterminer quelles actions ont été effectuées après la suppression du contrôleur d'un pod, consultez les journaux. Pour résoudre ce problème, supprimez manuellement le pod. |
"no.scale.down.node.pod.unexpected.error" |
Le pod bloque le scaling à la baisse en raison d'une erreur inattendue. | N/A | La cause de cette erreur est inconnue. Contactez l'équipe Cloud Customer Care pour une analyse plus approfondie. |
Effectuer d'autres investigations
Les sections suivantes expliquent comment utiliser l'explorateur de journaux et gcpdiag pour obtenir des informations supplémentaires sur vos erreurs.
Analyser les erreurs dans l'explorateur de journaux
Si vous souhaitez examiner plus en détail votre message d'erreur, vous pouvez afficher les journaux spécifiques à votre erreur:
Dans Google Cloud Console, accédez à la page Explorateur de journaux.
Dans le volet Requête, saisissez la requête suivante :
resource.type="k8s_cluster" log_id("container.googleapis.com/cluster-autoscaler-visibility") jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"Remplacez
ERROR_MESSAGEpar le message que vous souhaitez examiner. Exemple :scale.down.error.failed.to.delete.node.min.size.reached.Cliquez sur Exécuter la requête.
Déboguer certaines erreurs avec gcpdiag
gcpdiag est un outil Open Source créé avec l'aide d'ingénieurs techniques Google Cloud. Il ne s'agit pas d'un produit Google Cloud officiellement compatible.
Si l'un des messages d'erreur suivants s'affiche, vous pouvez utiliser gcpdiag pour résoudre le problème:
scale.down.error.failed.to.evict.podsno.scale.down.node.node.group.min.size.reached
Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.
Résoudre les erreurs de scaling à la baisse complexes
Les sections suivantes fournissent des conseils pour résoudre les erreurs impliquant plusieurs étapes et les erreurs auxquelles aucun message d'événement de l'autoscaler de cluster n'est associé.
Erreur: les nœuds du cluster ont atteint la taille minimale
Si les erreurs suivantes s'affichent, l'autoscaler de cluster n'a pas pu supprimer un nœud, car le nombre de nœuds du cluster était déjà à la taille minimale:
Notification
Le scaling à la baisse du nœud sous-utilisé est bloqué, car les limites de ressources minimales de l'autoscaler de cluster sont atteintes.
Événement
"scale.down.error.failed.to.delete.node.min.size.reached"
Pour résoudre ce problème, examinez et mettez à jour les limites minimales de l'autoscaling:
Dans la console Cloud Console, accédez à la page des clusters Kubernetes.
Cliquez sur le nom du cluster identifié dans la notification ou dans Cloud Logging.
Sur la page Détails du cluster, accédez à l'onglet Nœuds.
Examinez la valeur de la colonne Nombre de nœuds et comparez-la au nombre minimal de nœuds indiqué dans la colonne Autoscaling. Par exemple, si vous voyez 4 à 6 nœuds dans la colonne Autoscaling et que le nombre de nœuds dans le pool de nœuds est de 4, le nombre de pools de nœuds est déjà égal à la taille minimale. L'autoscaler de cluster ne peut donc pas réduire davantage la capacité des nœuds.
Si la configuration est correcte et que la valeur du nombre de nœuds est égale au minimum défini pour l'autoscaling, l'autoscaler de cluster fonctionne comme prévu. Si le nombre minimal de nœuds est trop élevé pour vos besoins, réduisez la taille minimale afin que les nœuds puissent être réduits.
Erreur: No place to move Pods (Aucun emplacement pour déplacer les pods)
Les erreurs suivantes se produisent lorsque l'autoscaler de cluster tente de réduire la capacité d'un nœud, mais ne peut pas le faire, car un pod de ce nœud ne peut pas être déplacé vers un autre nœud:
Notification
Le scaling à la baisse du nœud sous-utilisé est bloqué, car celui-ci comporte un pod qui ne peut pas être déplacé vers un autre nœud du cluster.
Événement
"no.scale.down.node.no.place.to.move.pods"
Si vous ne souhaitez pas que ce pod soit reprogrammé, ce message est attendu et aucune modification n'est requise. Si vous souhaitez que le pod soit reprogrammé, examinez les définitions suivantes dans le pod.spec block du fichier manifeste du pod:
- NodeAffinity: examinez les exigences de planification des pods sur le nœud sous-utilisé. Vous pouvez vérifier ces exigences en examinant le fichier manifeste du pod et en recherchant les règles NodeAffinity ou NodeSelector. Si le pod possède un nodeSelector défini et qu'il n'y a pas d'autres nœuds (d'autres pools de nœuds) dans le cluster qui correspondent à ce sélecteur, l'autoscaler de cluster ne peut pas déplacer le pod vers un autre nœud, ce qui l'empêche de supprimer les nœuds sous-utilisés.
maxPodConstraint: simaxPodConstraintest configuré sur un autre nombre que le nombre par défaut de 110, confirmez s'il s'agit d'un changement intentionnel. Si vous diminuez cette valeur, vous augmentez la probabilité de rencontrer des problèmes. L'autoscaler de cluster ne peut pas reprogrammer les pods sur d'autres nœuds si tous les autres nœuds du cluster ont déjà atteint la valeur définie dansmaxPodConstraint, ce qui ne laisse pas d'espace pour programmer de nouveaux pods. L'augmentation de la valeurmaxPodConstraintpermet de planifier davantage de pods sur les nœuds. L'autoscaler de cluster dispose alors de l'espace nécessaire pour replanifier les pods et réduire les nœuds sous-utilisés. Lorsque vous définissezmaxPodConstraint, n'oubliez pas qu'il y a environ 10 pods système sur chaque nœud.hostPort: si vous spécifiez unhostPortpour le pod, cela signifie qu'un seul pod peut s'exécuter sur ce nœud. Il peut donc être difficile pour l'autoscaler de cluster de réduire le nombre de nœuds, car le pod ne peut pas être déplacé vers un autre nœud si le port de ce nœud est déjà utilisé. Ce comportement est normal.
Erreur: le pod kube-system ne peut pas être déplacé
Les erreurs suivantes se produisent lorsqu'un pod système empêche le scaling à la baisse:
Notification
Le pod bloque le scaling à la baisse, car il s'agit d'un pod non DaemonSet, non mis en miroir et sans PodDisruptionBudget dans l'espace de noms
kube-system.
Événement
"no.scale.down.node.pod.kube.system.unmovable"
Un pod dans l'espace de noms kube-system est considéré comme un pod système. Par défaut, l'autoscaler de cluster ne supprime pas les pods de l'espace de noms kube-system.
Pour résoudre cette erreur, choisissez l'une des solutions suivantes:
Ajoutez un budget
PodDisruptionBudgetpour les podskube-system. Pour en savoir plus sur l'ajout manuel d'unPodDisruptionBudgetpour les podskube-system, consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes.La création d'un PodDisruptionBudget peut affecter la disponibilité des charges de travail système, ce qui peut entraîner des interruptions sur le cluster. L'autoscaler de cluster réorganise ces charges de travail système sur différents nœuds de calcul pendant le processus de scaling à la baisse.
Utilisez une combinaison de rejets et de tolérances de pools de nœuds pour séparer les pods
kube-systemdes pods de votre application. Pour en savoir plus, consultez la section Provisionnement automatique des nœuds dans GKE.
Vérifier que les nœuds disposent de pods kube-system
Si vous n'êtes pas sûr que vos nœuds exécutent des pods kube-system et que vous souhaitez le vérifier, procédez comme suit:
Accédez à l'explorateur de journaux dans la console Google Cloud.
Cliquez sur Générateur de requêtes.
Utilisez la requête suivante pour rechercher tous les enregistrements du journal des règles de réseau :
- resource.labels.location="CLUSTER_LOCATION" resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility" jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"Remplacez les éléments suivants :
CLUSTER_LOCATION: la région dans laquelle se trouve le clusterCLUSTER_NAME: le nom du clusterPROJECT_ID: ID du projet auquel appartient votre cluster.NODE_POOL_NAME: le nom de votre pool de nœuds
S'il y a des pods
kube-systemen cours d'exécution sur votre pool de nœuds, le résultat inclut les éléments suivants :"no.scale.down.node.pod.kube.system.unmovable"
Erreur: PodDisruptionBudget insuffisant
Les erreurs suivantes se produisent lorsque votre PodDisruptionBudget empêche le scaling à la baisse:
Notification
Le scaling à la baisse du nœud sous-utilisé est bloqué, car un pod est en cours d'exécution sur le nœud et que le budget d'interruption de pod (PDB) est insuffisant pour permettre l'éviction du pod.
Événement
NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"
Pour vérifier si un PodDisruptionBudget est trop restrictif, examinez ses paramètres:
kubectl get pdb --all-namespaces
Le résultat ressemble à ce qui suit :
NAMESPACE NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
example-app-one one_pdb N/A 1 1 12d
example-app-two two_pdb N/A 0 0 12d
Dans cet exemple, les pods correspondant au sélecteur de libellé two_pdb ne seront pas exclus par l'autoscaler de cluster. Le paramètre maxUnavailable: 0 de ce PodDisruptionBudget indique que tous les instances répliquées doivent rester disponibles à tout moment. De plus, disruptionsAllowed: 0 interdit toute interruption de ces pods. Par conséquent, les nœuds exécutant ces pods ne peuvent pas être sujets au scaling à la baisse, car cela entraînerait une interruption et irait à l'encontre de la règle PodDisruptionBudget.
Si votre PodDisruptionBudget fonctionne comme vous le souhaitez, aucune autre action n'est requise. Si vous souhaitez ajuster votre PodDisruptionBudget afin de pouvoir déplacer des pods sur un nœud sous-utilisé, modifiez le fichier manifeste du PodDisruptionBudget.
Par exemple, si vous avez défini maxUnavailable sur 0, vous pouvez le remplacer par 1 pour que l'autoscaler de cluster puisse réduire la taille.
Problème: le nœud reste dans l'état "non programmable" et n'est pas supprimé
Des erreurs semblables à celles-ci se produisent lorsque l'autoscaler de cluster ne peut pas réduire la taille du pool de nœuds, car le compte de service Google ne dispose pas du rôle Éditeur:
Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.
Un symptôme courant de ce problème est lorsque l'autoscaler de cluster tente de réduire la taille du pool de nœuds, mais que le nœud ne change pas d'état.
Pour résoudre ce problème, vérifiez si le compte de service par défaut (PROJECT_NUMBER@cloudservices.gserviceaccount.com) dispose du rôle Éditeur (roles/editor) sur le projet. Si le compte de service ne dispose pas de ce rôle, ajoutez-le maintenant. GKE utilise ce compte de service pour gérer les ressources de votre projet. Pour savoir comment procéder, consultez la section Attribuer ou révoquer un rôle unique dans la documentation IAM.
Étape suivante
Consultez les questions suivantes dans les questions fréquentes sur l'autoscaler de cluster Kubernetes:
Regardez une vidéo YouTube sur le dépannage et la résolution des problèmes de scaling.
Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.