Résoudre les problèmes d'observabilité dans 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 suggérées et les solutions de contournement.

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

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

Vérifiez si Cloud Audit Logs est activé dans la section cloudAuditLogging de la configuration du cluster. Vérifiez que l'ID du projet, l'emplacement et la clé de compte de service sont correctement configurés. L'ID du projet doit être identique à l'ID du projet indiqué sous gkeConnect.

Si Cloud Audit Logs est activé, 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 du proxy Cloud Audit Logs.

Le conteneur de proxy Cloud Audit Logs s'exécute comme suit:

  • Un pod statique dans le cluster d'administrateur ou autonome
  • En tant que conteneur side-car dans le pod kube-apiserver.

Si vous rencontrez des erreurs d'autorisation, suivez les étapes 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 d'une 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 de panne est plus important entre les agents de métriques sur tous les nœuds.

Les métriques KSM ont des noms qui suivent le modèle de 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 processeur, la mémoire et le nombre 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 un nombre de ressources insuffisant.
    • 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.

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 de grands clusters ou des clusters comportant 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 sur chacun de ces objets de ressource. 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 avec n'importe quelle version de Google Distributed Cloud.

Les limites de processeur et de mémoire par défaut ont été augmentées dans les dernières versions de Google Distributed Cloud. Ces problèmes de ressources devraient donc être moins courants.

Correction et solution provisoire

Pour vérifier si le 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 de consommation et d'utilisation de la mémoire pour KSM, et vérifiez qu'elle atteint la limite avant de redémarrer.

Si vous confirmez qu'il s'agit d'un problème de mémoire insuffisante, utilisez 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:

    1. Pour Google Distributed Cloud versions 1.9 et antérieures, 1.10.6 ou antérieures, 1.11.2 et antérieures, et 1.12.1 ou versions antérieures:

      1. Pas de solution à long terme : si vous modifiez la ressource associée KSM, les modifications sont automatiquement annulées par monitoring-operator.

      2. Vous pouvez réduire le nombre d'instances répliquées de monitoring-operator à zéro, puis modifier le déploiement KSM pour ajuster sa limite de ressources. Toutefois, le cluster ne recevra pas les correctifs des failles fournis par les nouvelles versions de correctif via monitoring-operator.

        N'oubliez pas d'effectuer le scaling à la hausse de monitoring-operator après la mise à niveau du cluster vers une version ultérieure avec le correctif.

    2. Pour Google Distributed Cloud versions 1.10.7 ou ultérieure, 1.11.3 ou ultérieure, 1.12.2 ou ultérieure et 1.13 et versions ultérieures, créez un ConfigMap nommé kube-state-metrics-resizer-config dans l'espace de noms kube-system (gke-managed-metrics-server pour la version 1.13 ou ultérieure) avec la définition suivante. Ajustez les nombres de processeurs et de mémoire comme vous le souhaitez:

      apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-state-metrics-resizer-config
  namespace: kube-system
data:
  NannyConfiguration: |-
  apiVersion: nannyconfig/v1alpha1
  kind: NannyConfiguration
  baseCPU: 200m
  baseMemory: 1Gi
  cpuPerNode: 3m
  memoryPerNode: 20Mi

      1. Après avoir créé le ConfigMap, redémarrez le déploiement KSM en supprimant le pod KSM à l'aide de la commande suivante:

          kubectl -n kube-system rollout restart deployment kube-state-metrics
  ```

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

    Pour Google Distributed Cloud 1.13, 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 à celle des versions précédentes, mais vous pouvez suivre la même procédure pour réduire davantage le nombre de métriques KSM.

    Pour les versions Google Distributed Cloud 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 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 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 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 saturation de la 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.

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 boucle de plantage de stackdriver-metadata-agent est dû à des événements de saturation de la mémoire. Cet événement est semblable à kube-state-metrics. Bien que stackdriver-metadata-agent ne répertorie pas toutes les ressources, il répertorie tous les objets pour les types de ressources pertinents tels que les pods, les déploiements et l'objet NetworkPolicy. L'agent s'exécute en tant que déploiement à instance répliquée unique, ce qui augmente le risque d'événements de mémoire insuffisante 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.

Les limites de processeur et de mémoire par défaut ont été augmentées dans les dernières versions de Google Distributed Cloud. Ces problèmes de ressources devraient donc être moins courants.

Correction et solution provisoire

Pour vérifier si le 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 de consommation et d'utilisation de la mémoire pour stackdriver-metadata-agent, et vérifiez qu'elle atteint la limite avant de redémarrer.
Si vous constatez 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 dans des clusters à forte densité de pods.

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

Correction et solution provisoire

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

Étapes suivantes

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