Cette page vous présente les techniques de dépannage de base pour Google Kubernetes Engine (GKE). Cette page s'adresse aux utilisateurs qui débutent avec Kubernetes et GKE, et qui souhaitent apprendre des pratiques de dépannage efficaces.
Cette page présente les outils et techniques suivants pour surveiller, diagnostiquer et résoudre les problèmes liés à GKE :
- Vérifiez l'état des clusters et des charges de travail dans la console Trusted Cloud : obtenez une vue d'ensemble pour identifier rapidement les problèmes potentiels liés à vos clusters et applications.
- Examinez l'état du cluster avec l'outil de ligne de commande
kubectl
: utilisez ces commandes pour afficher l'état en direct des ressources telles que les nœuds et les pods. - Effectuer une analyse historique avec Cloud Logging : interrogez les données de journaux historiques et examinez les événements pour identifier la cause première des échecs.
- Effectuez une surveillance proactive avec Cloud Monitoring : suivez les métriques de performances au fil du temps, visualisez les tendances et créez des alertes pour détecter les problèmes et y répondre avant qu'ils n'affectent les utilisateurs.
- Accélérez le diagnostic avec Gemini Cloud Assist : analysez les messages d'erreur complexes, obtenez des conseils de dépannage détaillés et examinez les problèmes automatiquement.
- Assembler toutes les briques : exemple de scénario de dépannage : découvrez comment utiliser ces outils ensemble dans un guide pas à pas pour diagnostiquer et résoudre un problème courant d'application réelle.
Comprendre les concepts de base
Si vous débutez avec Kubernetes et GKE, il est essentiel de comprendre les concepts de base, comme l'architecture des clusters et la relation entre les pods et les nœuds, avant de commencer à résoudre les problèmes. Pour en savoir plus, consultez Commencer à découvrir GKE.
Il est également utile de comprendre les parties de GKE que vous êtes responsable de maintenir et celles dont Trusted Cloud by S3NS est responsable. Pour en savoir plus, consultez Responsabilité partagée de GKE.
Vérifier l'état des clusters et des charges de travail dans la console Trusted Cloud
La console Trusted Cloud est un bon point de départ pour résoudre les problèmes, car elle offre un aperçu rapide de l'état de vos clusters et de vos charges de travail. L'état du cluster fait référence à l'état de l'infrastructure GKE sous-jacente, comme les nœuds et le réseau, tandis que l'état de la charge de travail fait référence à l'état et aux performances de vos applications exécutées sur le cluster.
Les sections suivantes décrivent les pages "Cluster" et "Charge de travail". Pour vous donner une vue d'ensemble de l'état de votre application, la console Trusted Cloud vous donne également accès à de puissants outils de journalisation et de surveillance. Vous pouvez ainsi identifier la cause première des échecs passés et prévenir ceux à venir. Pour en savoir plus sur ces outils, consultez les sections Effectuer des analyses historiques avec Cloud Logging et Effectuer une surveillance proactive avec Cloud Monitoring.
Identifier les problèmes de cluster
La page Clusters Kubernetes vous offre une vue d'ensemble de l'état de vos clusters. Pour identifier les problèmes liés à vos clusters, commencez par consulter cette page.
Pour commencer, dans la console Trusted Cloud , accédez à la page Clusters Kubernetes.
Voici quelques exemples d'utilisation de cette page pour résoudre des problèmes :
- Pour obtenir des conseils sur l'amélioration de l'état de votre cluster, de votre stratégie de mise à niveau et de l'optimisation des coûts, cliquez sur Afficher les recommandations.
- Pour identifier les clusters non opérationnels, consultez la colonne État. Tout cluster qui ne comporte pas de coche verte requiert votre attention.
- Pour identifier les problèmes potentiels, consultez la colonne Notifications. Cliquez sur un message de notification pour en savoir plus.
Examiner un cluster spécifique
Une fois que vous avez identifié un problème avec un cluster, explorez la page Détails du cluster pour obtenir des informations détaillées qui vous aideront à résoudre le problème et à comprendre la configuration du cluster.
Pour accéder à la page Détails d'un cluster, procédez comme suit :
Accédez à la page des clusters Kubernetes.
Examinez la colonne Nom, puis cliquez sur le nom du cluster que vous souhaitez examiner.
Voici quelques exemples d'utilisation de la page Détails du cluster pour résoudre les problèmes liés à votre cluster :
Pour les vérifications d'état générales, essayez les options suivantes :
Pour afficher les tableaux de bord au niveau du cluster, accédez à l'onglet Observabilité. Par défaut, GKE active Cloud Monitoring lorsque vous créez un cluster. Lorsque Cloud Monitoring est activé, GKE configure automatiquement les tableaux de bord sur cette page. Voici quelques-unes des vues qui pourraient vous être les plus utiles pour résoudre les problèmes :
- Présentation : affichez un récapitulatif général de l'état, de l'utilisation des ressources et des événements clés de votre cluster. Ce tableau de bord vous aide à évaluer rapidement l'état général de votre cluster et à identifier les problèmes potentiels.
- Métriques de trafic : affichez les métriques de mise en réseau basées sur les nœuds pour obtenir des insights sur le trafic entre vos charges de travail Kubernetes.
- État de la charge de travail : affichez l'état des déploiements, des pods et des conteneurs. Identifier les instances défaillantes ou non opérationnelles et détecter les contraintes de ressources.
Plan de contrôle : affichez l'état et les performances du plan de contrôle. Ce tableau de bord vous permet de surveiller les métriques clés des composants tels que
kube-apiserver
etetcd
, d'identifier les goulots d'étranglement des performances et de détecter les défaillances des composants.
Pour afficher les erreurs récentes de l'application, accédez à l'onglet Erreurs de l'application. Les informations de cet onglet peuvent vous aider à hiérarchiser et à résoudre les erreurs. Elles indiquent le nombre d'occurrences, la date de la première apparition d'une erreur et la date de sa dernière occurrence.
Pour examiner une erreur plus en détail, cliquez sur le message d'erreur afin d'afficher un rapport d'erreurs détaillé, y compris des liens vers les journaux concernés.
Si vous rencontrez des problèmes après une mise à niveau ou une modification récente, consultez la section Principes de base des clusters dans l'onglet Détails du cluster. Vérifiez que la version indiquée dans le champ Version est celle que vous attendez. Pour en savoir plus, cliquez sur Afficher l'historique des mises à niveau dans la section Mises à niveau.
Si vous utilisez un cluster standard et que vos pods sont bloqués à l'état
Pending
, ou si vous pensez que les nœuds sont surchargés, consultez l'onglet Nœuds. L'onglet Nœuds n'est pas disponible pour les clusters Autopilot, car GKE gère les nœuds à votre place.- Dans la section Pools de nœuds, vérifiez que l'autoscaling est correctement configuré et que le type de machine est adapté à vos charges de travail.
- Dans la section Nœuds, recherchez les nœuds dont l'état n'est pas
Ready
. Un étatNotReady
indique un problème lié au nœud lui-même, tel qu'une pression sur les ressources ou un problème avec le kubelet (l'agent qui s'exécute sur chaque nœud pour gérer les conteneurs).
Identifier les problèmes liés aux charges de travail
Lorsque vous pensez qu'un problème est lié à une application spécifique, comme un déploiement ayant échoué, accédez à la page Charges de travail dans la console Trusted Cloud . Cette page fournit une vue centralisée de toutes les applications qui s'exécutent dans vos clusters.
Pour commencer, dans la console Trusted Cloud , accédez à la page Charges de travail.
Voici quelques exemples d'utilisation de cette page pour résoudre des problèmes :
- Pour identifier les charges de travail non opérationnelles, consultez la colonne État. Toute charge de travail qui ne comporte pas de coche verte requiert votre attention.
- Si une application ne répond pas, consultez la colonne Pods. Par exemple, un état tel que 1/3 signifie qu'une seule des trois répliques d'application est en cours d'exécution, ce qui indique un problème.
Examiner une charge de travail spécifique
Une fois que vous avez identifié une charge de travail problématique dans l'aperçu, explorez la page Détails de la charge de travail pour commencer à isoler la cause première.
Pour accéder à la page Détails d'une charge de travail, procédez comme suit :
Accédez à la page "Charges de travail".
Consultez la colonne Nom et cliquez sur le nom de la charge de travail que vous souhaitez examiner.
Voici quelques exemples d'utilisation de la page Détails de la charge de travail pour résoudre les problèmes liés à vos charges de travail :
Pour vérifier la configuration de la charge de travail, utilisez les onglets Présentation et Détails de la charge de travail. Vous pouvez utiliser ces informations pour vérifier des événements tels que le déploiement du tag d'image de conteneur approprié ou les limites et demandes de ressources de la charge de travail.
Pour trouver le nom d'un pod spécifique qui plante, accédez à la section Pods gérés. Vous aurez peut-être besoin de ces informations pour les commandes
kubectl
. Cette section liste tous les pods contrôlés par la charge de travail, ainsi que leur état. Pour afficher l'historique des modifications récentes apportées à une charge de travail, accédez à l'onglet Historique des révisions. Si vous constatez des problèmes de performances après un nouveau déploiement, utilisez cette section pour identifier la révision active. Vous pouvez ensuite comparer les configurations de la révision actuelle avec les précédentes pour identifier la source du problème. Si cet onglet n'est pas visible, cela signifie que la charge de travail est d'un type qui n'utilise pas de révisions ou qu'elle n'a pas encore été mise à jour.Si un déploiement semble avoir échoué, accédez à l'onglet Événements. Cette page est souvent la source d'informations la plus utile, car elle affiche les événements au niveau de Kubernetes.
Pour consulter les journaux de votre application, cliquez sur l'onglet Journaux. Cette page vous aide à comprendre ce qui se passe dans votre cluster. Recherchez ici les messages d'erreur et les traces de pile qui peuvent vous aider à diagnostiquer les problèmes.
Pour confirmer exactement ce qui a été déployé, consultez l'onglet YAML. Cette page affiche le fichier manifeste YAML actif de la charge de travail telle qu'elle existe sur le cluster. Ces informations sont utiles pour identifier les éventuelles incohérences dans vos fichiers manifestes contrôlés par source. Si vous consultez le fichier manifeste YAML d'un seul pod, cet onglet affiche également l'état du pod, ce qui fournit des informations sur les échecs au niveau du pod.
Examiner l'état du cluster avec l'outil de ligne de commande kubectl
Bien que la console Trusted Cloud vous aide à comprendre si un problème existe, l'outil en ligne de commande kubectl
est essentiel pour en découvrir la cause. En communiquant directement avec le plan de contrôle Kubernetes, l'outil de ligne de commande kubectl
vous permet de recueillir les informations détaillées dont vous avez besoin pour résoudre les problèmes liés à votre environnement GKE.
Les sections suivantes vous présentent quelques commandes essentielles qui constituent un excellent point de départ pour le dépannage de GKE.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Installez kubectl.
Configurez l'outil de ligne de commande
kubectl
pour communiquer avec votre cluster :gcloud container clusters get-credentials CLUSTER_NAME \ --location=LOCATION
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du clusterLOCATION
: emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.
Vérifiez vos autorisations. Pour vérifier si vous disposez des autorisations requises pour exécuter les commandes
kubectl
, utilisez la commandekubectl auth can-i
. Par exemple, pour vérifier si vous êtes autorisé à exécuterkubectl get nodes
, exécutez la commandekubectl auth can-i get nodes
.Si vous disposez des autorisations requises, la commande renvoie
yes
. Sinon, elle renvoieno
.Si vous n'êtes pas autorisé à exécuter une commande
kubectl
, un message d'erreur semblable à celui-ci peut s'afficher :Error from server (Forbidden): pods "POD_NAME" is forbidden: User "USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the namespace "default"
Si vous ne disposez pas des autorisations requises, demandez à l'administrateur de votre cluster de vous attribuer les rôles nécessaires.
Obtenir un aperçu de ce qui est en cours d'exécution
La commande kubectl get
vous permet d'obtenir une vue d'ensemble de ce qui se passe dans votre cluster. Utilisez les commandes suivantes pour afficher l'état de deux des composants de cluster les plus importants, les nœuds et les pods :
Pour vérifier si vos nœuds sont opérationnels, affichez les détails de tous les nœuds et de leurs états :
kubectl get nodes
Le résultat ressemble à ce qui suit :
NAME STATUS ROLES AGE VERSION gke-cs-cluster-default-pool-8b8a777f-224a Ready <none> 4d23h v1.32.3-gke.1785003 gke-cs-cluster-default-pool-8b8a777f-egb2 Ready <none> 4d22h v1.32.3-gke.1785003 gke-cs-cluster-default-pool-8b8a777f-p5bn Ready <none> 4d22h v1.32.3-gke.1785003
Tout état autre que
Ready
nécessite une enquête supplémentaire.Pour vérifier si vos pods sont opérationnels, affichez les détails de tous les pods et de leurs états :
kubectl get pods --all-namespaces
Le résultat ressemble à ce qui suit :
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system netd-6nbsq 3/3 Running 0 4d23h kube-system netd-g7tpl 3/3 Running 0 4d23h
Tout état autre que
Running
nécessite une enquête supplémentaire. Voici quelques états courants que vous pouvez rencontrer :Running
: état d'exécution sain.Pending
: le pod est en attente de planification sur un nœud.CrashLoopBackOff
: les conteneurs du pod plantent en boucle à plusieurs reprises, car l'application démarre, quitte avec une erreur, puis est redémarrée par Kubernetes.ImagePullBackOff
: le pod ne peut pas extraire l'image de conteneur.
Les commandes précédentes ne sont que deux exemples d'utilisation de la commande kubectl
get
. Vous pouvez également utiliser cette commande pour en savoir plus sur de nombreux types de ressources Kubernetes. Pour obtenir la liste complète des ressources que vous pouvez explorer, consultez kubectl get dans la documentation Kubernetes.
En savoir plus sur des ressources spécifiques
Une fois que vous avez identifié un problème, vous devez obtenir plus d'informations. Par exemple, un problème peut être un pod dont l'état n'est pas Running
. Pour obtenir plus de détails, utilisez la commande kubectl describe
.
Par exemple, pour décrire un pod spécifique, exécutez la commande suivante :
kubectl describe pod POD_NAME -n NAMESPACE_NAME
Remplacez les éléments suivants :
POD_NAME
: nom du pod qui rencontre des problèmes.NAMESPACE_NAME
: espace de noms dans lequel se trouve le pod. Si vous n'êtes pas sûr de l'espace de noms, consultez la colonneNamespace
dans le résultat de la commandekubectl get pods
.
Le résultat de la commande kubectl describe
inclut des informations détaillées sur votre ressource. Voici quelques-unes des sections les plus utiles à consulter lorsque vous résolvez un problème lié à un Nest :
Status
: état actuel du pod.Conditions
: état de santé et disponibilité globale du pod.Restart Count
: nombre de fois où les conteneurs du pod ont redémarré. Un nombre élevé peut être préoccupant.Events
: journal des événements importants qui se sont produits pour ce pod, comme sa programmation sur un nœud, l'extraction de son image de conteneur et les éventuelles erreurs survenues. La sectionEvents
contient souvent des indices directs sur la raison de l'échec d'un pod.
Comme la commande kubectl get
, vous pouvez utiliser la commande kubectl describe
pour en savoir plus sur plusieurs types de ressources. Pour obtenir la liste complète des ressources que vous pouvez explorer, consultez kubectl describe dans la documentation Kubernetes.
Effectuer des analyses historiques avec Cloud Logging
Bien que l'outil de ligne de commande kubectl
soit indispensable pour inspecter l'état actuel de vos objets Kubernetes, sa vue est souvent limitée au moment présent. Pour comprendre la cause racine d'un problème, vous devez souvent examiner ce qui s'est passé au fil du temps. Lorsque vous avez besoin de ce contexte historique, utilisez Cloud Logging.
Cloud Logging agrège les journaux de vos clusters GKE, de vos applications conteneurisées et d'autres services Trusted Cloud .
Comprendre les principaux types de journaux pour le dépannage
Cloud Logging collecte automatiquement plusieurs types de journaux GKE qui peuvent vous aider à résoudre les problèmes :
Journaux de nœud et d'exécution (
kubelet
,containerd
) : journaux des services de nœud sous-jacents. Étant donné quekubelet
gère le cycle de vie de tous les pods sur le nœud, ses journaux sont essentiels pour résoudre les problèmes tels que les démarrages de conteneurs, les événements de mémoire insuffisante (OOM), les échecs de vérification et les erreurs de montage de volume. Ces journaux sont également essentiels pour diagnostiquer les problèmes au niveau des nœuds, par exemple un nœud dont l'état estNotReady
.Comme containerd gère le cycle de vie de vos conteneurs, y compris l'extraction d'images, ses journaux sont essentiels pour résoudre les problèmes qui surviennent avant que le kubelet puisse démarrer le conteneur. Les journaux containerd vous aident à diagnostiquer les problèmes au niveau des nœuds dans GKE, car ils documentent les activités spécifiques et les erreurs potentielles de l'environnement d'exécution du conteneur.
Journaux d'application (
stdout
,stderr
) : flux de sortie et d'erreur standards de vos processus conteneurisés. Ces journaux sont essentiels pour déboguer les problèmes spécifiques aux applications, tels que les plantages, les erreurs ou les comportements inattendus.Journaux d'audit : ces journaux répondent à la question "Qui a fait quoi, où et quand ?" pour votre cluster. Ils permettent de suivre les actions d'administration et les appels d'API effectués sur le serveur d'API Kubernetes, ce qui est utile pour diagnostiquer les problèmes causés par des modifications de configuration ou un accès non autorisé.
Scénarios de dépannage courants
Une fois que vous avez identifié un problème, vous pouvez interroger ces journaux pour savoir ce qui s'est passé. Pour vous aider à vous lancer, l'examen des journaux peut vous aider à résoudre les problèmes suivants :
- Si un nœud est à l'état
NotReady
, consultez ses journaux. Les journauxkubelet
etcontainerd
révèlent souvent la cause sous-jacente, comme des problèmes de réseau ou des contraintes de ressources. - Si un nouveau nœud ne parvient pas à être provisionné ni à rejoindre le cluster, consultez les journaux du port série du nœud. Ces journaux enregistrent l'activité de démarrage anticipé et de démarrage de kubelet avant que les agents de journalisation du nœud ne soient entièrement actifs.
- Si un pod n'a pas démarré dans le passé, examinez les journaux d'application de ce pod pour vérifier s'il y a eu des plantages. Si les journaux sont vides ou si le pod ne peut pas être planifié, consultez les journaux d'audit pour trouver les événements pertinents ou les journaux de nœud sur le nœud cible pour obtenir des indices sur la pression des ressources ou les erreurs d'extraction d'image.
- Si un déploiement critique a été supprimé sans que personne ne sache pourquoi, interrogez les journaux d'audit Activité d'administration. Ces journaux peuvent vous aider à identifier le compte d'utilisateur ou de service qui a émis l'appel d'API de suppression, ce qui constitue un point de départ clair pour votre enquête.
Accéder aux journaux
Utilisez l'explorateur de journaux pour interroger, afficher et analyser les journaux GKE dans la console Trusted Cloud . L'explorateur de journaux fournit de puissantes options de filtrage qui vous aident à isoler votre problème.
Pour accéder à l'explorateur de journaux et l'utiliser, procédez comme suit :
Dans la console Trusted Cloud , accédez à la page Explorateur de journaux.
Dans le volet Requête, saisissez une requête. Utilisez le langage de requête Logging pour rédiger des requêtes ciblées. Voici quelques filtres courants pour vous aider à démarrer :
Type de filtre Description Exemple de valeur resource.type
Type de ressource Kubernetes. k8s_cluster
,k8s_node
,k8s_pod
,k8s_container
log_id
Flux de journaux de la ressource. stdout
,stderr
resource.labels.RESOURCE_TYPE.name
Filtrez les ressources portant un nom spécifique.
RemplacezRESOURCE_TYPE
par le nom de la ressource que vous souhaitez interroger. Par exemple,namespace
oupod
.example-namespace-name
,example-pod-name
severity
Niveau de gravité du journal. DEFAULT
,INFO
,WARNING
,ERROR
etCRITICAL
jsonPayload.message=~
Recherche par expression régulière d'un texte dans le message de journal. scale.down.error.failed.to.delete.node.min.size.reached
Par exemple, pour résoudre les problèmes liés à un pod spécifique, vous pouvez isoler ses journaux d'erreurs. Pour n'afficher que les journaux dont la gravité est définie sur
ERROR
pour ce pod, utilisez la requête suivante :resource.type="k8s_container" resource.labels.pod_name="POD_NAME" resource.labels.namespace_name="NAMESPACE_NAME" severity=ERROR
Remplacez les éléments suivants :
POD_NAME
: nom du pod qui rencontre des problèmes.NAMESPACE_NAME
: espace de noms dans lequel se trouve le pod. Si vous n'êtes pas sûr de l'espace de noms, consultez la colonneNamespace
dans le résultat de la commandekubectl get pods
.
Pour obtenir d'autres exemples, consultez Requêtes liées à Kubernetes dans la documentation Google Cloud Observability.
Cliquez sur Exécuter la requête.
Pour afficher le message de journal complet, y compris la charge utile JSON, les métadonnées et l'horodatage, cliquez sur l'entrée de journal.
Pour en savoir plus sur les journaux GKE, consultez À propos des journaux GKE.
Effectuer une surveillance proactive avec Cloud Monitoring
Après un problème, l'examen des journaux est une étape essentielle du dépannage. Toutefois, un système véritablement résilient nécessite également une approche proactive pour identifier les problèmes avant qu'ils ne provoquent une panne.
Pour identifier de manière proactive les futurs problèmes et suivre les indicateurs clés de performances au fil du temps, utilisez Cloud Monitoring. Cloud Monitoring fournit des tableaux de bord, des métriques et des fonctionnalités d'alerte. Ces outils vous aident à identifier les taux d'erreur en hausse, l'augmentation de la latence ou les contraintes de ressources, ce qui vous permet d'agir avant que les utilisateurs ne soient affectés.
Examiner les métriques utiles
GKE envoie automatiquement un ensemble de métriques à Cloud Monitoring. Les sections suivantes listent certaines des métriques les plus importantes pour le dépannage :
- Métriques sur les performances et l'état des conteneurs
- Métriques de performances et d'état des nœuds
- Métriques sur les performances et l'état des pods
Pour obtenir la liste complète des métriques GKE, consultez Métriques système GKE.
Métriques de performances et d'état des conteneurs
Commencez par ces métriques lorsque vous suspectez un problème avec une application spécifique. Elles vous aident à surveiller l'état de votre application, y compris à déterminer si un conteneur redémarre fréquemment, manque de mémoire ou est limité par les limites de processeur.
Métrique | Description | Importance de la résolution des problèmes |
---|---|---|
kubernetes.io/container/cpu/limit_utilization |
Fraction de la limite de processeur actuellement utilisée sur l'instance. Cette valeur peut être supérieure à 1, car un conteneur peut être autorisé à dépasser sa limite de processeur. | Identifie la limitation du processeur. Des valeurs élevées peuvent entraîner une dégradation des performances. |
kubernetes.io/container/memory/limit_utilization |
Fraction de la limite de mémoire actuellement utilisée sur l'instance. Cette valeur ne peut pas être supérieure à 1. | Surveille le risque d'erreurs de mémoire insuffisante (OOM). |
kubernetes.io/container/memory/used_bytes |
Mémoire réelle consommée par le conteneur en octets. | Suit la consommation de mémoire pour identifier les fuites de mémoire potentielles ou le risque d'erreurs OOM. |
kubernetes.io/container/memory/page_fault_count |
Nombre de défauts de page, ventilés par types : majeurs et mineurs. | Indique une forte sollicitation de la mémoire. Les défauts de page majeurs signifient que la mémoire est lue à partir du disque (permutation), même si les limites de mémoire ne sont pas atteintes. |
kubernetes.io/container/restart_count |
Nombre de redémarrages du conteneur. | Met en évidence les problèmes potentiels tels que les plantages d'applications, les erreurs de configuration ou l'épuisement des ressources en raison d'un nombre élevé ou croissant de redémarrages. |
kubernetes.io/container/ephemeral_storage/used_bytes |
Utilisation du stockage éphémère local, en octets. | Surveille l'utilisation du disque temporaire pour éviter l'éviction des pods en raison d'un stockage éphémère complet. |
kubernetes.io/container/cpu/request_utilization |
Fraction des ressources processeur demandées en cours d'utilisation sur l'instance. Cette valeur peut être supérieure à 1, car l'utilisation peut dépasser la demande. | Identifie les demandes de processeur surprovisionnées ou sous-provisionnées pour vous aider à optimiser l'allocation des ressources. |
kubernetes.io/container/memory/request_utilization |
Fraction des ressources mémoire demandées en cours d'utilisation sur l'instance. Cette valeur peut être supérieure à 1, car l'utilisation peut dépasser la demande. | Identifie les demandes de mémoire surprovisionnées ou sous-provisionnées pour améliorer la planification et éviter les erreurs OOM. |
Métriques de performances et d'état des nœuds
Examinez ces métriques lorsque vous devez diagnostiquer des problèmes liés à l'infrastructure GKE sous-jacente. Ces métriques sont essentielles pour comprendre l'état et la capacité globale de vos nœuds. Elles vous aident à déterminer si un nœud est défaillant ou sous pression, ou s'il dispose de suffisamment de mémoire pour planifier de nouveaux pods.
Métrique | Description | Importance de la résolution des problèmes |
---|---|---|
kubernetes.io/node/cpu/allocatable_utilization |
Fraction du processeur allouable actuellement en cours d'utilisation sur l'instance. | Indique si la somme de l'utilisation des pods met à rude épreuve les ressources de processeur disponibles du nœud. |
kubernetes.io/node/memory/allocatable_utilization |
Fraction de la mémoire allouable actuellement utilisée sur l'instance. Cette valeur ne peut pas être supérieure à 1, car l'utilisation ne peut pas dépasser la quantité de mémoire allouable en octets. | Suggère que le nœud manque de mémoire pour planifier de nouveaux pods ou pour que les pods existants fonctionnent, en particulier lorsque les valeurs sont élevées. |
kubernetes.io/node/status_condition (BÊTA) |
Condition d'un nœud à partir du champ de condition d'état du nœud. | Indique les conditions d'état des nœuds, telles que Ready , MemoryPressure ou DiskPressure . |
kubernetes.io/node/ephemeral_storage/used_bytes |
Nombre d'octets de stockage éphémère local utilisés par le nœud. | Aide à éviter les échecs de démarrage ou les expulsions de pods en fournissant des avertissements sur l'utilisation élevée du stockage éphémère. |
kubernetes.io/node/ephemeral_storage/inodes_free |
Nombre d'inodes libres sur le stockage éphémère local. | Surveille le nombre d'inodes libres. Un manque de nœuds d'index peut interrompre les opérations, même si de l'espace disque est disponible. |
kubernetes.io/node/interruption_count (BÊTA) |
Les interruptions sont des évictions système de l'infrastructure, alors que le client en a le contrôle. Cette métrique correspond au nombre actuel d'interruptions par type et par motif. | Explique pourquoi un nœud peut disparaître de manière inattendue en raison d'évictions système. |
Métriques de performances et d'état des pods
Ces métriques vous aident à résoudre les problèmes liés à l'interaction d'un pod avec son environnement, comme la mise en réseau et le stockage. Utilisez ces métriques lorsque vous devez diagnostiquer des pods qui démarrent lentement, examiner des problèmes potentiels de connectivité réseau ou gérer de manière proactive le stockage pour éviter les échecs d'écriture dus à des volumes pleins.
Métrique | Description | Importance de la résolution des problèmes |
---|---|---|
kubernetes.io/pod/network/received_bytes_count |
Nombre cumulé d'octets reçus par le pod sur le réseau. | Identifie les activités réseau inhabituelles (élevées ou faibles) qui peuvent indiquer des problèmes d'application ou de réseau. |
kubernetes.io/pod/network/policy_event_count (BÊTA) |
Variation du nombre d'événements liés aux règles de réseau observés dans le plan de données. | Identifie les problèmes de connectivité causés par les règles réseau. |
kubernetes.io/pod/volume/utilization |
Fraction du volume en cours d'utilisation par l'instance. Cette valeur ne peut pas être supérieure à 1, car l'utilisation ne peut pas dépasser l'espace total disponible pour le volume. | Permet de gérer de manière proactive l'espace de volume en envoyant un avertissement lorsque l'utilisation élevée (proche de 1) peut entraîner des échecs d'écriture. |
kubernetes.io/pod/latencies/pod_first_ready (BÊTA) |
Latence de démarrage de bout en bout du pod (de "Pod créé" à "Prêt"), y compris les extractions d'images. | Diagnostique les pods qui mettent du temps à démarrer. |
Visualiser les métriques avec l'explorateur de métriques
Pour visualiser l'état de votre environnement GKE, créez des graphiques basés sur des métriques avec l'explorateur de métriques.
Pour utiliser l'explorateur de métriques, procédez comme suit :
Dans la console Trusted Cloud , accédez à la page Explorateur de métriques.
Dans le champ Métriques, sélectionnez ou saisissez la métrique que vous souhaitez examiner.
Affichez les résultats et observez les tendances au fil du temps.
Par exemple, pour examiner la consommation de mémoire des pods dans un espace de noms spécifique, vous pouvez procéder comme suit :
- Dans la liste Sélectionner une métrique, sélectionnez la métrique
kubernetes.io/container/memory/used_bytes
, puis cliquez sur Appliquer. - Cliquez sur Ajouter un filtre, puis sélectionnez namespace_name.
- Dans la liste Valeur, sélectionnez l'espace de noms que vous souhaitez examiner.
- Dans le champ Agrégation, sélectionnez Somme > pod_name, puis cliquez sur OK. Ce paramètre affiche une ligne de série temporelle distincte pour chaque pod.
- Cliquez sur Enregistrer le graphique.
Le graphique obtenu vous montre l'utilisation de la mémoire pour chaque pod au fil du temps, ce qui peut vous aider à identifier visuellement les pods dont la consommation de mémoire est inhabituellement élevée ou en pic.
L'explorateur de métriques offre une grande flexibilité pour construire les métriques que vous souhaitez afficher. Pour en savoir plus sur les options avancées de l'explorateur de métriques, consultez Créer des graphiques avec l'explorateur de métriques dans la documentation Cloud Monitoring.
Créer des alertes pour détecter les problèmes de manière proactive
Pour recevoir des notifications en cas de problème ou lorsque des métriques dépassent certains seuils, configurez des règles d'alerte dans Cloud Monitoring.
Par exemple, pour configurer une règle d'alerte qui vous avertit lorsque la limite d'utilisation du processeur du conteneur dépasse 80 % pendant cinq minutes, procédez comme suit :
Dans la console Trusted Cloud , accédez à la page Alertes.
Cliquez sur Créer une règle.
Dans la zone Sélectionner une métrique, filtrez sur
CPU limit utilization
, puis sélectionnez la métrique suivante : kubernetes.io/container/cpu/limit_utilization.Cliquez sur Appliquer.
Laissez le champ Ajouter un filtre vide. Ce paramètre déclenche une alerte lorsqu'un cluster dépasse votre seuil.
Dans la section Transformer les données, procédez comme suit :
- Dans la liste Fenêtre glissante, sélectionnez 1 minute. Ce paramètre signifie que Trusted Cloud calcule une valeur moyenne chaque minute.
Dans la liste Fonction de fenêtrage glissante, sélectionnez moyenne.
Ces deux paramètres calculent la moyenne de l'utilisation de la limite de processeur pour chaque conteneur toutes les minutes.
Cliquez sur Suivant.
Dans la section Configurer l'alerte, procédez comme suit :
- Pour Type de condition, sélectionnez Seuil.
- Pour Déclencheur d'alerte, sélectionnez À chaque infraction de série temporelle.
- Pour Position du seuil, sélectionnez Au-dessus du seuil.
- Dans le champ Valeur du seuil, saisissez
0.8
. Cette valeur représente le seuil de 80 % que vous souhaitez surveiller. - Cliquez sur Options avancées.
- Dans la liste Période de nouveau test, sélectionnez 5 min. Ce paramètre signifie que l'alerte ne se déclenche que si l'utilisation du processeur reste supérieure à 80 % pendant une période continue de cinq minutes, ce qui réduit les fausses alertes dues à de brefs pics.
- Dans le champ Nom de la condition, attribuez un nom descriptif à la condition.
- Cliquez sur Suivant.
Dans la section Configurer les notifications et finaliser l'alerte, procédez comme suit :
- Dans la liste Canaux de notification, sélectionnez le canal sur lequel vous souhaitez recevoir l'alerte. Si vous n'avez pas de canal, cliquez sur Gérer les canaux de notification pour en créer un.
- Dans le champ Nom de la règle d'alerte, attribuez à la règle un nom clair et descriptif.
- Conservez les valeurs par défaut dans les autres champs.
- Cliquez sur Suivant.
Vérifiez votre règle. Si tout semble correct, cliquez sur Créer une règle.
Pour découvrir d'autres façons de créer des alertes, consultez Présentation des alertes dans la documentation Cloud Monitoring.
Accélérer le diagnostic avec Gemini Cloud Assist
Parfois, la cause de votre problème n'est pas immédiatement évidente, même lorsque vous avez utilisé les outils décrits dans les sections précédentes. L'examen des cas complexes peut prendre du temps et nécessite une expertise approfondie. Dans ce type de scénario, Gemini Cloud Assist peut vous aider. Elle peut détecter automatiquement les schémas cachés, identifier les anomalies et fournir des résumés pour vous aider à identifier rapidement une cause probable.
Accéder à Gemini Cloud Assist
Pour accéder à Gemini Cloud Assist, procédez comme suit :
- Dans la console Trusted Cloud , accédez à n'importe quelle page.
Dans la barre d'outils de la console Trusted Cloud , cliquez sur spark Ouvrir ou fermer le chat Gemini Cloud Assist.
Le panneau Cloud Assist s'ouvre. Vous pouvez cliquer sur des exemples de requêtes s'ils s'affichent, ou saisir une requête dans le champ Saisissez une requête.
Découvrir des exemples de requêtes
Pour vous aider à comprendre comment Gemini Cloud Assist peut vous aider, voici quelques exemples de requêtes :
Thème | Scénario | Exemple de requête | Comment Gemini Cloud Assist peut vous aider |
---|---|---|---|
Message d'erreur ambigu | Un pod présente l'état CrashLoopBackoff , mais le message d'erreur est difficile à comprendre. |
Que signifie cette erreur de pod GKE et quelles en sont les causes courantes : panic: runtime error: invalid memory address or nil pointer dereference ? |
Gemini Cloud Assist analyse le message et l'explique clairement. Il propose également des causes et des solutions potentielles. |
Problèmes de performances | Votre équipe constate une latence élevée pour une application qui s'exécute dans GKE. | Mon service api-gateway dans le cluster GKE prod présente une latence élevée. Quelles métriques dois-je vérifier en premier ? Pouvez-vous me suggérer des causes courantes liées à GKE ? |
Gemini Cloud Assist suggère des métriques clés à examiner, explore les problèmes potentiels (par exemple, les contraintes de ressources ou la congestion du réseau) et recommande des outils et des techniques pour une analyse plus approfondie. |
Problèmes de nœuds | Un nœud GKE est bloqué avec l'état NotReady . |
L'un de mes nœuds GKE (node-xyz ) affiche l'état NotReady . Quelles sont les étapes de dépannage habituelles ? |
Gemini Cloud Assist fournit un plan d'investigation détaillé, explique des concepts tels que la réparation automatique des nœuds et suggère des commandes kubectl pertinentes. |
Comprendre GKE | Vous n'êtes pas sûr d'une fonctionnalité GKE spécifique ou de la façon d'implémenter une bonne pratique. | Quelles sont les bonnes pratiques pour sécuriser un cluster GKE ? Puis-je en savoir plus ? | Gemini Cloud Assist fournit des explications claires sur les bonnes pratiques GKE. Cliquez sur Afficher le contenu associé pour afficher des liens vers la documentation officielle. |
Pour en savoir plus, consultez les ressources suivantes :
- Découvrez comment rédiger des requêtes plus efficaces.
- Découvrez comment utiliser le panneau Gemini Cloud Assist.
- Consultez la présentation de Gemini pour Trusted Cloud .
- Découvrez comment Gemini pour Trusted Cloud by S3NS utilise vos données.
Utiliser les investigations Gemini Cloud Assist
En plus du chat interactif, Gemini Cloud Assist peut effectuer des analyses plus approfondies et automatisées grâce à Gemini Cloud Assist Investigations. Cette fonctionnalité est intégrée directement aux workflows tels que l'explorateur de journaux. Il s'agit d'un outil puissant d'analyse des causes premières.
Lorsque vous lancez une investigation à partir d'une erreur ou d'une ressource spécifique, Gemini Cloud Assist analyse les journaux, les configurations et les métriques. Il utilise ces données pour générer des observations et des hypothèses classées sur les causes racines probables, puis vous fournit les prochaines étapes recommandées. Vous pouvez également transférer ces résultats vers une demande d'assistance Trusted Cloud by S3NS pour fournir un contexte utile qui peut vous aider à résoudre votre problème plus rapidement.
Pour en savoir plus, consultez Investigations Gemini Cloud Assist dans la documentation Gemini.
Synthèse : exemple de scénario de dépannage
Cet exemple montre comment utiliser une combinaison d'outils GKE pour diagnostiquer et comprendre un problème courant en conditions réelles : un conteneur qui plante à plusieurs reprises en raison d'une mémoire insuffisante.
Le scénario
Vous êtes l'ingénieur d'astreinte pour une application Web nommée product-catalog
qui s'exécute dans GKE.
Votre enquête commence lorsque vous recevez une alerte automatique de Cloud Monitoring :
Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.
Cette alerte vous informe qu'un problème existe et qu'il est lié à la charge de travail product-catalog
.
Confirmer le problème dans la console Trusted Cloud
Vous commencez par une vue d'ensemble de vos charges de travail pour confirmer le problème.
- Dans la console Trusted Cloud , accédez à la page Charges de travail et filtrez sur votre charge de travail
product-catalog
. - Vous consultez la colonne d'état Pods. Au lieu de l'état opérationnel
3/3
, la valeur indique un état non opérationnel :2/3
. Cette valeur indique que l'un des pods de votre application n'a pas l'étatReady
. - Vous souhaitez en savoir plus. Vous cliquez donc sur le nom de la charge de travail
product-catalog
pour accéder à sa page d'informations. - Sur la page des détails, vous verrez la section Pods gérés. Vous identifiez immédiatement un problème : la colonne
Restarts
de votre pod affiche14
, un nombre inhabituellement élevé.
Ce nombre élevé de redémarrages confirme que le problème est à l'origine de l'instabilité de l'application et suggère qu'un conteneur échoue à ses vérifications d'état ou plante.
Trouver la raison avec les commandes kubectl
Maintenant que vous savez que votre application redémarre à plusieurs reprises, vous devez en trouver la raison. La commande kubectl describe
est un bon outil pour cela.
Vous obtenez le nom exact du pod instable :
kubectl get pods -n prod
Le résultat est le suivant :
NAME READY STATUS RESTARTS AGE product-catalog-d84857dcf-g7v2x 0/1 CrashLoopBackOff 14 25m product-catalog-d84857dcf-lq8m4 1/1 Running 0 2h30m product-catalog-d84857dcf-wz9p1 1/1 Running 0 2h30m
Décrivez le pod instable pour obtenir l'historique détaillé des événements :
kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod
Vous examinez le résultat et trouvez des indices dans les sections
Last State
etEvents
:Containers: product-catalog-api: ... State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: OOMKilled Exit Code: 137 Started: Mon, 23 Jun 2025 10:50:15 -0700 Finished: Mon, 23 Jun 2025 10:54:58 -0700 Ready: False Restart Count: 14 ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 25m default-scheduler Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a Normal Pulled 8m (x14 over 25m) kubelet Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine Normal Created 8m (x14 over 25m) kubelet Created container product-catalog-api Normal Started 8m (x14 over 25m) kubelet Started container product-catalog-api Warning BackOff 3m (x68 over 22m) kubelet Back-off restarting failed container
Le résultat vous donne deux indices essentiels :
- Tout d'abord, la section
Last State
indique que le conteneur a été arrêté avecReason: OOMKilled
, ce qui signifie qu'il a manqué de mémoire. Cette raison est confirmée par leExit Code: 137
, qui est le code de sortie Linux standard pour un processus qui a été arrêté en raison d'une consommation excessive de mémoire. - Ensuite, la section
Events
affiche un événementWarning: BackOff
avec le messageBack-off restarting failed container
. Ce message confirme que le conteneur est dans une boucle d'échec, qui est la cause directe de l'étatCrashLoopBackOff
que vous avez vu précédemment.
- Tout d'abord, la section
Visualiser le comportement avec des métriques
La commande kubectl describe
vous a indiqué ce qui s'est passé, mais Cloud Monitoring peut vous montrer le comportement de votre environnement au fil du temps.
- Dans la console Trusted Cloud , accédez à l'explorateur de métriques.
- Vous sélectionnez la métrique
container/memory/used_bytes
. - Vous filtrez la sortie pour n'afficher que votre cluster, votre espace de noms et votre nom de pod spécifiques.
Le graphique montre un schéma distinct : l'utilisation de la mémoire augmente régulièrement, puis chute brusquement à zéro lorsque le conteneur est arrêté en raison d'une erreur de mémoire insuffisante et redémarre. Cette preuve visuelle confirme une fuite de mémoire ou une limite de mémoire insuffisante.
Identifier la cause dans les journaux
Vous savez maintenant que le conteneur manque de mémoire, mais vous ne savez toujours pas exactement pourquoi. Pour identifier la cause première, utilisez l'explorateur de journaux.
- Dans la console Trusted Cloud , accédez à l'explorateur de journaux.
Vous écrivez une requête pour filtrer les journaux de votre conteneur spécifique à partir de juste avant l'heure du dernier plantage (que vous avez vu dans la sortie de la commande
kubectl describe
) :resource.type="k8s_container" resource.labels.cluster_name="example-cluster" resource.labels.namespace_name="prod" resource.labels.pod_name="product-catalog-d84857dcf-g7v2x" timestamp >= "2025-06-23T17:50:00Z" timestamp < "2025-06-23T17:55:00Z"
Dans les journaux, vous trouverez un schéma de messages récurrent juste avant chaque plantage :
{ "message": "Processing large image file product-image-large.jpg", "severity": "INFO" }, { "message": "WARN: Memory cache size now at 248MB, nearing limit.", "severity": "WARNING" }
Ces entrées de journal indiquent que l'application tente de traiter des fichiers image volumineux en les chargeant entièrement en mémoire, ce qui finit par épuiser la limite de mémoire du conteneur.
Résultats
En utilisant ces outils ensemble, vous obtenez une vue d'ensemble du problème :
- L'alerte de surveillance vous a informé qu'un problème était survenu.
- La console Trusted Cloud vous a montré que le problème affectait les utilisateurs (redémarrages).
- Les commandes
kubectl
ont permis d'identifier la raison exacte des redémarrages (OOMKilled
). - L'explorateur de métriques a visualisé le modèle de fuite de mémoire au fil du temps.
- L'explorateur de journaux a révélé le comportement spécifique à l'origine du problème de mémoire.
Vous êtes maintenant prêt à implémenter une solution. Vous pouvez optimiser le code de l'application pour gérer les fichiers volumineux plus efficacement ou, comme solution à court terme, augmenter la limite de mémoire du conteneur (plus précisément la valeur spec.containers.resources.limits.memory
) dans le fichier manifeste YAML de la charge de travail.
Étapes suivantes
Pour obtenir des conseils sur la résolution de problèmes spécifiques, consultez les guides de dépannage de GKE.
Si vous ne trouvez pas de solution à votre problème dans la documentation, consultez Obtenir de l'aide pour obtenir une assistance supplémentaire, y compris des conseils sur les sujets suivants :
- Ouvrez une demande d'assistance en contactant le service client Google Cloud.
- Obtenir de l'aide de la communauté en posant des questions sur Stack Overflow et en utilisant le tag
google-kubernetes-engine
pour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack#kubernetes-engine
pour obtenir de l'aide auprès de la communauté. - Signaler des bugs ou demander des fonctionnalités à l'aide de l'outil public de suivi des problèmes.