Cette page a été traduite par l'API Cloud Translation.

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

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

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

Vérifiez que vous avez 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 de la consoleGoogle 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.
Est-ce qu'un pod heapster ou gke-metrics-agent (OpenTelemetry Collector) s'exécute 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.

Identifier et résoudre les problèmes d'autorisation pour l'écriture de métriques

GKE utilise des comptes de service IAM associés à vos nœuds pour exécuter des tâches système telles que la journalisation et la surveillance. Au minimum, ces comptes de service de nœud doivent disposer du rôle Compte de service de nœud par défaut Kubernetes Engine (roles/container.defaultNodeServiceAccount) sur votre projet. Par défaut, GKE utilise le compte de service Compute Engine par défaut, qui est créé automatiquement dans votre projet, en tant que compte de service de nœud.

Si votre organisation applique la contrainte de règle d'administration iam.automaticIamGrantsForDefaultServiceAccounts, il est possible que le compte de service Compute Engine par défaut de votre projet n'obtienne pas automatiquement les autorisations requises pour GKE.

Pour identifier le problème, recherchez les erreurs 401 dans la charge de travail de surveillance du système de votre cluster :
```
[[ $(kubectl logs -l k8s-app=gke-metrics-agent -n kube-system -c gke-metrics-agent | grep -cw "Received 401") -gt 0 ]] && echo "true" || echo "false"
```
Si le résultat est true, cela signifie que la charge de travail système rencontre des erreurs 401, qui indiquent un manque d'autorisations. Si le résultat est false, ignorez le reste de ces étapes et essayez une autre procédure de dépannage.

Pour attribuer le rôle roles/container.defaultNodeServiceAccount au compte de service Compute Engine par défaut, procédez comme suit :

Console

Accédez à la page d'accueil :
Accéder à la page d'accueil
Dans le champ Numéro du projet, cliquez sur Copier dans le presse-papiers.
Accédez à la page IAM :
Accéder à la page "IAM"
Cliquez sur Accorder l'accès.
Dans le champ Nouveaux comptes principaux, spécifiez la valeur suivante :
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
Remplacez PROJECT_NUMBER par le numéro de projet que vous avez copié.
Dans le menu Sélectionner un rôle, choisissez le rôle Compte de service de nœud par défaut Kubernetes Engine.
Cliquez sur Enregistrer.

gcloud

Recherchez le numéro de votre projet Google Cloud :
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
Remplacez PROJECT_ID par l'ID du projet.

Le résultat ressemble à ce qui suit :
```
12345678901
```

Attribuez le rôle roles/container.defaultNodeServiceAccount au compte de service Compute Engine par défaut :

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

Remplacez PROJECT_NUMBER par le numéro de projet de l'étape précédente.

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, il est possible que l'agent de métriques ne dispose pas de suffisamment 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 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 bugs ou demander des fonctionnalités à l'aide de l'outil public de suivi des problèmes.