Résoudre les problèmes d'observabilité de la GDCV pour Bare Metal

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

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

Cloud Audit Logs 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 les journaux d'audit Cloud sont activés, les autorisations constituent la raison la plus courante pour laquelle les journaux ne sont pas collectés. Dans ce scénario, les messages d'erreur "Autorisation refusée" s'affichent dans le conteneur de proxy Cloud Audit Logs.

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

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

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

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

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

S'il manque des métriques KSM, consultez les étapes de dépannage suivantes:

  • Dans Cloud Monitoring, vérifiez le nombre de processeurs, la mémoire et le nombre de redémarrages de KSM à l'aide des métriques récapitulatives de l'API 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 rencontre 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.

kube-state-metrics : plantage en boucle

Symptôme

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

Cause

Ce scénario est plus susceptible de se produire dans les clusters volumineux ou ceux comportant de grandes quantités de ressources. KSM s'exécute comme un déploiement sur une seule instance répliquée 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 sur chacun de ces objets de ressource. Si l'une des ressources contient de nombreux objets, par exemple un cluster avec plus de 10 000 pods, KSM risque de manquer de mémoire.

Versions concernées

Ce problème peut survenir avec n'importe quelle version de Google Distributed Cloud Virtual pour Bare Metal.

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

Solution

Pour vérifier si votre problème est dû à une mémoire insuffisante, procédez comme suit:

  • Utilisez kubectl describe pod ou kubectl get pod -o yaml et vérifiez le message d'état d'erreur.
  • Vérifiez la métrique d'utilisation et de consommation de mémoire de KSM, et vérifiez si la limite est atteinte avant de redémarrer.

Si vous confirmez que des problèmes de mémoire insuffisante sont à l'origine du problème, appliquez l'une des solutions suivantes:

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

    Pour ajuster le processeur et la mémoire de KSM, utilisez la valeur resourceOverride de la ressource personnalisée Stackdriver pour kube-state-metrics.

  • Réduisez le nombre de métriques de KSM.

    Pour la version 1.13 de Google Distributed Cloud Virtual pour Bare Metal, KSM n'expose qu'un plus petit nombre de métriques appelées métriques principales par défaut. Ce comportement signifie que l'utilisation des ressources est inférieure aux versions précédentes, mais la même procédure peut être suivie pour réduire davantage le nombre de métriques KSM.

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

gke-metrics-agent : plantage en boucle

Si gke-metrics-agent ne rencontre que des problèmes de mémoire insuffisante sur le nœud contenant kube-state-metrics, un grand nombre de métriques kube-state-metrics sont à l'origine du problème. Pour atténuer ce problème, effectuez un scaling à la baisse de stackdriver-operator et modifiez KSM pour exposer un petit ensemble de métriques nécessaires, comme indiqué dans la section précédente. N'oubliez pas d'effectuer un scaling à la hausse de stackdriver-operator après la mise à niveau du cluster vers la version 1.13 de Google Distributed Cloud Virtual pour Bare Metal, dans laquelle 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 saturation de la mémoire, consultez les journaux des pods dans gke-metric-agent. Vous pouvez ajuster le nombre de processeurs et la mémoire pour tous les pods gke-metrics-agent en ajoutant le champ resourceAttrOverride à la ressource personnalisée Stackdriver.

stackdriver-metadata-agent : plantage en boucle

Symptôme

Aucun libellé de métadonnées système n'est disponible lors du filtrage des métriques dans Cloud Monitoring.

Cause

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

Version concernée

Ce problème peut survenir avec n'importe quelle version de Google Distributed Cloud Virtual pour Bare Metal.

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

Solution

Pour vérifier si votre problème est dû à une mémoire insuffisante, 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 d'utilisation et de consommation de mémoire de stackdriver-metadata-agent, et vérifiez si elle atteint la limite avant de redémarrer.
Si vous confirmez que des problèmes de mémoire insuffisante sont à l'origine des problèmes, augmentez la limite de mémoire dans le champ resourceAttrOverride de la ressource personnalisée Stackdriver.

metrics-server : plantage en boucle

Symptôme

L'autoscaler horizontal de 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 insuffisante dans des clusters volumineux ou avec une densité de pods élevée.

Ce problème peut survenir avec n'importe quelle version de Google Distributed Cloud Virtual pour Bare Metal.

Solution

Augmentez les limites de ressources du serveur de métriques. Dans la version 1.13 et les versions ultérieures de Google Distributed Cloud Virtual pour Bare Metal, 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 Virtual pour Bare Metal, la modification de la configuration du service nounou serait annulée en cas de mise à jour ou de mise à niveau du cluster. Vous devrez appliquer à nouveau les modifications de votre configuration. Pour contourner cette limitation, effectuez un scaling à la baisse de metrics-server-operator et modifiez manuellement le pod metrics-server.

Étapes suivantes

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