Ce document vous aide à résoudre les problèmes d'observabilité dans Google Distributed Cloud. Si vous rencontrez l'un de ces problèmes, examinez les solutions et les solutions de contournement suggérées.
Si vous avez besoin d'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 sectioncloudAuditLogging
de la configuration du cluster. Vérifiez que l'ID de projet, l'emplacement et la clé du compte de service sont correctement configurés. L'ID de projet doit être identique à celui sous gkeConnect
.
Si Cloud Audit Logging est activé, 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 de l'une des manières suivantes :- Un pod statique dans le cluster d'administration ou autonome
- En tant que conteneur secondaire dans le pod
kube-apiserver
.
Si des erreurs d'autorisation s'affichent, suivez la procédure de dépannage pour résoudre les 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 KSM et gke-metrics-agent
s'exécutent sur le même nœud, le risque de panne est plus élevé parmi les agents de métriques sur tous les nœuds.
Les noms des métriques KSM suivent le format 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.
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.
- Si ces métriques d'API récapitulatives ne sont pas disponibles pour KSM,
- 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 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 clusters de grande taille ou dans les clusters contenant un grand nombre 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 se produire dans n'importe quelle version de Google Distributed Cloud.
La limite de processeur et de mémoire par défaut a été augmentée dans les dernières versions de Google Distributed Cloud. Ces problèmes de ressources devraient donc être moins fréquents.
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
oukubectl get pod -o yaml
et 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.
Pour ajuster le processeur et la mémoire de KSM :
Pour Google Distributed Cloud versions 1.16.0 ou ultérieures, Google Cloud Observability gère KSM. Pour mettre à jour KSM, consultez la section Remplacer les valeurs par défaut de processeur et les demandes de mémoire et limites pour un composant Stackdriver.
Pour les versions Google Distributed Cloud 1.10.7 ou ultérieure, 1.11.3 ou ultérieure, 1.12.2 ou ultérieure, et 1.13 ou ultérieure, mais antérieure à 1.16.0, créez un
ConfigMap
pour ajuster le processeur et la mémoire :Créez un
ConfigMap
nommékube-state-metrics-resizer-config
dans l'espace de nomskube-system
(gke-managed-metrics-server
pour la version 1.13 ou ultérieure) avec la définition suivante. Ajustez le nombre de processeurs et de mémoire selon vos besoins :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 ```
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
Pour Google Distributed Cloud versions 1.9 et antérieures, 1.10.6 et antérieures, 1.11.2 et antérieures, et 1.12.1 et antérieures :
- Aucune solution à long terme satisfaisante : si vous modifiez la ressource associée à KSM, les modifications sont automatiquement annulées par
monitoring-operator
. - Vous pouvez réduire
monitoring-operator
à 0 instance répliquée, puis modifier le déploiement KSM pour ajuster sa limite de ressources. Toutefois, le cluster ne recevra pas les correctifs de vulnérabilité fournis par les nouvelles versions de correctifs à l'aide demonitoring-operator
. N'oubliez pas de mettre à l'échellemonitoring-operator
après la mise à niveau du cluster vers une version ultérieure avec correctif.
- Aucune solution à long terme satisfaisante : si vous modifiez la ressource associée à KSM, les modifications sont automatiquement annulées par
Réduire le nombre de métriques de KSM
Pour Google Distributed Cloud 1.13, KSM n'expose qu'un nombre limité 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 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 à la version 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 stackdriver-operator
et modifiez KSM afin d'exposer un petit ensemble de métriques nécessaires, comme indiqué dans la section précédente.
N'oubliez pas de réduire la valeur de stackdriver-operator
une fois que le cluster a été mis à niveau vers Google Distributed Cloud 1.13, où KSM expose par défaut un nombre réduit de métriques principales.
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 pour filtrer les 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 pour les types de ressources pertinents tels que les pods, les déploiements et les règles de réseau. 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 de processeur et de mémoire par défaut a été augmentée dans les dernières versions de Google Distributed Cloud. Ces problèmes de ressources devraient donc être moins fréquents.
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
oukubectl get pod -o yaml
et 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.
resourceAttrOverride
de la ressource personnalisée Stackdriver.
Boucle de plantage 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 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.
Correction et solution de contournement
Augmentez les limites des ressources du serveur de métriques.
Dans Google Distributed Cloud version 1.13 et 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
.
Étape suivante
Si vous avez besoin d'aide supplémentaire, contactez l'Assistance Google.