Gérer les métriques GKE

Google Kubernetes Engine (GKE) facilite l'envoi de métriques à Cloud Monitoring. Une fois dans Cloud Monitoring, les métriques peuvent permettre de renseigner des tableaux de bord personnalisés, générer des alertes et créer des objectifs de niveau de service, ou elles peuvent être récupérés par des services de surveillance tiers à l'aide de l'API Monitoring.

G​K​E fournit deux sources de métriques :

• Métriques définies par le système : métriques issues des composants système essentiels, décrivant les ressources de bas niveau telles que le processeur, la mémoire et le stockage.
• Métriques liées aux charges de travail : métriques exposées par n'importe quelle charge de travail G​K​E (telle qu'une tâche cron ou un déploiement pour une application).

Métriques définies par le système

Lorsqu'un cluster est créé, G​K​E collecte par défaut certaines métriques émises par les composants système.

Vous pouvez choisir d'envoyer ou non les métriques de votre cluster G​K​E à Cloud Monitoring. Si vous choisissez d'envoyer des métriques à Cloud Monitoring, vous devez envoyer des métriques système.

Toutes les métriques G​K​E définies par le système sont ingérées dans Cloud Monitoring avec le préfixe kubernetes.io.

Tarifs

Cloud Monitoring ne facture pas l'ingestion de métriques système G K E. En savoir plus sur les tarifs de Cloud Monitoring.

Configurer la collecte de métriques définies par le système

Pour activer la collecte de métriques définies par le système, transmettez la valeur SYSTEM à l'option --monitoring de la commande gcloud container clusters create ou gcloud container clusters update.

Pour désactiver la collecte de métriques définies par le système, utilisez la valeur NONE pour l'option --monitoring. Si la collecte de métriques définies par le système est désactivée, les informations de base telles que l'utilisation du processeur, de la mémoire et du disque ne sont pas disponibles pour un cluster dans lesection G​K​E de Cloud Console. De plus, le tableau de bord G​K​E de Cloud Monitoring ne contient pas d'informations sur le cluster.

Remarque : Pour les clusters GKE Autopilot, vous ne pouvez pas désactiver la collecte des métriques définies par le système.

Consultez la section Configurer Cloud Operations pour GKE pour obtenir plus d'informations sur l'intégration de Cloud Monitoring à G​K​E.

Liste des métriques définies par le système

Les métriques définies par le système incluent des métriques provenant des composants système essentiels pour les fonctionnalités principales de Kubernetes. Consultez la liste complète des métriques système.

Métriques liées aux charges de travail

Aperçu

Ce produit ou cette fonctionnalité est couvert par les Conditions des offres avant disponibilité générale des conditions d'utilisation de Google Cloud Platform. Les fonctionnalités et produits avant disponibilité générale sont susceptibles de présenter une compatibilité limitée, et les modifications apportées à ces fonctionnalités ou produits peuvent ne pas être compatibles avec d'autres versions avant disponibilité générale. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Les métriques liées aux charges de travail G​K​E sont la méthode recommandée par Google pour surveiller les applications Kubernetes à l'aide de Cloud Monitoring.

G​K​E 1.20.8-gke.2100 ou une version ultérieure propose un pipeline de collecte de métriques entièrement géré pour scraper les métriques de style Prometheus exposées par toute charge de travail G​K​E (telle qu'une tâche cron ou déploiement pour une application) et envoyer ces métriques à Cloud Monitoring.

Toutes les métriques collectées par le pipeline de métriques liées aux charges de travail G​K​E sont ingérées dans Cloud Monitoring avec le préfixe workload.googleapis.com.

Avantages des métriques liées aux charges de travail G​K​E :

• Configuration facile : une commande kubectl permettant de déployer une ressource personnalisée PodMonitor suffit pour commencer à collecter des métriques. Aucune installation manuelle d'un agent n'est nécessaire.
• Haute configuration : ajustez les points de terminaison scrapés, la fréquence et d'autres paramètres.
• Entièrement géré : Google gère le pipeline afin que vous puissiez vous concentrer sur vos applications.
• Contrôle des coûts : gérez facilement les coûts Cloud Monitoring grâce au filtrage flexible des métriques.
• Standard ouvert : configurez les métriques liées aux charges de travail à l'aide de la ressource personnalisée PodMonitor, modélisée à partir de la ressource PodMonitor de l'opérateur Prometheus.
• Compatibilité AHP : compatible avec l'adaptateur de métriques personnalisées Stackdriver pour permettre le scaling horizontal sur les métriques personnalisées.
• Meilleurs tarifs : tarifs plus intuitifs, prévisibles et économiques.
• Compatibilité avec Autopilot : compatible avec les clusters G​K​E Standard et G​K​E Autopilot.

Exigences

Les métriques liées aux charges de travail G​K​E nécessitent la version 1.20.8-gke.2100 ou ultérieure du plan de contrôle G​K​E et ne sont pas compatibles avec les charges de travail G​K​E Windows.

Si vous activez le pipeline de métriques liées aux charges de travail, vous devez également activer la collecte des métriques définies par le système.

Étape 1 : Activez le pipeline de métriques liées aux charges de travail

Pour activer le pipeline de collecte de métriques de charge de travail dans un cluster G​K​E existant, procédez comme suit :

CONSOLE

1. Dans Google Cloud Console, accédez à la liste des clusters GKE :

   Accéder à la page "Clusters Kubernetes"

2. Cliquez sur le nom de votre cluster.

3. Sur la ligne intitulée "Cloud Monitoring", cliquez sur l'icône Modifier.

4. Dans la boîte de dialogue "Modifier Cloud Monitoring" qui s'affiche, vérifiez que l'option Activer Cloud Monitoring est sélectionnée.

5. Dans le menu déroulant, sélectionnez Charges de travail.

6. Cliquez sur OK.

7. Cliquez sur Save Changes (Enregistrer les modifications).

GCLOUD

1. Ouvrez une fenêtre de terminal avec le SDK Cloud et l'outil de ligne de commande gcloud installés. L'une des méthodes consiste à utiliser Cloud Shell :

2. Dans Cloud Console, activez Cloud Shell.

   Activer Cloud Shell

   En bas de la fenêtre de Cloud Console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel le SDK Cloud est déjà installé (y compris l'outil de ligne de commande gcloud), et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

3. Exécutez cette commande :

   gcloud beta container clusters update [CLUSTER_ID] \
     --zone=[ZONE] \
     --project=[PROJECT_ID] \
     --monitoring=SYSTEM,WORKLOAD
   

   Inclure la valeur WORKLOAD de l'option --monitoring des commandes gcloud beta container clusters create ou gcloud beta container clusters update active les pipelines de collecte de métriques de charge de travail.

   Remarque : Les métriques liées aux charges de travail GKE sont actuellement en version bêta. Par conséquent, veillez à utiliser les commandes gcloud beta.

L'activation du pipeline de collecte de métriques liées aux charges de travail a pour effet de déployer un agent de collecte de métriques sur chaque nœud capable de collecter des métriques d'application émises par les charges de travail Kubernetes.

Consultez la section Configurer Cloud Operations pour GKE pour obtenir plus d'informations sur l'intégration de Cloud Monitoring à G​K​E.

Étape 2 : Configurez les métriques à collecter

1. Créez une ressource personnalisée PodMonitor nommée my-pod-monitor.yaml :

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  # POD_MONITOR_NAME is how you identify your PodMonitor
  name: [POD_MONITOR_NAME]
  # POD_NAMESPACE is the namespace where your workload is running, and the
  # namespace of your PodMonitor object
  namespace: [POD_NAMESPACE]
spec:
  # POD_LABEL_KEY and POD_LABEL_VALUE identify which pods to collect metrics
  # from. For example, POD_LABEL_KEY of app.kubernetes.io/name and
  # POD_LABEL_VALUE of mysql would collect metrics from all pods with the label
  # app.kubernetes.io/name=mysql
  selector:
    matchLabels:
      [POD_LABEL_KEY]: [POD_LABEL_VALUE]
  podMetricsEndpoints:
    # CONTAINER_PORT_NAME is the name of the port of the container to be scraped
    # Use the following command to list all ports exposed by the container:
    # kubectl get pod [POD_NAME] -n [POD_NAMESPACE] -o json | jq '.items[].spec.containers[].ports[]?' | grep -v null
    # If the port for your metrics does not have a name, modify your application's pod spec
    # to add a port name.
  - port: [CONTAINER_PORT_NAME]

2. Initialisez les identifiants à l'aide de l'outil de ligne de commande gcloud afin de configurer kubectl :

gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]

3 Déployez la ressource personnalisée PodMonitor :

kubectl apply -f my-pod-monitor.yaml

Migrating (Migration)

Si vous utilisez déjà le side-car Stackdriver Prometheus, les métriques liées aux charges de travail G​K​E offrent de nombreuses améliorations. Il est fortement recommandé d'utiliser les métriques liées aux charges de travail G​K​E pour collecter les métriques émises par votre application. Consultez le guide de migration du side-car Stackdriver Prometheus vers les métriques de charge de travail G​K​E.

Tarifs

Les frais liés à Cloud Monitoring pour l'ingestion de métriques de charge de travail G K E sont basés sur le nombre d'échantillons ingérés. En savoir plus sur les tarifs de Cloud Monitoring.

Gérer les coûts

Pour gérer les coûts, commencez par déterminer les métriques liées aux charges de travail les plus utiles pour vos besoins de surveillance. Le pipeline de métriques liées aux charges de travail G​K​E fournit des contrôles précis pour obtenir le bon compromis entre la capture de métriques détaillées et la réduction des coûts.

De nombreuses applications exposent une grande variété de métriques Prometheus. Par défaut, le pipeline de métriques liées aux charges de travail G​K​E scrape toutes les métriques de chaque pod sélectionné toutes les 60 secondes.

Vous pouvez utiliser les techniques suivantes pour réduire le coût des métriques :

1. Ajuster la fréquence de scraping : pour réduire le coût des métriques, nous vous recommandons de réduire la fréquence de scraping le cas échéant. Par exemple, il est possible qu'un KPI (indicateur clé de performance) pertinent pour l'entreprise change suffisamment lentement pour être scrapé toutes les 10 minutes. Dans PodMonitor, définissez la valeur interval pour contrôler la fréquence de scraping.

2. Métriques de filtrage : identifiez les métriques non utilisées dans Cloud Monitoring, et utilisez metricRelabelings pour vous assurer que seules les métriques utiles pour les tableaux de bord, les alertes ou les SLO sont envoyées à Cloud Monitoring.

Voici un exemple concret de ressource personnalisée PodMonitor utilisant les deux techniques :

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: example
  podMetricsEndpoints:
  - port: metrics
    path: /metrics
    scheme: http

    # (1) scrape metrics less frequently than the default (once every 60s)
    interval: 10m

    metricRelabelings:

    - # (2) drop the irrelevant metric named "foo" and all metrics
      # with the prefix "bar_"
      sourceLabels: [__name__]
      regex: foo|bar_.*
      action: drop

    - # (3) keep only metrics with a subset of values for a particular label
      sourceLabels: [region]
      regex: us-.*
      action: keep

Pour identifier les métriques qui possèdent le plus grand nombre d'échantillons en cours d'ingestion, utilisez la métrique monitoring.googleapis.com/collection/attribution/write_sample_count :

1. Dans Cloud Console, sélectionnez Monitoring :

   Accéder à Monitoring

2. Dans le volet de navigation "Surveillance", cliquez sur Explorateur de métriques.

3. Dans le champ Métrique, sélectionnez monitoring.googleapis.com/collection/attribution/write_sample_count.

4. Vous pouvez éventuellement filtrer les métriques de charges de travail G K E uniquement :

   • Cliquez sur Ajouter un filtre.

   • Dans le champ Libellé, sélectionnez metric_domain.

   • Dans le champ Valeur, saisissez workload.googleapis.com.

   • Cliquez sur OK.

5. Vous pouvez également regrouper le nombre d'échantillons ingérés par l'espace de noms Kubernetes, la région G K E, le projet Google Cloud ou le type de ressource surveillée :

   • Cliquez sur Grouper par.

   • Pour regrouper les données par espace de noms Kubernetes, sélectionnez attribution_dimension et attribution_id.

   • Pour regrouper les données par région G K E, sélectionnez emplacement.

   • Pour regrouper les données par projet Cloud, sélectionnez resource_container.

   • Pour regrouper les données par type de ressource surveillée, sélectionnez resource_type.

6. Triez la liste des métriques par ordre décroissant en cliquant sur l'en-tête de colonne Valeur au-dessus de la liste des métriques.

Ces étapes montrent les métriques présentant le taux d'échantillons le plus élevé ingéré dans Cloud Monitoring. Étant donné que les métriques de charge de travail G K E sont facturées en fonction du nombre d'échantillons ingérés, prêtez une attention particulière aux métriques dont le taux d'échantillonnage est le plus élevé. Déterminez si vous pouvez réduire la fréquence de récupération de l'une de ces métriques ou si vous pouvez arrêter de les collecter.

Enfin, de nombreuses ressources sont disponibles pour comprendre le coût des métriques G​K​E ingérées dans Cloud Monitoring et pour optimiser ces coûts. Consultez le guide d'optimisation des coûts pour découvrir d'autres moyens de réduire les coûts liés à Cloud Monitoring.

Versions antérieures de G​K​E

Pour collecter des métriques d'application dans un cluster dont la version du plan de contrôle G​K​E est inférieure à 1.20.8-gke.2100, utilisez le side-car Stackdriver Prometheus.

Dépannage

Si les métriques liées aux charges de travail ne sont pas disponibles dans Cloud Monitoring comme prévu, voici quelques étapes à suivre pour résoudre le problème.

Vérifiez que votre cluster remplit les conditions minimales requises

Assurez-vous que votre cluster GKE exécute le plan de contrôle version 1.20.8-gke.2100 ou ultérieure. Si ce n'est pas le cas, mettez à niveau le plan de contrôle de votre cluster.

Vérifiez que les métriques liées aux charges de travail sont activées

Assurez-vous que votre cluster G​K​E est configuré pour activer le pipeline de collecte de métriques liées aux charges de travail en procédant comme suit :

CONSOLE

1. Dans Google Cloud Console, accédez à la liste des clusters GKE :

   Accéder à la page "Clusters Kubernetes"

2. Cliquez sur le nom de votre cluster.

3. Dans le panneau Informations détaillées de votre cluster, vérifiez que la charge de travail est incluse dans l'état de Cloud Monitoring. Si la charge de travail n'est pas affichée ici, activez les métriques de charge de travail.

GCLOUD

1. Ouvrez une fenêtre de terminal avec le SDK Cloud et gcloud installés. L'une des méthodes consiste à utiliser Cloud Shell :

2. Dans Cloud Console, activez Cloud Shell.

   Activer Cloud Shell

   En bas de la fenêtre de Cloud Console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel le SDK Cloud est déjà installé (y compris l'outil de ligne de commande gcloud), et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

3. Exécutez cette commande :

   gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
   

   Dans la sortie de cette commande, recherchez la ligne monitoringConfig:. Quelques lignes plus tard, vérifiez que la section enableComponents: inclut WORKLOADS. Si WORKLOADS n'apparaît pas ici, activez les métriques de charge de travail.

Vérifiez que les métriques sont collectées à partir de votre application

Si vous ne parvenez pas à afficher les métriques de votre application dans Cloud Monitoring, les étapes ci-dessous peuvent vous aider à résoudre les problèmes. Ces étapes utilisent un exemple d'application à des fins de démonstration, mais vous pouvez appliquer les mêmes étapes ci-dessous pour résoudre les problèmes de n'importe quelle application.

Les premières étapes ci-dessous déploient un exemple d'application que vous pouvez utiliser à des fins de test. Les étapes restantes indiquent les étapes à suivre pour résoudre les problèmes d'affichage des métriques de cette application dans Cloud Monitoring.

1. Créez un fichier nommé prometheus-example-app.yaml contenant les éléments suivants :

   # This example application exposes prometheus metrics on port 1234.
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: prom-example
     name: prom-example
     namespace: gke-workload-metrics
   spec:
     selector:
       matchLabels:
         app: prom-example
     template:
       metadata:
         labels:
           app: prom-example
       spec:
         containers:
         - image: nilebox/prometheus-example-app@sha256:dab60d038c5d6915af5bcbe5f0279a22b95a8c8be254153e22d7cd81b21b84c5
           name: prom-example
           ports:
           - name: metrics-port
             containerPort: 1234
           command:
           - "/main"
           - "--process-metrics"
           - "--go-metrics"
   

2. Initialisez les identifiants à l'aide de l'outil de ligne de commande gcloud afin de configurer kubectl :

   gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
   

3. Créez l'espace de noms gke-workload-metrics :

   kubectl create ns gke-workload-metrics
   

4. Déployez l'exemple d'application :

   kubectl apply -f prometheus-example-app.yaml
   

5. Vérifiez que l'exemple d'application est en cours d'exécution en exécutant la commande suivante :

   kubectl get pod -n gke-workload-metrics -l app=prom-example
   

   Le résultat devrait ressembler à ceci :

   NAME                            READY   STATUS    RESTARTS   AGE
   prom-example-775d8685f4-ljlkd   1/1     Running   0          25m
   

6. Vérifiez que votre application expose les métriques comme prévu.

   À l'aide de l'un des pods renvoyés par la commande ci-dessus, vérifiez que le point de terminaison des métriques fonctionne correctement :

   POD_NAME=prom-example-775d8685f4-ljlkd
   NAMESPACE=gke-workload-metrics
   PORT_NUMBER=1234
   METRICS_PATH=/metrics
   kubectl get --raw /api/v1/namespaces/$NAMESPACE/pods/$POD_NAME:$PORT_NUMBER/proxy/$METRICS_PATH
   

   Si vous utilisez l'exemple d'application ci-dessus, vous devriez obtenir un résultat semblable à celui-ci :

   # HELP example_random_numbers A histogram of normally distributed random numbers.
   # TYPE example_random_numbers histogram
   example_random_numbers_bucket{le="0"} 501
   example_random_numbers_bucket{le="0.1"} 1.75933011554e+11
   example_random_numbers_bucket{le="0.2"} 3.50117676362e+11
   example_random_numbers_bucket{le="0.30000000000000004"} 5.20855682325e+11
   example_random_numbers_bucket{le="0.4"} 6.86550977647e+11
   example_random_numbers_bucket{le="0.5"} 8.45755380226e+11
   example_random_numbers_bucket{le="0.6"} 9.97201199544e+11
   ...
   

7. Créez un fichier nommé my-pod-monitor.yaml contenant les éléments suivants :

   # Note that this PodMonitor is in the monitoring.gke.io domain,
   # rather than the monitoring.coreos.com domain used with the
   # Prometheus Operator.  The PodMonitor supports a subset of the
   # fields in the Prometheus Operator's PodMonitor.
   apiVersion: monitoring.gke.io/v1alpha1
   kind: PodMonitor
   metadata:
     name: example
     namespace: gke-workload-metrics
   # spec describes how to monitor a set of pods in a cluster.
   spec:
     # selector determines which pods are monitored.  Required
     # This example matches pods with the `app: prom-example` label
     selector:
       matchLabels:
         app: prom-example
     podMetricsEndpoints:
       # port is the name of the port of the container to be scraped.
     - port: metrics-port
       # path is the path of the endpoint to be scraped.
       # Default /metrics
       path: /metrics
       # scheme is the scheme of the endpoint to be scraped.
       # Default http
       scheme: http
       # interval is the time interval at which metrics should
       # be scraped. Default 60s
       interval: 20s
   

8. Créez la ressource PodMonitor :

   kubectl apply -f my-pod-monitor.yaml
   

   Une fois que vous avez créé la ressource PodMonitor, le pipeline de métriques liées aux charges de travail G​K​E détecte les pods appropriés et commence à les scraper automatiquement. Le pipeline envoie les métriques collectées à Cloud Monitoring.

9. Vérifiez que le libellé et l'espace de noms sont correctement définis dans PodMonitor. Mettez à jour les valeurs de NAMESPACE et SELECTOR ci-dessous afin de refléter le namespace et les matchLabels dans votre ressource personnalisée PodMonitor. Exécutez ensuite cette commande :

   NAMESPACE=gke-workload-metrics
   SELECTOR=app=prom-example
   kubectl get pods --namespace $NAMESPACE --selector $SELECTOR
   

   Vous devez obtenir un résultat semblable à celui-ci :

   NAME                            READY   STATUS    RESTARTS   AGE
   prom-example-7cff4db5fc-wp8lw   1/1     Running   0          39m
   

10. Vérifiez que le PodMonitor est à l'état "Ready" (Prêt).

    Exécutez la commande suivante pour renvoyer tous les PodMonitors que vous avez installés dans votre cluster :

    kubectl get podmonitor.monitoring.gke.io --all-namespaces
    

    Le résultat doit ressembler à ce qui suit :

    NAMESPACE              NAME      AGE
    gke-workload-metrics   example   2m36s
    

    Identifiez le PodMonitor approprié à partir de l'ensemble renvoyé et exécutez cette commande (en remplaçant example dans la commande ci-dessous par le nom de votre PodMonitor) :

    kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metrics
    

    Examinez les résultats renvoyés par kubectl describe et vérifiez que la condition "Ready" est définie sur "True". Si elle est définie sur "False", recherchez les événements qui peuvent expliquer cela.

11. Ensuite, vous allez vérifier que ces métriques sont bien reçues par Cloud Monitoring. Dans la section Cloud Monitoring de Google Cloud Console, accédez à l'Explorateur de métriques.

12. Dans le champ Métrique, saisissez example_requests_total.

13. Dans le menu déroulant qui s'affiche, sélectionnez workload.googleapis.com/example_requests_total.

    Cette métrique example_requests_total est l'une des métriques Prometheus générées par l'exemple d'application.

    Si le menu déroulant n'apparaît pas ou si vous ne voyez pas workload.googleapis.com/example_requests_total dans le menu déroulant, patientez quelques minutes, puis réessayez.

    Toutes les métriques sont associées à la ressource Kubernetes Container (k8s_container) à partir de laquelle elles sont collectées. Vous pouvez sélectionner k8s_container dans le champ Type de ressource de l'Explorateur de métriques. Vous pouvez également grouper par libellé, comme namespace_name ou pod_name.

    Cette métrique peut être utilisée n'importe où dans Cloud Monitoring ou interrogée via l'API Cloud Monitoring. Par exemple, pour ajouter ce graphique à un tableau de bord nouveau ou existant, cliquez sur le bouton Enregistrer le graphique dans l'angle supérieur droit et sélectionnez le tableau de bord souhaité dans une boîte de dialogue.

Recherchez les erreurs d'envoi à l'API Cloud Monitoring

Les métriques envoyées à Cloud Monitoring doivent respecter les limites de métriques personnalisées. Les erreurs sont consignées dans les journaux d'audit Cloud Monitoring.

À l'aide de l'Explorateur de journaux de Cloud Logging, recherchez les journaux avec ce filtre de journal (remplacez PROJECT_ID par le nom de votre projet) :

resource.type="audited_resource"
resource.labels.service="monitoring.googleapis.com"
protoPayload.authenticationInfo.principalEmail=~".*[e-mail]"
resource.labels.project_id="[PROJECT_ID]"
severity>=ERROR

Notez que cela permet d'afficher les erreurs de toutes les écritures dans Cloud Monitoring pour le projet, et pas seulement celles de votre cluster.

Vérifiez votre quota d'ingestion Cloud Monitoring

1. Accédez à la page "Quotas de l'API Cloud Monitoring".
2. Sélectionnez le projet approprié.
3. Développez la section Requêtes d'ingestion de séries temporelles.
4. Vérifiez que le nombre d'erreurs de dépassement de quota pour le nombre de requêtes d'ingestion de séries temporelles par minute est défini sur 0. (Si c'est le cas, le graphique "Nombre d'erreurs liées au dépassement de quota" indique "Aucune donnée disponible pour la période sélectionnée".)
5. Si le pourcentage d'utilisation maximale dépasse 100 %, envisagez de sélectionner moins de pods, de sélectionner moins de métriques ou de demander une limite de quota plus élevée pour le quota monitoring.googleapis.com/ingestion_requests.

Vérifiez que le DaemonSet est déployé

Assurez-vous que le DaemonSet des métriques liées aux charges de travail est déployé dans votre cluster. Vous pouvez vérifier que cela fonctionne comme prévu en utilisant kubectl :

1. Initialisez les identifiants à l'aide de l'outil de ligne de commande gcloud afin de configurer kubectl :

   gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
   

2. Vérifiez que le DaemonSet des métriques liées aux charges de travail est présent et opérationnel. Exécutez la commande suivante :

   kubectl get ds -n kube-system workload-metrics
   

   Si les composants ont bien été déployés, vous obtenez un résultat semblable au suivant :

   NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
   workload-metrics   3         3         3       3            3           2m
   

   Le nombre d'instances dupliquées ci-dessus doit correspondre au nombre de nœuds GKE Linux dans votre cluster. Par exemple, un cluster comportant trois nœuds aura DESIRED = 3. Après quelques minutes, les nombres de READY et de AVAILABLE doivent correspondre au nombre de DESIRED. Sinon, il peut y avoir un problème avec le déploiement.

Autres métriques

Outre les métriques définies par le système et les métriques liées aux charges de travail décrites ci-dessus, certaines métriques supplémentaires sont disponibles pour un cluster G​K​E. Par exemple :

• Métriques Istio, disponibles dans Cloud Monitoring