Résoudre les problèmes d'observabilité de Google Distributed Cloud

Ce document vous aide à résoudre les problèmes d'observabilité dans Google Distributed Cloud. Si vous rencontrez l'un de ces problèmes, consultez les corrections et les solutions suggérées.

Si vous avez besoin d'une aide supplémentaire, contactez l'assistance Google.

Les journaux d'audit Cloud ne sont pas collectés

Les journaux d'audit Cloud sont activés par défaut, sauf si un indicateur disableCloudAuditLogging est défini dans la section clusterOperations de la configuration du cluster.

Si Cloud Audit Logs est activé, les autorisations sont la raison la plus courante pour laquelle les journaux ne sont pas collectés. Dans ce scénario, les messages d'erreur d'autorisation refusée s'affichent dans le conteneur du proxy Cloud Audit Logs.

Le conteneur proxy Cloud Audit Logs s'exécute en tant que DaemonSet dans tous les clusters Google Distributed Cloud.

Si vous rencontrez des erreurs d'autorisation, suivez la procédure de dépannage et de résolution des problèmes d'autorisation.

Les métriques kube-state-metrics ne sont pas collectées

kube-state-metrics (KSM) s'exécute en tant que déploiement d'instance répliquée unique dans le cluster et génère des métriques sur presque toutes les ressources du cluster. Lorsque le KSM et gke-metrics-agent s'exécutent sur le même nœud, le risque d'indisponibilité est plus élevé parmi les agents de métriques sur tous les nœuds.

Les métriques KSM ont des noms qui suivent le modèle kube_<ResourceKind>, par exemple kube_pod_container_info. Les métriques commençant par kube_onpremusercluster_ proviennent du contrôleur de cluster sur site, et non de KSM.

Si les métriques KSM sont manquantes, consultez les étapes de dépannage suivantes :

  • Dans Cloud Monitoring, vérifiez le nombre de processeurs, de mémoire et de redémarrages de KSM à l'aide des métriques d'API récapitulatives telles que kubernetes.io/anthos/container/.... Il s'agit d'un pipeline distinct avec KSM. Vérifiez que le pod KSM n'est pas limité par des ressources insuffisantes.
    • Si ces métriques d'API récapitulatives ne sont pas disponibles pour KSM, gke-metrics-agent sur le même nœud présente probablement le même problème.
  • Dans le cluster, vérifiez l'état et les journaux du pod KSM et du pod gke-metrics-agent sur le même nœud avec KSM.

Boucle de plantage de kube-state-metrics

Symptôme

Aucune métrique de kube-state-metrics (KSM) n'est disponible dans Cloud Monitoring.

Cause

Ce scénario est plus susceptible de se produire dans des clusters de grande taille ou avec de grandes quantités de ressources. KSM s'exécute en tant que déploiement à instance répliquée unique et répertorie presque toutes les ressources du cluster, telles que les pods, les déploiements, les DaemonSets, les ConfigMaps, les Secrets et les PersistentVolumes. Des métriques sont générées pour chacun de ces objets de ressources. Si l'une des ressources comporte de nombreux objets, comme un cluster avec plus de 10 000 pods, KSM risque de manquer de mémoire.

Versions concernées

Ce problème peut survenir dans n'importe quelle version de Google Distributed Cloud.

La limite par défaut de processeur et de mémoire a été augmentée dans les dernières versions de Google Distributed Cloud. Ces problèmes de ressources devraient donc être moins courants.

Correction et solution de contournement

Pour vérifier si votre problème est dû à des problèmes de mémoire saturée, procédez comme suit :

  • Utilisez kubectl describe pod ou kubectl get pod -o yaml, puis vérifiez le message d'état d'erreur.
  • Vérifiez la métrique de consommation et d'utilisation de la mémoire pour KSM et vérifiez si elle atteint la limite avant d'être redémarrée.

Si vous confirmez que les problèmes de mémoire insuffisante sont le problème, utilisez l'une des solutions suivantes :

  • Augmentez la demande et la limite de mémoire pour KSM.

  • Réduire le nombre de métriques de KSM

    Pour Google Distributed Cloud 1.13, KSM n'expose qu'un petit nombre de métriques appelées métriques de base par défaut. Ce comportement signifie que l'utilisation des ressources est inférieure à celle des versions précédentes, mais que vous pouvez suivre la même procédure pour réduire davantage le nombre de métriques KSM.

    Pour les versions antérieures à la version 1.13 de Google Distributed Cloud, KSM utilise les options par défaut. Cette configuration expose un grand nombre de métriques.

Boucle de plantage de gke-metrics-agent

Si gke-metrics-agent ne rencontre que des problèmes de mémoire insuffisante sur le nœud où kube-state-metrics existe, cela est dû à un grand nombre de métriques kube-state-metrics. Pour atténuer ce problème, réduisez stackdriver-operator et modifiez KSM pour exposer un petit ensemble de métriques requises, comme indiqué dans la section précédente. N'oubliez pas d'effectuer un scaling à la hausse stackdriver-operator après la mise à niveau du cluster vers Google Distributed Cloud 1.13, où KSM expose par défaut un plus petit nombre de métriques principales.

Pour les problèmes qui ne sont pas liés à des événements de manque de mémoire, consultez les journaux des pods de gke-metric-agent. Vous pouvez ajuster le processeur et la mémoire pour tous les pods gke-metrics-agent en ajoutant le champ resourceAttrOverride à la ressource personnalisée Stackdriver.

Boucle de plantage stackdriver-metadata-agent

Symptôme

Aucun libellé de métadonnées système n'est disponible lorsque vous filtrez des métriques dans Cloud Monitoring.

Cause

Le cas le plus courant de boucle de plantage stackdriver-metadata-agent est dû à des événements de mémoire insuffisante. Cet événement est semblable à kube-state-metrics. Bien que stackdriver-metadata-agent ne liste pas toutes les ressources, il liste tous les objets des types de ressources pertinents, tels que les pods, les déploiements et NetworkPolicy. L'agent s'exécute en tant que déploiement à réplication unique, ce qui augmente le risque d'événements de mémoire insuffisante si le nombre d'objets est trop important.

Version concernée

Ce problème peut se produire dans n'importe quelle version de Google Distributed Cloud.

La limite par défaut de processeur et de mémoire a été augmentée dans les dernières versions de Google Distributed Cloud. Ces problèmes de ressources devraient donc être moins courants.

Correction et solution de contournement

Pour vérifier si votre problème est dû à des problèmes de mémoire saturée, procédez comme suit :

  • Utilisez kubectl describe pod ou kubectl get pod -o yaml, puis vérifiez le message d'état d'erreur.
  • Vérifiez la métrique de consommation et d'utilisation de mémoire pour stackdriver-metadata-agent, et vérifiez si elle atteint la limite avant de redémarrer.
Si vous vérifiez que les problèmes de mémoire insuffisante sont à l'origine des problèmes, augmentez la limite de mémoire dans lechamp resourceAttrOverride de la ressource personnalisée Stackdriver.

Boucle de plantage de metrics-server

Symptôme

L'autoscaler horizontal des pods et kubectl top ne fonctionnent pas dans votre cluster.

Cause et versions concernées

Ce problème n'est pas très courant, mais il est causé par des erreurs de mémoire saturée dans les grands clusters ou dans les clusters à forte densité de pods.

Ce problème peut survenir dans n'importe quelle version de Google Distributed Cloud.

Correction et solution de contournement

Augmentez les limites de ressources du serveur de métriques. Dans les versions 1.13 et ultérieures de Google Distributed Cloud, l'espace de noms de metrics-server et sa configuration ont été déplacés de kube-system vers gke-managed-metrics-server.

Pour Google Distributed Cloud, la modification de la configuration du système de supervision est annulée en cas de mise à jour ou de mise à niveau du cluster. Vous devez appliquer à nouveau vos modifications de configuration. Pour contourner cette limitation, effectuez un scaling à la baisse de metrics-server-operator et modifiez manuellement le pod metrics-server.

Étape suivante

Si vous avez besoin d'une aide supplémentaire, contactez l'assistance Google.