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 correctifs et solutions de contournement suggérés.

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care. Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris en ce qui concerne les thématiques suivantes :

  • Conditions requises pour ouvrir une demande d'assistance
  • Outils pour vous aider à résoudre les problèmes liés à la configuration de votre environnement, les journaux et les métriques
  • Composants acceptés.

Cloud Audit Logs ne sont pas collectés

Cloud Audit Logs 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 sont la raison la plus courante pour laquelle les journaux ne sont pas collectés. Dans ce scénario, des messages d'erreur d'autorisation refusée s'affichent dans le conteneur 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 des erreurs d'autorisation s'affichent, suivez la procédure pour résoudre les problèmes d'autorisation.

Une autre cause possible est que votre projet a peut-être atteint la limite de comptes de service acceptée. Consultez la section Compte de service Cloud Audit Logs divulgué.

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 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>, comme kube_pod_container_info. Les métriques qui commencent 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 un manque de ressources.
    • 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 que KSM.

Boucle de plantage 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 les grands clusters ou les clusters 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 sur chacun de ces objets de ressource. Si l'une des ressources comporte de nombreux objets, comme un cluster de plus de 10 000 pods, KSM risque de manquer de mémoire.

Versions concernées

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 fréquents.

Correctif 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 qu'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éduisez le nombre de métriques de KSM.

    Pour Google Distributed Cloud 1.13, KSM n'expose par défaut qu'un plus petit nombre de métriques appelées métriques principales. Ce comportement signifie que l'utilisation des ressources est inférieure à celle des 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 antérieures à 1.13, KSM utilise les indicateurs par défaut. Cette configuration expose un grand nombre de métriques.

Boucle de plantage gke-metrics-agent

Si gke-metrics-agent ne rencontre des problèmes de mémoire insuffisante que sur le nœud où kube-state-metrics existe, la cause est un grand nombre de métriques kube-state-metrics. Pour atténuer ce problème, réduisez l'échelle de stackdriver-operator et modifiez KSM afin d'exposer un petit ensemble de métriques nécessaires, comme décrit dans la section précédente. N'oubliez pas de remettre à l'échelle stackdriver-operator une fois le cluster mis à niveau 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 mémoire insuffisante, consultez les journaux des pods de gke-metric-agent. Vous pouvez ajuster le processeur et la mémoire de tous les gke-metrics-agent pods en ajoutant le resourceAttrOverride champ à la ressource personnalisée Stackdriver.

Boucle de plantage stackdriver-metadata-agent

Symptôme

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

Cause

La cause la plus fréquente de la boucle de plantage stackdriver-metadata-agent est un événement 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 d'instance répliquée unique, ce qui augmente le risque de problèmes 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 fréquents.

Correctif 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 stackdriver-metadata-agent et vérifiez qu'elle atteint la limite avant le redémarrage.
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 metrics-server

Symptôme

L'Autoscaler horizontal de pods et kubectl top ne fonctionnent pas dans votre cluster.

Cause et versions concernées

Ce problème est peu fréquent, mais il est dû à des erreurs de mémoire insuffisante dans les grands clusters ou dans les clusters à forte densité de pods.

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

Correctif et solution de contournement

Augmentez les limites de ressources du serveur de métriques. Dans Google Distributed Cloud version 1.13 et versions ultérieures, 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 de la nounou serait annulée en cas de mise à jour ou de mise à niveau du cluster. Vous devrez réappliquer vos modifications de configuration. Pour contourner cette limitation, réduisez l'échelle de metrics-server-operator et modifiez manuellement le pod metrics-server.

Toutes les ressources ne sont pas supprimées lors de la suppression du compte de service Cloud Audit Logs

Lorsque vous supprimez un compte de service utilisé pour Cloud Audit Logs, toutes les Google Cloud ressources ne sont pas supprimées. Si vous supprimez et recréez régulièrement des comptes de service utilisés pour Cloud Audit Logs, la journalisation d'audit finit par échouer.

Symptôme

Des messages d'erreur d'autorisation refusée s'affichent dans le conteneur proxy Cloud Audit Logs.

Pour confirmer que l'échec du journal d'audit est dû à ce problème, exécutez la commande suivante :

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging

Remplacez PROJECT_NUMBER par votre numéro de projet.

La réponse renvoie tous les comptes de service utilisés avec Cloud Audit Logs dans le projet, y compris les comptes de service qui ont été supprimés.

Cause et versions concernées

Toutes les Google Cloud ressources ne sont pas supprimées lorsque vous supprimez un compte de service utilisé pour Cloud Audit Logs. Vous finissez par atteindre la limite de 1 000 comptes de service pour le projet.

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

Correctif et solution de contournement

  1. Créez une variable d'environnement contenant une liste séparée par des virgules de tous les comptes de service que vous souhaitez conserver. Placez chaque adresse e-mail de compte de service entre guillemets simples et placez l'ensemble de la liste entre guillemets doubles. Vous pouvez utiliser les éléments suivants comme point de départ :

    SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet.
    • SERVICE_ACCOUNT_NAME : nom du compte de service.

    La liste complète doit ressembler à l'exemple suivant :

    "'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"

  2. Exécutez la commande suivante pour supprimer la fonctionnalité Cloud Audit Logs du projet :

    curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging

    Remplacez les éléments suivants :

    • PROJECT_NUMBER : numéro du projet.
    • FLEET_REGION: emplacement de l'appartenance au parc pour vos clusters. Il peut s'agir d'une région spécifique telle que us-central1 ou global. Vous pouvez exécuter la commande gcloud container fleet memberships list pour obtenir l'emplacement de l'appartenance.

    Cette commande supprime complètement tous les comptes de service.

  3. Recréez la fonctionnalité Cloud Audit Logs avec uniquement les comptes de service que vous souhaitez conserver :

    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \
    -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'

Les libellés de métadonnées disparaissent des métriques

Symptôme

Les libellés de métadonnées, par exemple node_name, ne sont pas renseignés dans Cloud Monitoring.

Cause et versions concernées

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

Correctif et solution de contournement

Toute modification apportée au pod rétablira les libellés de métadonnées. Par exemple, l'exécution de commandes telles que kubectl rollout restart deployment <workload_name>.

Étape suivante

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care. Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris en ce qui concerne les thématiques suivantes :

  • Conditions requises pour ouvrir une demande d'assistance
  • Outils pour vous aider à résoudre les problèmes liés à la configuration de votre environnement, les journaux et les métriques
  • Composants acceptés