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), vos charges de travail peuvent ne pas être 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 HorizontalPodAutoscaler ou que les opérations de scaling ne se produisent pas du tout.

Utilisez ce document 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 HorizontalPodAutoscaler.

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 Cloud de Confiance by S3NS , consultez Rôles utilisateur et tâches courantes de GKE.

Avant de commencer

  • Assurez-vous d'utiliser des objets HorizontalPodAutoscaler avec des charges de travail évolutives, telles que les déploiements et les 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 pour inspecter les objets HorizontalPodAutoscaler et afficher les journaux de 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 Cloud de Confiance by S3NS .

Diagnostiquer les problèmes liés à HorizontalPodAutoscaler

Pour diagnostiquer les problèmes liés à un HorizontalPodAutoscaler, inspectez l'état et la configuration à l'aide des commandes kubectl ou de la console Cloud de Confiance .

Décrire HorizontalPodAutoscaler

Pour afficher les calculs en temps réel et les décisions de scaling récentes, utilisez la commande kubectl describe hpa :

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
Namespace:                                             default
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 (tableau) : affiche les valeurs actuelles des métriques par rapport à leurs cibles. 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 : indique si HorizontalPodAutoscaler peut récupérer les métriques (AbleToScale) et effectuer des calculs de scaling (ScalingActive). Un état False dans l'une de ces conditions indique un échec.
  • Events : enregistre les actions de scaling récentes, les avertissements et les erreurs 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.

Vérifier votre fichier manifeste 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 Cloud de Confiance , 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'autoscaler horizontal de pods est configuré pour mettre à l'échelle.
    • minReplicas et maxReplicas : paramètres de réplique minimale et maximale.
    • metrics : métriques configurées pour le scaling (par exemple, utilisation du processeur ou 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 : affiche l'état de l'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'autoscaler horizontal de pods souhaite effectuer un scaling, mais est limité par vos paramètres minReplicas ou maxReplicas.

Afficher les journaux d'événements

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

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

    1. Dans la console Cloud de Confiance , 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 d'autoscaling horizontal des pods : ces journaux fournissent des journaux structurés et lisibles par l'utilisateur qui expliquent comment l'HorizontalPodAutoscaler calcule une recommandation, offrant ainsi un aperçu détaillé de son processus de prise de décision.

Résoudre les erreurs de configuration d'HorizontalPodAutoscaler

Les sections suivantes traitent des erreurs de configuration dans le fichier manifeste HorizontalPodAutoscaler, telles que des champs mal saisis, des cibles de métriques non valides ou des configurations conflictuelles.

Charge de travail cible introuvable

Symptômes

La section Events comporte 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 se produit en raison d'une erreur de configuration 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 intentionnellement supprimé la charge de travail, supprimez l'objet HorizontalPodAutoscaler correspondant pour nettoyer votre cluster. Si vous devez recréer la charge de travail, l'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 que votre charge de travail se trouve dans un autre espace de noms, 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.

Métriques non valides

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.

Le libellé de métrique 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é d'étiquette 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é d'étiquette dans la section metric.selector.matchLabels de votre fichier manifeste HorizontalPodAutoscaler.
  3. Pour trouver une clé d'étiquette filtrable valide, consultez la documentation Cloud Monitoring pour cette métrique.

Plusieurs HorizontalPodAutoscalers ciblent la même charge de travail

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 seul HorizontalPodAutoscaler.
  • 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, car plusieurs objets HorizontalPodAutoscaler du même espace de noms spécifient exactement la même charge de travail dans le champ spec.scaleTargetRef. Chaque HorizontalPodAutoscaler calcule indépendamment le nombre de répliques 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 de ces champs 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. Regroupez 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 aux charges de travail et aux services

Les sections suivantes traitent des erreurs causées par la charge de travail cible ou ses services associés, plutôt que par l'objet HorizontalPodAutoscaler lui-même.

Demandes de ressources manquantes pour le calcul du scaling

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

HorizontalPodAutoscaler doit calculer l'utilisation des ressources en pourcentage pour mettre à l'échelle 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 faire évoluer tous les conteneurs du pod. Exemple :

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
# Multiple lines are omitted here
spec:
  containers:
  - name: example-container
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Impossible de récupérer les métriques du pod

Symptômes

Un message persistant semblable au suivant 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, vérifiez que vous avez spécifié des requêtes de ressources pour chaque conteneur de votre charge de travail.

Plusieurs services sélectionnent la même cible

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 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"} correspondent 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 concerné 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.

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 de communiquer avec une API de métriques ou d'interroger un backend de métriques.

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'API Kubernetes, adaptateur de métriques et 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

Pour vous aider à déboguer le pipeline, procédez comme suit :

  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 et 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 est introuvable.

    • 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 de l'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 règles pour vérifier 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 [] : ce résultat 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.

Versions de métriques introuvables ou adaptateur indisponible

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 sont pas en cours d'exécution ou ne sont pas correctement enregistrés auprès du serveur d'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 Cloud de Confiance , consultez l'état et l'état de santé 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.

    4. 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 redémarré 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 le nombre de redémarrages est élevé, examinez le pod pour en trouver la cause première. Pour obtenir des conseils de dépannage, consultez Déboguer les pods dans la documentation de 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 la valeur 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.

La requête de métrique ne renvoie 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 dans 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 HorizontalPodAutoscaler se sont produits.
  4. Recherchez les erreurs : consultez 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 de scaling opérationnel, mais inattendu

Les sections suivantes traitent des scénarios dans lesquels la configuration HorizontalPodAutoscaler est valide et les métriques sont disponibles, mais les actions de scaling ne se produisent pas comme prévu.

HorizontalPodAutoscaler est opérationnel, mais ne fait pas évoluer le nombre d'instances

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 expliquer ce comportement attendu :

  • Limites d'instances dupliquées : le nombre actuel d'instances dupliquées a déjà atteint 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'objet HorizontalPodAutoscaler ne procède pas à un scaling à la hausse.
  • Pods non prêts : HorizontalPodAutoscaler 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 moment où une action de scaling est lancée.
  • 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, HorizontalPodAutoscaler 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 s'adapte 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éplicas, mais qu'une métrique de requêtes par seconde calcule un besoin de 15, HorizontalPodAutoscaler met à l'échelle le déploiement à 15 réplicas.

Solution

Essayez les solutions suivantes :

  • Limites de répliques : vérifiez les valeurs minReplicas et maxReplicas dans le 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 comprise entre 0,9 et 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 nouvelle série temporelle de 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).

Échec du scaling à la baisse de HorizontalPodAutoscaler

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 éviter un scaling rapide à la hausse ou à la baisse, ou un scaling à la baisse basé sur des informations incomplètes. Voici les principales raisons :

  • Utilisation de plusieurs métriques : l'autoscaler horizontal de pods effectue le scaling en fonction de la métrique nécessitant le plus grand nombre d'instances dupliquées. Si vous avez plusieurs métriques, la charge de travail ne sera réduite que 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 de pods horizontaux refuse de manière conservatrice de réduire la charge de travail. 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 signaler des données en l'absence d'activité, ce qui fait que l'objet HorizontalPodAutoscaler considère la métrique comme indisponible et interrompt les opérations de réduction de la capacité.
  • Délai de réduction de la taille à partir de la règle de scaling : le champ behavior de HorizontalPodAutoscaler vous permet de configurer des règles de scaling. La stratégie de scaling à la baisse par défaut inclut une fenêtre de stabilisation de 300 secondes (cinq minutes). Pendant cette période, l'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 taille du pool 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 un 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 à HorizontalPodAutoscaler de prendre des décisions de scaling de manière fiable.
    • Assurez-vous que votre source de 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 règle de scaling, si la période de stabilisation par défaut de cinq minutes pour les réductions 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 cluster plus rapidement après une 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