Résoudre les problèmes liés aux métriques système

Autopilot Standard

Cette page explique comment résoudre les problèmes liés aux métriques système sur vos clusters Google Kubernetes Engine (GKE).

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Les métriques de votre cluster n'apparaissent pas dans Cloud Monitoring

Assurez-vous d'avoir activé l'API Monitoring et l'API Logging sur votre projet. Vous devez également vérifier que vous pouvez afficher votre projet dans la présentation de Cloud Monitoring dans la console Google Cloud.

Si le problème persiste, penchez-vous sur les causes potentielles suivantes :

Avez-vous activé la surveillance sur votre cluster ?

La surveillance est activée par défaut pour les clusters créés à partir de la console Google Cloud et de Google Cloud CLI, mais vous pouvez vérifier que c'est bien le cas en cliquant sur les détails du cluster dans la console Google Cloud ou en exécutant la commande suivante :
```
gcloud container clusters describe CLUSTER_NAME
```
Le résultat de cette commande doit inclure SYSTEM_COMPONENTS dans la liste de enableComponents de la section monitoringConfig, comme dans l'exemple suivant :
```
monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
```
Si la surveillance n'est pas activée, exécutez la commande suivante pour l'activer :
```
gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
```
Depuis combien de temps votre cluster a-t-il été créé ou sa surveillance activée ?

L'apparition des métriques d'un nouveau cluster dans Cloud Monitoring peut prendre jusqu'à une heure.
Un heapster ou gke-metrics-agent (OpenTelemetry Collector) s'exécute-t-il dans votre cluster dans l'espace de noms kube-system ?

Ce pod ne parvient peut-être pas à planifier les charges de travail parce que votre cluster manque de ressources. Vérifiez que Heapster ou OpenTelementry est en cours d'exécution en exécutant kubectl get pods --namespace=kube-system et en recherchant les pods dont le nom contient heapster ou gke-metrics-agent.
Le plan de contrôle de votre cluster est-il capable de communiquer avec les nœuds ?

Cloud Monitoring s'appuie sur cette communication. Vous pouvez vérifier que le plan de contrôle communique avec les nœuds en exécutant la commande suivante:
```
kubectl logs POD_NAME
```
Si cette commande renvoie une erreur, le problème peut être causé par les tunnels SSH. Pour connaître les étapes de dépannage, consultez la section Résoudre les problèmes liés à SSH.

Vérifier que l'agent de métriques dispose de suffisamment de mémoire

Si vous avez suivi les étapes de dépannage précédentes et que les métriques ne s'affichent toujours pas, l'agent de métriques peut manquer de mémoire.

Dans la plupart des cas, l'allocation de ressources par défaut à l'agent de métriques GKE est suffisante. Toutefois, si le DaemonSet plante de manière répétée, vous pouvez vérifier le motif de l'arrêt à l'aide des instructions suivantes :

Obtenez les noms des pods de l'agent de métriques GKE :

kubectl get pods -n kube-system -l component=gke-metrics-agent

Recherchez le pod ayant l'état CrashLoopBackOff.

Le résultat ressemble à ce qui suit :

NAME                    READY STATUS           RESTARTS AGE
gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m

Décrivez le pod dont l'état est CrashLoopBackOff :
```
kubectl describe pod POD_NAME -n kube-system
```
Remplacez POD_NAME par le nom du pod obtenu à l'étape précédente.

Si le motif de l'arrêt du pod est OOMKilled, l'agent a besoin de mémoire supplémentaire.

Le résultat ressemble à ce qui suit :
```
  containerStatuses:
  ...
  lastState:
    terminated:
      ...
      exitCode: 1
      finishedAt: "2021-11-22T23:36:32Z"
      reason: OOMKilled
      startedAt: "2021-11-22T23:35:54Z"
```
Ajoutez un libellé de nœud au nœud hébergeant l'agent de métriques défaillant. Vous pouvez utiliser un libellé de nœud persistant ou temporaire. Nous vous recommandons d'essayer d'ajouter 20 Mo supplémentaires. Si l'agent continue de planter, vous pouvez exécuter à nouveau cette commande en remplaçant le libellé de nœud par un libellé qui demande une plus grande quantité de mémoire supplémentaire.

Pour mettre à jour un pool de nœuds avec un libellé persistant, exécutez la commande suivante :
```
gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --node-labels=ADDITIONAL_MEMORY_NODE_LABEL \
    --location=COMPUTE_LOCATION
```
Remplacez les éléments suivants :
- NODEPOOL_NAME : nom du pool de nœuds.
- CLUSTER_NAME : nom du cluster existant.
- ADDITIONAL_MEMORY_NODE_LABEL : un des libellés de nœud de mémoire supplémentaires ; utilisez l'une des valeurs suivantes :
  - Pour ajouter 10 Mo : cloud.google.com/gke-metrics-agent-scaling-level=10
  - Pour ajouter 20 Mo : cloud.google.com/gke-metrics-agent-scaling-level=20
  - Pour ajouter 50 Mo : cloud.google.com/gke-metrics-agent-scaling-level=50
  - Pour ajouter 100 Mo : cloud.google.com/gke-metrics-agent-scaling-level=100
  - Pour ajouter 200 Mo : cloud.google.com/gke-metrics-agent-scaling-level=200
  - Pour ajouter 500 Mo : cloud.google.com/gke-metrics-agent-scaling-level=500
- COMPUTE_LOCATION : emplacement Compute Engine du cluster.
Vous pouvez également ajouter un libellé de nœud temporaire qui ne persistera pas après la mise à niveau à l'aide de la commande suivante :
```
kubectl label node/NODE_NAME \
ADDITIONAL_MEMORY_NODE_LABEL --overwrite
```
Remplacez les éléments suivants :
- NODE_NAME : nom du nœud de l'agent de métriques concerné.
- ADDITIONAL_MEMORY_NODE_LABEL : un des libellés de nœud de mémoire supplémentaires ; utilisez l'une des valeurs de l'exemple précédent.

Étape suivante

Si vous rencontrez un problème lié à l'agent Cloud Logging, consultez sa documentation de dépannage.
Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.