Résoudre les problèmes liés à l'autoscaling horizontal des pods

Lorsque l'autoscaling horizontal des pods ne fonctionne pas comme prévu dans Google Kubernetes Engine (GKE), il est possible que vos charges de travail ne soient pas mises à l'échelle correctement. Ce problème peut empêcher les applications de gérer la charge, ce qui peut entraîner des problèmes de performances ou des pannes. Il est possible que le nombre de pods n'augmente pas malgré une utilisation élevée du processeur, que les valeurs des métriques s'affichent sous la forme <unknown> dans l'état de votre HorizontalPodAutoscaler ou que les opérations de scaling ne se produisent pas du tout.

Utilisez cette page pour diagnostiquer et résoudre les problèmes courants liés à l'autoscaling horizontal des pods, qu'il s'agisse de problèmes de configuration initiale dans vos objets HorizontalPodAutoscaler ou d'échecs plus complexes dans le pipeline de métriques. En suivant ces étapes de dépannage, vous pouvez vous assurer que vos applications évoluent de manière efficace et fiable en fonction de la demande, en utilisant efficacement la ressource Autoscaler horizontal de pods.

Ces informations sont importantes pour les développeurs d'applications qui configurent des objets HorizontalPodAutoscaler et doivent s'assurer que leurs applications évoluent correctement. Il aide également les administrateurs et opérateurs de plate-forme à résoudre les problèmes liés au pipeline de métriques ou à la configuration du cluster qui affectent toutes les charges de travail autoscalées. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Si vous avez déjà rencontré des symptômes ou vu un message d'erreur, utilisez le tableau suivant pour trouver les conseils appropriés :

Problème constaté Solution possible
Aucun scaling, mais les conditions HorizontalPodAutoscaler sont True Résoudre les problèmes liés à un HorizontalPodAutoscaler sain, mais qui ne répond pas
Un message d'erreur spécifique s'affiche dans les événements HorizontalPodAutoscaler Résoudre les erreurs courantes de l'autoscaler horizontal de pods
Métrique <unknown> Résoudre les problèmes liés aux métriques personnalisées et externes
Le scaling à la baisse ne fonctionne pas Résoudre les problèmes liés à l'autoscaler horizontal de pods qui n'effectue pas de scaling à la baisse

Avant de commencer

  • Assurez-vous d'utiliser des objets HorizontalPodAutoscaler avec des charges de travail évolutives, telles que des déploiements et des StatefulSets. Vous ne pouvez pas utiliser l'autoscaling horizontal des pods avec des charges de travail qui ne peuvent pas être mises à l'échelle, comme les DaemonSets.

  • Pour obtenir les autorisations nécessaires pour résoudre les problèmes d'autoscaling horizontal de pods dans GKE, y compris inspecter les objets HorizontalPodAutoscaler et afficher les journaux du cluster, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

    Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

    Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

  • Configurez l'outil de ligne de commande kubectl pour communiquer avec votre cluster GKE :

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.
    • PROJECT_ID : ID de votre projet Google Cloud .

Vérifier l'état et la configuration de l'autoscaler horizontal de pods

Commencez le dépannage en inspectant l'état et la configuration de l'objet HorizontalPodAutoscaler. Cette vérification initiale vous aide à identifier et à résoudre les erreurs de configuration de base, qui sont une cause fréquente des problèmes de mise à l'échelle.

Décrire HorizontalPodAutoscaler

Pour afficher les calculs en temps réel et les décisions de scaling récentes de l'objet HorizontalPodAutoscaler, utilisez la commande kubectl describe hpa. Cette commande fournit un récapitulatif de l'objet HorizontalPodAutoscaler et un journal Events utile pour diagnostiquer les problèmes :

kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

Remplacez les éléments suivants :

  • HPA_NAME : nom de votre objet HorizontalPodAutoscaler.
  • NAMESPACE_NAME : espace de noms de votre objet HorizontalPodAutoscaler.

Le résultat ressemble à ce qui suit :

Name:                                                  php-apache-hpa
Reference:                                             Deployment/php-apache
Metrics: ( current / target )
  resource cpu on pods (as a percentage of request):   1% (1m) / 50%
Min replicas:                                          1
Max replicas:                                          10
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HorizontalPodAutoscaler was able to successfully calculate a replica count
Events:
  Type     Reason              Age   From                       Message
  ----     ------              ----  ----                       -------
  Normal   SuccessfulRescale   39m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization...
  Normal   SuccessfulRescale   26m   horizontal-pod-autoscaler  New size: 1; reason: cpu resource utilization...

Dans le résultat, les trois sections suivantes vous aident à diagnostiquer le problème :

  • Metrics : cette section affiche les valeurs actuelles des métriques par rapport à leurs cibles. Vérifiez ici si HorizontalPodAutoscaler reçoit des données. Une valeur de métrique <unknown> indique que HorizontalPodAutoscaler n'a pas récupéré la métrique ou que le pipeline de métriques est interrompu.
  • Conditions : cette vérification de l'état de haut niveau indique si HorizontalPodAutoscaler peut récupérer des métriques (AbleToScale) et effectuer des calculs de scaling (ScalingActive). Un état False dans l'une de ces conditions indique un échec.
  • Events : cette section enregistre les actions de scaling, les avertissements et les erreurs récents du contrôleur HorizontalPodAutoscaler. C'est souvent le premier endroit où trouver des messages ou des raisons d'erreur spécifiques, comme FailedGetScale ou FailedGetResourceMetric, qui vous aident à découvrir la source du problème.

Vérifier l'état de HorizontalPodAutoscaler dans les déploiements

Pour vérifier l'état des objets HorizontalPodAutoscaler utilisés avec vos déploiements, utilisez la console Google Cloud  :

  1. Dans la console Google Cloud , accédez à la page Charges de travail.

    Accéder à la page Charges de travail

  2. Cliquez sur le nom de votre déploiement.

  3. Accédez à l'onglet Détails, puis recherchez la section Autoscaling.

  4. Vérifiez la valeur de la ligne État :

    • Une coche verte signifie que l'élément HorizontalPodAutoscaler est configuré et peut lire ses métriques.
    • Un triangle orange signifie que l'objet HorizontalPodAutoscaler est configuré, mais qu'il a du mal à lire ses métriques. Il s'agit d'un problème courant avec les métriques personnalisées ou externes. Pour résoudre ce problème, identifiez la raison pour laquelle les métriques ne sont pas disponibles. Pour en savoir plus, consultez la section Résoudre les problèmes liés aux métriques personnalisées et externes.

Pour les autres types de charges de travail, comme les StatefulSets, ou pour plus de détails, consultez le fichier manifeste de l'objet HorizontalPodAutoscaler.

Vérifier le fichier manifeste de votre HorizontalPodAutoscaler

Le fichier manifeste YAML de votre objet HorizontalPodAutoscaler vous permet d'afficher des informations sur sa configuration et son état actuel.

Pour afficher le fichier manifeste YAML, sélectionnez l'une des options suivantes :

Console

  1. Dans la console Google Cloud , accédez à la page Navigateur d'objets.

    Accéder au navigateur d'objets

  2. Dans la liste Types d'objets, cochez la case HorizontalPodAutoscaler, puis cliquez sur OK.

  3. Accédez au groupe d'API autoscaling, puis cliquez sur la flèche d'expansion pour HorizontalPodAutoscaler.

  4. Cliquez sur le nom de l'objet HorizontalPodAutoscaler que vous souhaitez inspecter.

  5. Consultez la section YAML, qui affiche la configuration complète de l'objet HorizontalPodAutoscaler.

kubectl

Exécutez la commande suivante :

kubectl get hpa HPA_NAME -n NAMESPACE_NAME -o yaml

Remplacez les éléments suivants :

  • HPA_NAME : nom de votre objet HorizontalPodAutoscaler.
  • NAMESPACE_NAME : espace de noms de votre objet HorizontalPodAutoscaler.

Une fois le fichier manifeste récupéré, recherchez les sections clés suivantes :

  • spec (votre configuration) :
    • scaleTargetRef : charge de travail (comme un déploiement) que l'HorizontalPodAutoscaler est censé mettre à l'échelle.
    • minReplicas et maxReplicas : paramètres de réplique minimale et maximale.
    • metrics : métriques que vous avez configurées pour le scaling (par exemple, l'utilisation du processeur ou les métriques personnalisées).
  • status (état actuel de l'HorizontalPodAutoscaler) :
    • currentMetrics : valeurs de métriques les plus récentes observées par HorizontalPodAutoscaler.
    • currentReplicas et desiredReplicas : nombre actuel de pods et nombre auquel l'autoscaler horizontal des pods souhaite s'adapter.
    • conditions : section la plus utile pour le dépannage. Cette section affiche l'état de l'objet HorizontalPodAutoscaler :
      • AbleToScale : indique si HorizontalPodAutoscaler peut trouver sa cible et ses métriques.
      • ScalingActive : indique si HorizontalPodAutoscaler est autorisé à calculer et à effectuer le scaling.
      • ScalingLimited : indique si l'HorizontalPodAutoscaler souhaite effectuer un scaling, mais est limité par vos paramètres minReplicas ou maxReplicas.

Utiliser les fonctionnalités de journalisation avancées

Pour obtenir des informations plus détaillées sur votre objet HorizontalPodAutoscaler, utilisez les types de journaux suivants :

  • Afficher les événements de l'autoscaler horizontal de pods dans Cloud Logging : utilisez un filtre de journaux pour trouver tous les événements de l'autoscaler horizontal de pods pour un cluster spécifique. Exemple :

    1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

      Accéder à l'explorateur de journaux

    2. Dans le volet Requête, saisissez la requête suivante :

      resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
logName="projects/PROJECT_ID/logs/events"
jsonPayload.involvedObject.kind="HorizontalPodAutoscaler"`

      Remplacez les éléments suivants :

      • CLUSTER_NAME : nom du cluster auquel appartient HorizontalPodAutoscaler.
      • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.
      • PROJECT_ID : ID de votre projet.

    3. Cliquez sur Exécuter la requête et examinez le résultat.

  • Afficher les événements de l'autoscaler horizontal de pods : ces journaux fournissent des journaux structurés et lisibles par l'homme qui expliquent comment l'autoscaler horizontal de pods calcule une recommandation, offrant ainsi un aperçu détaillé de son processus de prise de décision.

Résoudre les problèmes liés à un HorizontalPodAutoscaler sain, mais qui ne répond pas

Cette section vous aide à comprendre pourquoi votre HorizontalPodAutoscaler ne déclenche aucune action de scaling, même s'il semble sain et ne signale aucune erreur dans son état ni dans ses événements.

Symptômes :

L'objet HorizontalPodAutoscaler semble opérationnel, ses conditions indiquent True et aucun événement d'erreur n'est signalé. Toutefois, il n'effectue toujours aucune action de scaling.

Cause :

Plusieurs facteurs peuvent entraîner ce comportement attendu :

  • Limites d'instances dupliquées : le nombre actuel d'instances dupliquées se trouve déjà à la limite définie par le champ minReplicas ou maxReplicas dans la configuration HorizontalPodAutoscaler.
  • Marge de tolérance : Kubernetes utilise une marge de tolérance par défaut de 10 % pour éviter le scaling en cas de fluctuations mineures des métriques. La mise à l'échelle n'a lieu que si le ratio entre la métrique actuelle et la métrique cible se situe en dehors de la plage comprise entre 0,9 et 1,1. Par exemple, si la cible est de 85 % d'utilisation du processeur et que l'utilisation actuelle est de 93 %, le ratio est d'environ 1,094 (93/85≈1,094). Comme cette valeur est inférieure à 1,1, l'autoscaler horizontal de pods n'effectue pas de scaling à la hausse.
  • Pods non prêts : l'autoscaler horizontal de pods n'inclut que les pods dont l'état est Ready dans ses calculs de scaling. Les pods bloqués à l'état Pending ou qui ne passent pas à l'état Ready (en raison d'échecs de vérification de l'état ou de problèmes de ressources) sont ignorés et peuvent empêcher la mise à l'échelle.
  • Délai de la période de synchronisation : le contrôleur HorizontalPodAutoscaler vérifie les métriques de manière périodique. Il est normal qu'il y ait un délai de 15 à 30 secondes entre le moment où une métrique dépasse le seuil et le début d'une action de scaling.
  • Latence de création : lorsqu'un HorizontalPodAutoscaler utilise une nouvelle métrique personnalisée pour la première fois, vous pouvez constater une latence ponctuelle de plusieurs minutes. Ce délai se produit, car le système de surveillance (tel que Cloud Monitoring) doit créer la nouvelle série temporelle lorsque le premier point de données est écrit.
  • Calcul de plusieurs métriques : lorsque vous configurez plusieurs métriques, l'Autoscaler horizontal de pods calcule le nombre d'instances dupliquées requis pour chaque métrique de manière indépendante, puis choisit la valeur calculée la plus élevée comme nombre final d'instances dupliquées. En raison de ce comportement, votre charge de travail est mise à l'échelle pour répondre aux exigences de la métrique ayant les besoins les plus élevés. Par exemple, si les métriques de processeur calculent un besoin de neuf répliques, mais qu'une métrique de requêtes par seconde calcule un besoin de 15, l'Autoscaler horizontal de pods met à l'échelle le déploiement à 15 répliques.

Solution :

Essayez les solutions suivantes :

  • Limites de répliques : vérifiez les valeurs minReplicas et maxReplicas dans votre fichier manifeste HorizontalPodAutoscaler ou dans le résultat de la commande kubectl describe. Ajustez ces limites si elles empêchent la mise à l'échelle nécessaire.
  • Marge de tolérance : si une mise à l'échelle est requise dans la marge de tolérance par défaut, configurez une autre valeur de tolérance. Sinon, attendez que la métrique sorte de la plage de ratio de 0,9 à 1,1.
  • Pods non prêts : recherchez pourquoi les pods sont Pending ou non Ready et résolvez les problèmes sous-jacents (par exemple, les contraintes de ressources, les vérifications de préparation en échec). Pour obtenir des conseils de dépannage, consultez Déboguer les pods dans la documentation Kubernetes.
  • Délai de la période de synchronisation et latence de la nouvelle métrique : ces latences sont normales. Attendez la fin de la période de synchronisation ou la création de la série temporelle de la nouvelle métrique personnalisée.
  • Calcul de plusieurs métriques : ce comportement est intentionnel. Si le scale-up se produit en fonction d'une métrique (par exemple, les requêtes par seconde), il remplace correctement le calcul inférieur d'une autre métrique (par exemple, le processeur).

Résoudre les erreurs courantes liées à l'autoscaler horizontal de pods

Les sections suivantes fournissent des solutions pour des messages d'erreur et des raisons d'événements spécifiques que vous pouvez rencontrer lorsque vous inspectez l'état de votre HorizontalPodAutoscaler. Vous trouverez généralement ces messages dans la section Events du résultat de la commande kubectl describe hpa.

Résoudre les erreurs de configuration de l'autoscaler horizontal de pods

Une erreur de configuration dans le fichier manifeste HorizontalPodAutoscaler, comme un champ mal saisi ou des configurations conflictuelles, est à l'origine des erreurs de cette section.

Erreur : métriques non valides

Cette erreur peut s'afficher lorsque la configuration d'une métrique dans un HorizontalPodAutoscaler est incorrecte ou incohérente au niveau de la syntaxe.

Symptômes :

Si HorizontalPodAutoscaler ne peut pas calculer le nombre de répliques requis en raison d'un problème de configuration, sa section Events affiche la raison FailedComputeMetricsReplicas avec un message semblable à celui-ci :

invalid metrics (1 invalid out of 1)

Cause :

Cette erreur signifie généralement qu'il existe une incohérence entre la métrique type et le target que vous avez défini dans votre fichier manifeste HorizontalPodAutoscaler. Par exemple, vous avez peut-être spécifié un type de Utilization, mais fourni une valeur cible de averageValue au lieu de averageUtilization.

Solution :

Corrigez le fichier manifeste HorizontalPodAutoscaler afin que la valeur du champ target corresponde à la métrique type :

  • Si type est défini sur Utilization, la valeur du champ target doit être averageUtilization.
  • Si type est défini sur AverageValue, la valeur du champ target doit être averageValue.

Erreur : plusieurs services sélectionnent la même cible

Cette erreur peut s'afficher lorsque vous utilisez un autoscaling basé sur le trafic avec une configuration de service incorrecte pour votre HorizontalPodAutoscaler.

Symptômes :

L'erreur suivante s'affiche :

multiple services selecting the same target of HPA_NAME: SERVICE_NAME

Ce résultat inclut les valeurs suivantes :

  • HPA_NAME : nom de l'objet HorizontalPodAutoscaler.
  • SERVICE_NAME : nom d'un service.

Cause :

L'autoscaling basé sur le trafic est configuré, mais plusieurs services Kubernetes ciblent le champ scaleTargetRef de l'HorizontalPodAutoscaler. L'autoscaling basé sur le trafic n'est compatible qu'avec une relation un-à-un entre le service et la charge de travail autoscalée.

Solution :

Pour résoudre ce problème, assurez-vous qu'un seul sélecteur de libellé de service correspond aux pods de votre charge de travail :

  1. Recherchez les libellés de pod de votre charge de travail :

    kubectl get deployment HPA_TARGET_DEPLOYMENT \
    -n NAMESPACE \
    -o jsonpath='{.spec.template.metadata.labels}'

    Remplacez les éléments suivants :

    • HPA_TARGET_DEPLOYMENT : nom du déploiement ciblé par HorizontalPodAutoscaler.
    • NAMESPACE : espace de noms du déploiement.

    Le résultat ressemble à ce qui suit :

    {"app":"my-app", "env":"prod"}

  2. Pour trouver tous les services correspondant à ces libellés, examinez le champ spec.selector de tous les services de l'espace de noms.

    kubectl get services -n NAMESPACE -o yaml

    Identifiez chaque service dont le sélecteur correspond aux libellés de l'étape précédente. Par exemple, {"app": "my-app"} et {"app": "my-app", "env": "prod"} correspondraient aux libellés de pod de l'exemple.

  3. Résolvez le conflit en choisissant l'une des options suivantes :

    • Rendez le sélecteur du service prévu unique en ajoutant un libellé unique au champ spec.template.metadata.labels de votre déploiement. Ensuite, mettez à jour le champ spec.selector du Service prévu pour inclure ce nouveau libellé.
    • Rendez les autres sélecteurs de service plus restrictifs en modifiant le champ spec.selector de tous les autres services en conflit afin qu'ils soient plus restrictifs et ne correspondent plus aux pods de votre charge de travail.

  4. Appliquez les modifications :

    kubectl apply -f MANIFEST_NAME

    Remplacez MANIFEST_NAME par le nom du fichier YAML contenant le fichier manifeste de service ou de déploiement mis à jour.

Erreur : le libellé n'est pas autorisé

Symptômes :

L'erreur suivante s'affiche :

unable to fetch metrics from external metrics API: googleapi: Error 400: Metric label: 'LABEL_NAME' is not allowed

Dans ce résultat, LABEL_NAME correspond au nom du libellé incorrect.

Cause :

Le fichier manifeste HorizontalPodAutoscaler spécifie une clé de libellé non valide dans la section metric.selector.matchLabels. Cloud Monitoring ne reconnaît ni n'autorise cette clé pour la métrique.

Solution :

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

  1. Identifiez le nom de libellé non autorisé dans le message d'erreur.
  2. Supprimez ou corrigez cette clé de libellé dans la section metric.selector.matchLabels de votre fichier manifeste HorizontalPodAutoscaler.
  3. Pour trouver une clé de libellé valide et filtrable, consultez la documentation Cloud Monitoring pour cette métrique.

Problème : plusieurs HorizontalPodAutoscalers ciblent la même charge de travail

La configuration de plusieurs objets HorizontalPodAutoscaler pour gérer la même charge de travail entraîne un comportement de scaling conflictuel et imprévisible.

Symptômes :

Il n'existe pas de Condition ni de Reason spécifiques dans l'état d'un HorizontalPodAutoscaler qui indiquent directement ce conflit. Vous pouvez plutôt observer les symptômes suivants :

  • Le nombre de répliques de la charge de travail peut fluctuer de manière inattendue.
  • Il est possible que les décisions de scaling ne semblent pas correspondre aux métriques définies dans un objet HorizontalPodAutoscaler donné.
  • Lorsque vous consultez des événements, vous pouvez voir des événements SuccessfulRescale alternatifs ou contradictoires provenant de différents objets HorizontalPodAutoscaler.

Cause :

Ce problème se produit lorsqu'un même espace de noms contient plusieurs objets HorizontalPodAutoscaler qui spécifient exactement la même charge de travail dans le champ spec.scaleTargetRef. Chaque HorizontalPodAutoscaler calcule indépendamment le nombre de réplicas et tente de mettre à l'échelle la charge de travail en fonction de son propre ensemble de métriques et de cibles. Kubernetes ne bloque pas cette configuration, mais elle entraîne des ajustements de scaling erratiques, car les HorizontalPodAutoscalers se font concurrence.

Solution :

Pour éviter les conflits, définissez toutes les métriques de scaling dans un seul objet HorizontalPodAutoscaler. Chaque HorizontalPodAutoscaler calcule les besoins de scaling à partir de son propre champ spec.metrics. La fusion permet à l'objet HorizontalPodAutoscaler choisi de prendre en compte tous les facteurs, tels que le processeur et les requêtes par seconde, ensemble :

  1. Pour identifier les HorizontalPodAutoscalers qui ciblent la même charge de travail, obtenez le fichier manifeste YAML pour chaque objet HorizontalPodAutoscaler. Portez une attention particulière au champ spec.scaleTargetRef dans le résultat.

    kubectl get hpa -n NAMESPACE_NAME -o yaml

    Remplacez NAMESPACE_NAME par l'espace de noms de votre objet HorizontalPodAutoscaler.

    Recherchez les instances où différentes ressources HorizontalPodAutoscaler ont les mêmes valeurs pour apiVersion, kind et name dans leur champ scaleTargetRef.

  2. Consolidez les métriques dans un seul objet HorizontalPodAutoscaler :

    1. Choisissez l'objet HorizontalPodAutoscaler à conserver. C'est ce HorizontalPodAutoscaler que vous allez modifier.
    2. Examinez la section spec.metrics dans le fichier manifeste de chacun des autres objets HorizontalPodAutoscaler ciblant la même charge de travail.
    3. Copiez les définitions de métriques que vous souhaitez conserver à partir des sections spec.metrics des objets HorizontalPodAutoscaler en double.
    4. Collez ces définitions de métriques copiées dans le tableau spec.metrics de l'objet HorizontalPodAutoscaler que vous avez décidé de conserver.

  3. Appliquez les modifications :

    kubectl apply -f MANIFEST_NAME

    Remplacez MANIFEST_NAME par le nom du fichier manifeste HorizontalPodAutoscaler que vous avez décidé de conserver.

  4. Supprimez les autres objets HorizontalPodAutoscaler qui ciblaient la même charge de travail :

    kubectl delete hpa DUPLICATE_MANIFEST_NAME -n NAMESPACE_NAME

    Remplacez DUPLICATE_MANIFEST_NAME par le nom de l'objet HorizontalPodAutoscaler redondant que vous souhaitez supprimer.

Résoudre les problèmes liés à la charge de travail et à la cible

Les erreurs de cette section sont dues à la mise à l'échelle du déploiement, de StatefulSet ou des pods, et non à l'objet HorizontalPodAutoscaler lui-même.

Erreur : Impossible d'obtenir l'échelle actuelle de la cible

Cette erreur peut s'afficher lorsque l'HorizontalPodAutoscaler ne parvient pas à localiser ni à accéder à la charge de travail qu'il est censé mettre à l'échelle.

Symptômes :

La section Events présente une condition FailedGetScale avec un message semblable à celui-ci :

the HorizontalPodAutoscaler controller was unable to get the target's current scale: WORKLOAD_TYPE.apps "TARGET_WORKLOAD" not found

Ce résultat inclut les valeurs suivantes :

  • WORKLOAD_TYPE : type de charge de travail, tel que Deployment ou StatefulSet.
  • TARGET_WORKLOAD : nom de la charge de travail.

Cause :

Le contrôleur HorizontalPodAutoscaler ne parvient pas à trouver la charge de travail (comme un déploiement ou un StatefulSet) qu'il est configuré pour gérer. Ce problème est dû à un problème dans le champ scaleTargetRef du fichier manifeste HorizontalPodAutoscaler. Il est possible que la ressource spécifiée n'existe pas, qu'elle ait été supprimée ou qu'elle comporte une faute d'orthographe.

Solution :

Essayez les solutions suivantes :

  1. Vérifiez le champ scaleTargetRef du fichier manifeste HorizontalPodAutoscaler : assurez-vous que les valeurs de name, kind et apiVersion dans le champ scaleTargetRef correspondent exactement aux métadonnées correspondantes de votre charge de travail cible. Si le nom de la charge de travail est incorrect, mettez à jour le champ scaleTargetRef de HorizontalPodAutoscaler pour qu'il pointe vers le nom correct.
  2. Vérifiez que la charge de travail existe : assurez-vous que la charge de travail cible existe dans le même espace de noms que HorizontalPodAutoscaler. Vous pouvez le vérifier à l'aide d'une commande telle que kubectl get deployment DEPLOYMENT_NAME. Si vous avez supprimé intentionnellement la charge de travail, supprimez l'objet HorizontalPodAutoscaler correspondant pour nettoyer votre cluster. Si vous devez recréer la charge de travail, HorizontalPodAutoscaler la trouvera automatiquement une fois qu'elle sera disponible, et l'erreur sera résolue.
  3. Vérifiez que l'HorizontalPodAutoscaler et la charge de travail se trouvent dans le même espace de noms : l'HorizontalPodAutoscaler et sa charge de travail cible doivent se trouver dans le même espace de noms. Si vous oubliez de spécifier un espace de noms lorsque vous créez un objet avec des commandes kubectl, Kubernetes place l'objet dans l'espace de noms default. Ce comportement peut entraîner une incohérence si votre HorizontalPodAutoscaler se trouve dans l'espace de noms default et votre charge de travail dans un autre, ou inversement. Vérifiez l'espace de noms des deux objets et assurez-vous qu'ils correspondent.

Une fois que HorizontalPodAutoscaler a trouvé sa cible, la condition AbleToScale devient True et le message devient the HorizontalPodAutoscaler controller was able to get the target's current scale.

Erreur : Impossible de calculer le nombre de répliques

Cette erreur peut s'afficher lorsque HorizontalPodAutoscaler doit calculer la mise à l'échelle en fonction de l'utilisation des ressources, mais qu'il ne dispose pas des informations de référence nécessaires provenant des pods.

Symptômes :

La condition ScalingActive est False avec un Reason de FailedGetResourceMetric. Un message semblable au suivant s'affiche généralement :

the HorizontalPodAutoscaler was unable to compute the replica count

Cause :

L'autoscaler de pods horizontaux doit calculer l'utilisation des ressources en pourcentage pour adapter la charge de travail, mais il ne peut pas effectuer ce calcul, car au moins un conteneur de la spécification du pod ne comporte pas de définition resources.requests pour la ressource correspondante (cpu ou memory).

Solution :

Pour résoudre ce problème, mettez à jour le fichier manifeste du pod dans votre déploiement, StatefulSet ou autre contrôleur afin d'inclure un champ resources.requests pour la ressource (cpu ou memory) sur laquelle HorizontalPodAutoscaler tente de mettre à l'échelle tous les conteneurs du pod. Exemple :

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
...
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Erreur : impossible de récupérer les métriques du pod

Cette erreur peut s'afficher lorsqu'un problème survient lors de la récupération des métriques requises pour qu'un HorizontalPodAutoscaler prenne des décisions de scaling. Il est souvent lié aux définitions des ressources de pod.

Symptômes :

Un message persistant semblable à celui-ci s'affiche :

unable to fetch pod metrics for pod

Il est normal que ce message s'affiche temporairement au démarrage du serveur de métriques.

Cause :

Pour effectuer un scaling en fonction du pourcentage d'utilisation des ressources (comme cpu ou memory), chaque conteneur des pods ciblés par l'objet HorizontalPodAutoscaler doit avoir le champ resources.requests défini pour cette ressource spécifique. Sinon, l'HorizontalPodAutoscaler ne peut pas effectuer les calculs nécessaires et n'effectue aucune action en lien avec cette métrique.

Solution :

Si ces messages d'erreur persistent et que vous remarquez que les pods ne sont pas mis à l'échelle pour votre charge de travail, assurez-vous d'avoir spécifié des requêtes de ressources pour chaque conteneur de votre charge de travail.

Résoudre les problèmes liés à l'API Metrics et à la disponibilité des données

Les sections suivantes vous aident à résoudre les erreurs qui se produisent lorsque HorizontalPodAutoscaler tente d'extraire des données d'une API de métriques. Ces problèmes peuvent aller des échecs de communication de cluster interne, où l'API Metrics n'est pas disponible, aux requêtes non valides que le fournisseur de métriques rejette (souvent indiquées par des erreurs HTTP de niveau 400).

Erreur : Aucune version de métrique disponible connue n'a été trouvée

Symptômes :

L'erreur suivante s'affiche :

unable to fetch metrics from custom metrics API: no known available metric versions found

Cause :

Cette erreur indique une défaillance de la communication au sein du cluster, et non un problème avec la source des métriques (telle que Cloud Monitoring). Voici quelques causes courantes :

  • Le serveur d'API Kubernetes est temporairement indisponible (par exemple, lors d'une mise à niveau du cluster ou d'une réparation du plan de contrôle).
  • Les pods de l'adaptateur de métriques (par exemple, custom-metrics-stackdriver-adapter) sont défectueux, ne s'exécutent pas ou ne sont pas correctement enregistrés auprès du serveur API.

Solution :

Ce problème est souvent temporaire. Si le problème persiste, essayez les solutions suivantes :

  1. Vérifiez l'état du plan de contrôle Kubernetes :

    1. Dans la console Google Cloud , consultez l'état et l'intégrité de votre cluster.

      1. Accédez à la page des clusters Kubernetes.

        Accéder à la page "Clusters Kubernetes"

      2. Consultez les colonnes État et Notifications pour votre cluster.

      3. Cliquez sur Notifications pour rechercher les opérations en cours, comme les mises à niveau ou les réparations. Le serveur d'API peut être brièvement indisponible pendant ces périodes.

    2. Consultez les journaux d'audit Cloud pour détecter d'éventuelles erreurs liées aux composants du plan de contrôle. Pour savoir comment afficher ces journaux, consultez Informations sur la journalisation d'audit GKE.

  2. Vérifiez l'état et les journaux des pods de l'adaptateur de métriques : assurez-vous que les pods de l'adaptateur de métriques sont à l'état Running et n'ont pas été redémarrés récemment :

    kubectl get pods -n custom-metrics,kube-system -o wide

    Si l'état d'un pod est différent de Running ou si son nombre de redémarrages est élevé, examinez le pod pour en trouver la cause première. Pour obtenir des conseils de dépannage, consultez la section Déboguer les pods dans la documentation Kubernetes.

  3. Vérifiez que les API de métriques sont enregistrées et disponibles :

    kubectl get apiservice | grep metrics.k8s.io

    Si les API de métriques sont opérationnelles, le résultat ressemble à ce qui suit :

    NAME                            SERVICE                                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io   custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.external.metrics.k8s.io custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.metrics.k8s.io          kube-system/metrics-server                          True        18d

    Si la colonne AVAILABLE a une valeur de False, la colonne Message du fichier manifeste APIService complet peut fournir plus de détails.

    Vous pouvez afficher le fichier manifeste complet à l'aide de la commande suivante :

    kubectl get apiservice API_SERVICE_NAME -o yaml

    Remplacez API_SERVICE_NAME par le nom de l'objet APIService, tel que v1beta1.custom.metrics.k8s.io.

Erreur : la requête ne renverra aucune série temporelle

Symptômes :

L'erreur suivante s'affiche :

unable to fetch metrics from custom or external metrics API: googleapi: Error
400: The supplied filter [...] query will not return any time series

Cause :

La requête envoyée à Cloud Monitoring était valide, mais elle n'a renvoyé aucune donnée. Cela signifie qu'aucun point de données ne correspond à votre filtre (ce qui est différent de la recherche d'une métrique avec une valeur de 0). La raison la plus probable de ce problème est que l'application ou la charge de travail responsable de la génération de la métrique personnalisée n'a pas écrit de données dans Cloud Monitoring au moment où les erreurs ont été signalées.

Solution :

Essayez les solutions suivantes :

  1. Vérifiez la configuration : assurez-vous que les noms et libellés des métriques de votre objet HorizontalPodAutoscaler correspondent précisément à ceux émis par l'application.
  2. Vérifiez les autorisations : assurez-vous que l'application est correctement configurée avec les autorisations et les points de terminaison d'API nécessaires pour publier des métriques dans Cloud Monitoring.
  3. Confirmer l'activité de l'application : vérifiez que l'application responsable de la métrique était opérationnelle et tentait d'envoyer des données à Cloud Monitoring pendant la période où les avertissements de l'autoscaler horizontal de pods se sont produits.
  4. Recherchez les erreurs : vérifiez les journaux de l'application pour la même période afin de détecter d'éventuelles erreurs explicites liées à l'émission de métriques, telles que des échecs de connexion, des identifiants non valides ou des problèmes de mise en forme.

Résoudre les problèmes liés aux métriques personnalisées et externes

Lorsque votre HorizontalPodAutoscaler s'appuie sur des métriques provenant de sources autres que le processeur ou la mémoire par défaut, des problèmes peuvent survenir dans le pipeline de métriques personnalisées ou externes. Ce pipeline se compose du contrôleur HorizontalPodAutoscaler, du serveur d'API de métriques Kubernetes, de l'adaptateur de métriques et de la source de métriques (par exemple, Cloud Monitoring ou Prometheus), comme illustré dans le schéma suivant :

Pipeline de métriques AHP montrant les composants : contrôleur AHP, serveur d&#39;API Kubernetes, adaptateur de métriques et source de métriques.

Cette section explique en détail comment déboguer ce pipeline, de l'adaptateur de métriques à la source de métriques.

Symptômes :

Voici les symptômes les plus courants d'un problème dans le pipeline de métriques :

  • La valeur de la métrique s'affiche sous la forme <unknown>.
  • Les événements HorizontalPodAutoscaler affichent des erreurs telles que FailedGetExternalMetric ou FailedGetCustomMetric.

Cause :

Un problème existe dans le pipeline de métriques personnalisées ou externes.

Solution :

Suivez les étapes ci-dessous pour déboguer le pipeline :

  1. Vérifiez si l'adaptateur de métriques est enregistré et disponible : l'adaptateur de métriques doit s'enregistrer auprès du serveur d'API Kubernetes principal pour diffuser les métriques. Cette action est la méthode la plus directe pour vérifier si l'adaptateur est en cours d'exécution et accessible par le serveur d'API :

    kubectl get apiservice | grep -E 'NAME|metrics.k8s.io'

    Dans le résultat, vous devriez voir les entrées v1beta1.custom.metrics.k8s.io ou v1beta1.external.metrics.k8s.io, ainsi que la valeur True dans la colonne Available. Exemple :

    NAME                   SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io kube-system/metrics-server   True        18d

    • Si la valeur de la colonne Available est False ou manquante, il est probable que votre adaptateur ait planté ou soit mal configuré. Consultez les journaux de pod de l'adaptateur dans l'espace de noms kube-system ou custom-metrics pour détecter les erreurs liées aux autorisations, à la connectivité réseau à la source de métriques ou les messages indiquant que la métrique n'a pas pu être trouvée.

    • Si la valeur est True, passez à l'étape suivante.

  2. Interrogez directement l'API Metrics : si l'adaptateur est disponible, contournez HorizontalPodAutoscaler et demandez directement votre métrique à l'API Kubernetes. Cette commande teste l'intégralité du pipeline, du serveur d'API à l'adaptateur de métriques, en passant par la source de données.

    Pour interroger des métriques externes, exécutez la commande suivante :

    kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/METRIC_NAME" | jq .

    Pour interroger les métriques de pod personnalisées, exécutez la commande suivante :

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/pods/*/METRIC_NAME" | jq .

    Remplacez les éléments suivants :

    • NAMESPACE_NAME : espace de noms dans lequel vos pods sont exécutés.
    • METRIC_NAME : nom de la métrique personnalisée ou externe que vous essayez d'interroger. Par exemple, requests_per_second ou queue_depth.

  3. Analysez le résultat de la commande : le résultat des commandes précédentes vous indique où se situe le problème. Choisissez le scénario qui correspond à votre résultat :

    • Réponse JSON réussie avec une valeur : le pipeline de métriques fonctionne correctement. Le problème est probablement lié à un problème de configuration dans votre fichier manifeste HorizontalPodAutoscaler. Vérifiez si le nom de la métrique comporte des fautes d'orthographe ou si matchLabels est incorrect.

    • Error: Error from server (Service Unavailable) : cette erreur indique généralement un problème de connectivité réseau, souvent lié à un pare-feu dans les clusters qui utilisent l'isolation réseau.

      1. Identifiez le service d'adaptateur de métriques. Il se trouve généralement dans l'espace de noms custom-metrics ou kube-system :

        kubectl get service -n custom-metrics,kube-system | grep -E 'adapter|metrics'

      2. Recherchez le port sur lequel l'adaptateur écoute :

        kubectl get service ADAPTER_SERVICE -n ADAPTER_NAMESPACE -o yaml

        Remplacez les éléments suivants :

        • ADAPTER_SERVICE : nom du service Kubernetes associé à l'adaptateur de métriques que vous avez déployé. Ce service est celui que vous avez trouvé à l'étape précédente. Ce service expose les fonctionnalités de l'adaptateur à d'autres parties du cluster, y compris au serveur d'API Kubernetes.
        • ADAPTER_NAMESPACE : espace de noms dans lequel réside le service d'adaptateur (par exemple, custom-metrics ou kube-system).

      3. Recherchez les règles de pare-feu entrantes pour le plan de contrôle de votre cluster :

        gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master"

        Remplacez CLUSTER_NAME par le nom de votre cluster.

      4. Ajoutez le targetPort de l'adaptateur à la règle :

        1. Décrivez la règle actuelle pour afficher les ports autorisés existants :

          gcloud compute firewall-rules describe FIREWALL_RULE_NAME

          Remplacez FIREWALL_RULE_NAME par le nom de la règle de pare-feu qui régit le trafic réseau vers le plan de contrôle de votre cluster Kubernetes.

        2. Mettez à jour la règle pour ajouter le port de l'adaptateur à la liste :

          gcloud compute firewall-rules update FIREWALL_RULE_NAME \
    --allow tcp:443,tcp:10250,tcp:ADAPTER_PORT

          Remplacez ADAPTER_PORT par le port réseau sur lequel l'adaptateur de métriques est à l'écoute.

      5. Assurez-vous que les règles de réseau Kubernetes ne bloquent pas le trafic vers les pods de l'adaptateur de métriques :

        kubectl get networkpolicy -n custom-metrics,kube-system

        Examinez les éventuelles règles pour vous assurer qu'elles autorisent le trafic entrant du plan de contrôle ou du serveur d'API vers ADAPTER_SERVICE sur ADAPTER_PORT.

    • Une liste vide [] : cette sortie signifie que l'adaptateur est en cours d'exécution, mais qu'il ne peut pas récupérer la métrique spécifique, ce qui indique un problème avec la configuration de l'adaptateur ou avec la source de métrique elle-même.

      • Problèmes liés au pod de l'adaptateur : inspectez les journaux du pod ou des pods de l'adaptateur de métriques pour détecter les erreurs liées aux appels d'API, à l'authentification ou à la récupération des métriques. Pour inspecter les journaux, procédez comme suit :

        1. Recherchez le nom du pod de l'adaptateur :

          kubectl get pods -n ADAPTER_NAMESPACE

        2. Affichez ses journaux :

          kubectl logs ADAPTER_POD_NAME \
    -n ADAPTER_NAMESPACE

          Remplacez les éléments suivants :

          • ADAPTER_POD_NAME : nom du pod d'adaptateur que vous avez identifié à l'étape précédente.
          • ADAPTER_NAMESPACE : espace de noms dans lequel réside le pod de l'adaptateur (par exemple, custom-metrics ou kube-system).

      • Aucune donnée à la source : il est possible que la métrique n'existe pas dans le système source. Utilisez un outil de surveillance, tel que l'explorateur de métriques, pour vérifier que la métrique existe et qu'elle porte le bon nom et les bons libellés.

Résoudre les problèmes liés à l'autoscaler horizontal de pods qui n'effectue pas de scaling à la baisse

Cette section vous aide à comprendre pourquoi un HorizontalPodAutoscaler peut ne pas réduire la taille de votre charge de travail comme prévu.

Symptômes :

L'HorizontalPodAutoscaler augmente correctement la capacité de la charge de travail, mais ne parvient pas à la réduire, même lorsque les métriques telles que l'utilisation du processeur sont faibles.

Cause :

Ce comportement est conçu pour empêcher une mise à l'échelle rapide ou une réduction de la capacité basée sur des informations incomplètes. Voici les deux principales raisons :

  • Utiliser plusieurs métriques : l'autoscaler horizontal de pods effectue la mise à l'échelle en fonction de la métrique nécessitant le plus grand nombre de réplicas. Si vous avez plusieurs métriques, la charge de travail ne sera pas réduite, sauf si toutes les métriques indiquent qu'un nombre inférieur de réplicas est nécessaire. Si une métrique exige un nombre élevé de réplicas, le scaling à la baisse est impossible, même si les autres métriques sont faibles.
  • Métriques indisponibles : si une métrique devient indisponible (souvent indiquée par <unknown>), l'autoscaler horizontal de pods refuse de réduire la taille de la charge de travail par précaution. Il ne peut pas déterminer si la métrique est manquante parce que l'utilisation est réellement nulle ou parce que le pipeline de métriques est défaillant. Ce problème est courant avec les métriques personnalisées basées sur le taux (par exemple, messages_per_second), qui peuvent cesser de générer des rapports sur les données en l'absence d'activité. L'Autoscaler horizontal de pods considère alors la métrique comme indisponible et interrompt les opérations de scaling à la baisse.
  • Délai de réduction de la capacité à partir de la règle de scaling : le champ behavior de HorizontalPodAutoscaler vous permet de configurer des règles de scaling. La stratégie par défaut de réduction de la capacité inclut une fenêtre de stabilisation de 300 secondes (cinq minutes). Pendant cette période, HorizontalPodAutoscaler ne réduira pas le nombre de répliques, même lorsque les valeurs des métriques seront inférieures au seuil cible. Cette fenêtre empêche les fluctuations rapides, mais peut ralentir la réduction de la capacité par rapport aux attentes.

Solution :

Essayez les solutions suivantes :

  1. Pour plusieurs métriques et les métriques indisponibles, diagnostiquez la métrique qui pose problème :

    kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

    Dans le résultat, recherchez dans la section Metrics les métriques dont l'état est <unknown>, et dans la section Events les avertissements tels que FailedGetCustomMetric ou FailedGetExternalMetric. Pour déboguer le pipeline en détail, consultez la section Résoudre les problèmes liés aux métriques personnalisées et externes.

  2. Si une métrique devient indisponible pendant les périodes de faible trafic (ce qui est fréquent avec les métriques basées sur des taux), essayez l'une des solutions suivantes :

    • Dans la mesure du possible, utilisez des métriques basées sur des jauges plutôt que sur des taux. Une métrique de type "gauge", telle que le nombre total de messages dans une file d'attente (par exemple, subscription ou num_undelivered_messages), indique toujours une valeur, même si cette valeur est 0, ce qui permet à l'autoscaler horizontal de pods de prendre des décisions de scaling de manière fiable.
    • Assurez-vous que la source de votre métrique indique des valeurs nulles. Si vous contrôlez la métrique personnalisée, configurez-la pour qu'elle publie un 0 pendant les périodes d'inactivité au lieu de n'envoyer aucune donnée.

  3. Pour les délais de réduction de la capacité à partir de la règle de scaling, si la période de stabilisation par défaut de cinq minutes pour les réductions de la capacité est trop longue, personnalisez-la. Inspectez la section spec.behavior.scaleDown de votre fichier manifeste HorizontalPodAutoscaler. Vous pouvez réduire stabilizationWindowSeconds pour permettre à l'autoscaler de réduire la taille du groupe plus rapidement après la baisse des métriques. Pour en savoir plus sur la configuration de ces règles, consultez Règles de scaling dans la documentation Kubernetes.

Étapes suivantes