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

Autopilot Standard

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 de votre 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 d'erreurs de configuration initiales dans vos objets HorizontalPodAutoscaler ou de défaillances 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 les 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 avec autoscaling. 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.

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, par exemple les DaemonSets.

• Pour obtenir les autorisations nécessaires pour résoudre les problèmes d'autoscaling horizontal des pods dans GKE, ce qui inclut l'inspection des objets HorizontalPodAutoscaler et l'affichage des journaux de cluster, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

  • Inspecter les ressources GKE : Lecteur GKE (roles/container.viewer)
  • Afficher les journaux du cluster : Visionneuse de journaux (roles/logging.viewer)

  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 qu'il communique 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 .

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 Google Cloud .

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 : 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 défaillant.
• Conditions : 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 : consigne 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 d'erreur ou des raisons 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 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 de développement pour HorizontalPodAutoscaler.

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

5. Examinez 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 configuré pour mettre à l'échelle.
  • minReplicas et maxReplicas : paramètres d'instances répliquées minimales et maximales.
  • metrics : métriques configurées pour le scaling (par exemple, l'utilisation du processeur ou des 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'autoscaler horizontal de pods :
    • 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.

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 journal pour trouver tous les événements HorizontalPodAutoscaler d'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 d'autoscaling horizontal des pods : ces journaux fournissent des journaux structurés et lisibles par l'homme 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 de HorizontalPodAutoscaler

Les sections suivantes traitent des erreurs de configuration dans le fichier manifeste HorizontalPodAutoscaler, comme 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 (par exemple, 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 l'objet 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, l'objet HorizontalPodAutoscaler la trouve automatiquement une fois qu'elle est disponible, et l'erreur est 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éplicas 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 vous avez indiqué 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 la 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é 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é à partir du 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é d'étiquette valide et filtrable, 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 d'instances répliquées 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 affichez des événements, vous pouvez voir des événements SuccessfulRescale alternés ou contradictoires provenant de différents objets HorizontalPodAutoscaler.

Cause

Ce problème se produit lorsqu'au moins deux 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 sont en 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 cet HorizontalPodAutoscaler que vous allez modifier.
   2. Examinez la section spec.metrics dans le fichier manifeste de chacun des autres objets HorizontalPodAutoscaler qui ciblent 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'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 erreurs liées 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.

Requêtes 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

Le HorizontalPodAutoscaler doit calculer l'utilisation des ressources sous forme de pourcentage pour effectuer le scaling de la charge de travail, mais il ne peut pas effectuer ce calcul, car au moins un conteneur de la spécification du pod ne dispose pas d'une 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 à celui-ci s'affiche :

unable to fetch pod metrics for pod

Il est normal de voir ce message temporairement lorsque le serveur de métriques démarre.

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, HorizontalPodAutoscaler ne peut pas effectuer les calculs dont il a besoin et n'effectue aucune action liée à 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 :

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 est <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 le moyen le plus direct de 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. Interroger 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.

   Remarque : Les commandes suivantes utilisent le processeur JSON jq pour imprimer la sortie JSON. Si jq n'est pas installé, vous pouvez supprimer la section | jq . des commandes pour afficher la réponse JSON brute.

   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 pods 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, qui est souvent un problème de 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 le 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 :

        Attention : La commande suivante remplace les ports autorisés existants. Pour éviter de perturber le fonctionnement du cluster, vous devez inclure les ports existants (généralement tcp:443 pour l'API Kubernetes et tcp:10250 pour l'agent kubelet) plus le port ADAPTER_PORT.

        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 é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 [] : 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 aux pods de l'adaptateur : inspectez les journaux 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 de l'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 rupture de 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) ne sont pas opérationnels, 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 Google Cloud , affichez l'état et l'état de votre cluster.

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

         Accéder à la page "Clusters Kubernetes"

   2. Consultez les colonnes État et Notifications de 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 Cloud Audit Logs pour détecter d'éventuelles erreurs liées aux composants du plan de contrôle. Pour savoir comment afficher ces journaux, consultez Informations sur les journaux d'audit de 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 qu'ils 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 s'il présente un nombre élevé de redémarrages, examinez le pod pour en trouver la cause. Pour obtenir des conseils de dépannage, consultez la section Déboguer des 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 Metrics 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, par exemple 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érifier les autorisations : vérifiez 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 d'identifier les erreurs explicites liées à l'émission de métriques, telles que les échecs de connexion, les identifiants non valides ou les 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 n'effectue pas de scaling

Symptômes

L'HorizontalPodAutoscaler semble en bon état, ses conditions indiquent True et aucun événement d'erreur n'est affiché. 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 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. Le scaling n'est effectué que si le ratio entre la métrique actuelle et la métrique cible est 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, HorizontalPodAutoscaler ne procède pas à un scaling à la hausse.
• Pods non prêts : l'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 le scaling.
• Délai de la période de synchronisation : le contrôleur HorizontalPodAutoscaler vérifie régulièrement les métriques. 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 des nouvelles métriques : 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 est dû au fait que le système de surveillance (tel que Cloud Monitoring) doit créer la 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 répliquées requis pour chaque métrique indépendamment, puis choisit la valeur calculée la plus élevée comme nombre final d'instances répliquées. En raison de ce comportement, votre charge de travail évolue 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, HorizontalPodAutoscaler 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 le fichier manifeste HorizontalPodAutoscaler ou dans la sortie de la commande kubectl describe. Ajustez ces limites si elles empêchent la mise à l'échelle nécessaire.
• Fenêtre de tolérance : si un scaling est requis dans la 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 : déterminez 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 d'aptitude qui échouent). Pour obtenir des conseils de dépannage, consultez Déboguer les pods dans la documentation de Kubernetes.
• Délai de synchronisation et latence des nouvelles métriques : 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 : il s'agit du comportement attendu. 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 CPU).

Échec du scaling à la baisse de HorizontalPodAutoscaler

Symptômes

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

Cause

Ce comportement est conçu pour empêcher une mise à l'échelle rapide à la hausse ou à la baisse, ou une mise à l'échelle à la baisse basée sur des informations incomplètes. Les principales raisons sont les suivantes :

• Utiliser plusieurs métriques : HorizontalPodAutoscaler effectue un scaling en fonction de la métrique nécessitant le plus grand nombre de répliques. 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é d'instances répliquées, 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'HorizontalPodAutoscaler refuse de manière conservatrice de réduire la taille de 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 générer des données lorsqu'il n'y a pas d'activité, ce qui amène HorizontalPodAutoscaler à considérer la métrique comme indisponible et à interrompre 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 règle par défaut pour le scaling à la baisse inclut une période de stabilisation de 300 secondes (cinq minutes). Pendant cette période, HorizontalPodAutoscaler ne réduit pas le nombre de répliques, même lorsque les valeurs des métriques sont tombées en dessous du seuil cible. Cette fenêtre empêche les fluctuations rapides, mais peut ralentir la réduction de la capacité par rapport aux prévisions.

Solution

Essayez les solutions suivantes :

1. Pour plusieurs métriques et 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 toute métrique 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. Pour les métriques indisponibles, si une métrique devient indisponible pendant les périodes de faible trafic (courant avec les métriques basées sur le 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 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 d'échelle à partir de la règle de scaling, si l'intervalle de stabilisation par défaut de cinq minutes pour les réductions d'échelle est trop long, personnalisez-le. Inspectez la section spec.behavior.scaleDown de votre fichier manifeste HorizontalPodAutoscaler. Vous pouvez réduire stabilizationWindowSeconds pour permettre à l'autoscaler d'effectuer un scaling à la baisse 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.

Résoudre les problèmes de scaling des charges de travail GKE vers et depuis zéro à l'aide de AHP

Cette section vous aide à diagnostiquer les problèmes lors de la configuration des charges de travail pour effectuer un scaling à zéro et inversement à l'aide de HPA (minReplicas: 0) dans GKE 1.37 ou version ultérieure.

La charge de travail n'est pas mise à l'échelle à zéro

Si votre charge de travail reste à une ou plusieurs répliques lorsque la demande tombe à zéro, vérifiez les points suivants :

1. Vérifiez minReplicas : assurez-vous que la paire champ-valeur minReplicas: 0 est définie dans votre fichier manifeste HorizontalPodAutoscaler.
2. Vérifiez les types de métriques : l'AHP ne peut pas effectuer de scaling à zéro s'il n'utilise que des métriques de processeur ou de mémoire (Resource). Vous devez configurer au moins une métrique External ou Object.
3. Vérifiez plusieurs métriques : le AHP effectue un scaling en fonction de la métrique nécessitant le plus grand nombre de répliques. Si vous configurez plusieurs métriques, la charge de travail ne passe pas à zéro, sauf si chaque métrique surveillée est égale à zéro.
4. Attendez la période de stabilisation du scaling à la baisse : par défaut, GKE attend cinq minutes (scaleDown.stabilizationWindowSeconds: 300) de demande continue nulle avant de passer d'une à zéro réplique.
5. Vérifiez si des métriques sont indisponibles : si la valeur d'une métrique est <unknown>, l'AHP suspend les opérations de réduction de la taille pour éviter un scaling à la baisse prématuré. Pour en savoir plus, consultez Résoudre les problèmes d'échec de scaling à la baisse de l'autoscaler horizontal de pods.

La charge de travail n'effectue pas de scaling à la hausse à partir de zéro

Si votre charge de travail reste à zéro instance répliquée lorsque la demande augmente, vérifiez les points suivants :

1. Inspectez HorizontalPodAutoscaler : exécutez la commande kubectl describe hpa HPA_NAME et vérifiez les sections suivantes dans le résultat :

   • Section "Métriques" : vérifiez que la valeur de la métrique est supérieure à zéro et qu'elle n'est pas affichée sous la forme <unknown>. Si la métrique est manquante ou ne se met pas à jour, vérifiez que la source externe (comme Pub/Sub) publie des événements et que Cloud Monitoring les reçoit.
   • Section Conditions :
     • État sain avec zéro réplica : vérifiez que les conditions affichent AbleToScale: True, ScalingActive: True et ScaledToZero: True (avec le motif ScaledToZero). Dans cet état, GKE augmente automatiquement la taille de la charge de travail lorsque la demande augmente.
     • Remplacement externe détecté : vérifiez si la valeur de la condition ScalingActive est False avec le motif ScalingDisabledExternalScaleToZero ou ScalingDisabledReplicaCountZero, ce qui indique que la charge de travail a été manuellement mise à l'échelle zéro. Par exemple, la charge de travail a été mise à l'échelle manuellement avec la commande kubectl scale, ce qui suspend l'autoscaling pour éviter les modifications incompatibles.

   • Résolution : pour reprendre le scaling automatique, effectuez manuellement le scaling du déploiement sur une ou plusieurs répliques :

     kubectl scale deployment DEPLOYMENT_NAME --replicas=1
     

2. Vérifiez la latence de démarrage à froid : si la charge de travail démarre lentement, le provisionnement des nœuds peut ajouter un délai. Pour vous assurer que la capacité de calcul de secours est prête lors du scaling à partir de zéro, pensez à utiliser des tampons de capacité.

Étapes suivantes

• Si vous ne trouvez pas de solution à votre problème dans la documentation, consultez Obtenir de l'aide pour bénéficier d'une assistance supplémentaire, y compris des conseils sur les sujets suivants :

  • Ouvrir une demande d'assistance en contactant Cloud Customer Care.
  • Obtenir de l'aide de la communauté en posant des questions sur Stack Overflow et en utilisant le tag google-kubernetes-engine pour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack #kubernetes-engine pour obtenir une assistance supplémentaire de la communauté.
  • Signaler des problèmes ou demander des fonctionnalités à l'aide de l'outil public de suivi des problèmes.