Dépannage

Cette page explique comment résoudre les problèmes liés à l'utilisation de Google Kubernetes Engine (GKE).

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Déboguer des ressources Kubernetes

Pour les ressources Kubernetes, si vous rencontrez un problème avec :

Résoudre les problèmes liés à la commande kubectl

Cette section contient les étapes de dépannage pour plusieurs types de problèmes liés à la commande kubectl.

Problème : la commande kubectl est introuvable

Si vous recevez un message indiquant que la commande kubectl est introuvable, réinstallez le binaire kubectl et définissez votre variable d'environnement $PATH :

  1. Installez le binaire kubectl en exécutant la commande suivante :

    gcloud components update kubectl

  2. Répondez "Oui" lorsque le programme d'installation vous invite à modifier votre variable d'environnement $PATH. La modification de cette variable vous permet d'utiliser les commandes kubectl sans avoir à saisir leur chemin d'accès complet.

    Vous pouvez également ajouter la ligne suivante à l'emplacement où votre interface système stocke les variables d'environnement, par exemple ~/.bashrc (ou ~/.bash_profile sous macOS) :

    export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/

  3. Exécutez la commande suivante pour charger votre fichier mis à jour. L'exemple suivant utilise .bashrc.

    source ~/.bashrc

    Si vous utilisez macOS, utilisez ~/.bash_profile au lieu de .bashrc.

Problème : les commandes kubectl renvoient une erreur de type "connexion refusée"

Si les commandes kubectl renvoient une erreur de type "connexion refusée", vous devez définir le contexte de cluster à l'aide de la commande suivante :

  gcloud container clusters get-credentials CLUSTER_NAME

Si vous ne savez pas quoi indiquer pour CLUSTER_NAME, utilisez la commande suivante pour répertorier vos clusters :

  gcloud container clusters list

Erreur : la commande kubectl a expiré

Si vous avez créé un cluster et que vous avez tenté d'exécuter la commande kubectl sur le cluster, mais que la commande kubectl a expiré, un message d'erreur s'affiche, par exemple :

  • Unable to connect to the server: dial tcp IP_ADDRESS: connect: connection timed out
  • Unable to connect to the server: dial tcp IP_ADDRESS: i/o timeout.

Ces erreurs indiquent que kubectl ne parvient pas à communiquer avec le plan de contrôle du cluster.

Pour résoudre ce problème, vérifiez et définissez le contexte dans lequel le cluster est défini, puis assurez-vous de la connectivité au cluster :

  1. Accédez à $HOME/.kube/config ou exécutez la commande kubectl config view pour vérifier que le fichier de configuration contient le contexte du cluster et l'adresse IP externe du plan de contrôle.

  2. Définissez les identifiants du cluster:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --project=PROJECT_ID

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • COMPUTE_LOCATION: emplacement Compute Engine.
    • PROJECT_ID: ID du projet dans lequel le cluster GKE a été créé.

  3. Si le cluster est un cluster GKE privé, assurez-vous que sa liste des réseaux autorisés existants inclut l'adresse IP sortante de la machine à partir de laquelle vous essayez de vous connecter. Les réseaux autorisés existants sont visibles dans la console ou au moyen de la commande suivante :

    gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --project=PROJECT_ID \
    --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"

    Si l'adresse IP sortante de la machine ne figure pas dans la liste des réseaux autorisés à partir du résultat de la commande précédente, procédez comme suit :

Erreur : les commandes kubectl renvoient une erreur de type "échec de négociation d'une version d'API"

Si les commandes kubectl renvoient une erreur "échec de négociation d'une version d'API", vous devez vous assurer que kubectl dispose des identifiants d'authentification :

  gcloud auth application-default login

Problème : les commandes kubectl logs, attach, exec et port-forward cessent de répondre

Si les commandes kubectl logs, attach, exec ou port-forward cessent de répondre, le serveur d'API est généralement incapable de communiquer avec les nœuds.

Tout d'abord, vérifiez si votre cluster comporte des nœuds. Si vous avez réduit à zéro le nombre de nœuds du cluster, les commandes ne fonctionnent pas. Pour résoudre ce problème, redimensionnez le cluster afin de disposer d'au moins un nœud.

Si votre cluster comporte au moins un nœud, vérifiez si vous utilisez des tunnels SSH ou proxy Konnectivity pour activer la communication sécurisée. Les sections suivantes décrivent les étapes de dépannage spécifiques à chaque approche :

Résoudre les problèmes liés à SSH

Si vous utilisez SSH, GKE enregistre un fichier de clé publique SSH dans les métadonnées de votre projet Compute Engine. Toutes les VM Compute Engine utilisant des images fournies par Google vérifient régulièrement les métadonnées communes de leur projet et celles de leur instance pour détecter les clés SSH à ajouter à la liste des utilisateurs autorisés de la VM. GKE ajoute également à votre réseau Compute Engine une règle de pare-feu qui autorise l'accès SSH à chaque nœud du cluster à partir de l'adresse IP du plan de contrôle.

Les problèmes liés à SSH peuvent être dus aux causes suivantes :

  • Les règles de pare-feu de votre réseau n'autorisent pas l'accès SSH depuis le plan de contrôle.

    Tous les réseaux Compute Engine sont créés avec une règle de pare-feu appelée default-allow-ssh qui autorise l'accès SSH à partir de toutes les adresses IP (clé privée valide requise). GKE insère également une règle SSH pour chaque cluster public sous la forme gke-CLUSTER_NAME-RANDOM_CHARACTERS-ssh. Cette règle autorise l'accès SSH spécifiquement à partir de l'adresse IP du plan de contrôle vers les nœuds du cluster.

    Si aucune de ces règles n'existe, le plan de contrôle ne peut pas ouvrir les tunnels SSH.

    Pour vérifier que c'est la cause du problème, vérifiez si votre configuration comporte ces règles.

    Pour résoudre ce problème, identifiez le tag présent sur tous les nœuds du cluster, puis ajoutez à nouveau une règle de pare-feu permettant d'accéder aux VM avec ce tag à partir de l'adresse IP du plan de contrôle.

  • L'entrée des métadonnées communes de votre projet pour ssh-keys est saturée.

    Si l'entrée de métadonnées du projet nommée "ssh-keys" est proche de la limite de taille maximale, GKE ne peut pas ajouter sa propre clé SSH pour ouvrir des tunnels SSH.

    Pour vérifier qu'il s'agit bien du problème, vérifiez la longueur de la liste des clés SSH. Vous pouvez voir les métadonnées de votre projet en exécutant la commande suivante, en incluant éventuellement l'option --project :

    gcloud compute project-info describe [--project=PROJECT_ID]

    Pour résoudre ce problème, supprimez les clés SSH dont vous n'avez plus besoin.

  • Vous avez défini un champ de métadonnées avec la clé "ssh-keys" sur les VM du cluster.

    L'agent de nœud sur les VM utilise préférentiellement les clés SSH propres à une instance plutôt que celles définies à l'échelle du projet. Par conséquent, si vous avez défini des clés SSH spécifiquement sur les nœuds du cluster, la clé SSH du plan de contrôle dans les métadonnées du projet n'est pas respectée par les nœuds.

    Pour vérifier qu'il s'agit bien du problème, exécutez gcloud compute instances describe VM_NAME et recherchez un champ ssh-keys dans les métadonnées.

    Pour résoudre le problème, supprimez les clés SSH par instance des métadonnées de l'instance.

Résoudre les problèmes liés au proxy Konnectivity

Vous pouvez déterminer si votre cluster utilise le proxy Konnectivity en vérifiant le déploiement système suivant :

  kubectl get deployments konnectivity-agent --namespace kube-system

Les problèmes liés au proxy Konnectivity peuvent être dus aux causes suivantes :

  • Les règles de pare-feu de votre réseau n'autorisent pas l'agent Konnectivity à accéder au plan de contrôle.

    Lors de la création du cluster, les pods de l'agent Konnectivity établissent et maintiennent une connexion au plan de contrôle sur le port 8132. Lorsque l'une des commandes kubectl est exécutée, le serveur d'API utilise cette connexion pour communiquer avec le cluster.

    Si les règles de pare-feu de votre réseau contiennent une ou plusieurs règles de refus du trafic sortant, l'agent peut empêcher la connexion.

    Pour vérifier que c'est la cause du problème, vérifiez les règles de pare-feu de votre réseau afin de voir si elles contiennent une ou plusieurs règles de refus du trafic sortant.

    Pour résoudre ce problème, autorisez le trafic de sortie vers le plan de contrôle du cluster sur le port 8132. (Par exemple, le serveur d'API utilise 443.)

  • La règle de réseau de votre cluster bloque le trafic entrant depuis l'espace de noms kube-system vers l'espace de noms workload.

    Ces fonctionnalités ne sont pas nécessaires au bon fonctionnement du cluster. Si vous préférez empêcher tout accès extérieur au réseau de votre cluster, sachez que ces fonctionnalités ne sont pas opérationnelles.

    Pour vérifier que c'est la cause du problème, recherchez les règles de réseau dans l'espace de noms concerné en exécutant la commande suivante :

    kubectl get networkpolicy --namespace AFFECTED_NAMESPACE

    Pour résoudre ce problème, ajoutez le code suivant au champ spec.ingress des règles réseau :

    - from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
    podSelector:
      matchLabels:
        k8s-app: konnectivity-agent

Résoudre les problèmes d'erreur 4xx

Les sections suivantes vous aident à résoudre les erreurs 400, 401, 403 et 404, ainsi que les erreurs d'authentification et d'autorisation associées.

Problème : erreurs d'authentification et d'autorisation lors de la connexion aux clusters GKE

Lorsque vous vous connectez à des clusters GKE, vous pouvez recevoir une erreur d'authentification et d'autorisation avec le code d'état HTTP 401 (Accès non autorisé). Ce problème peut se produire lorsque vous essayez d'exécuter une commande kubectl dans votre cluster GKE à partir d'un environnement local.

La cause de ce problème peut être l'une des suivantes:

  • Le plug-in d'authentification gke-gcloud-auth-plugin n'est pas correctement installé ou configuré.
  • Vous ne disposez pas des autorisations nécessaires pour vous connecter au serveur d'API du cluster et exécuter des commandes kubectl.

Pour diagnostiquer la cause, suivez les étapes décrites dans les sections suivantes :

  1. Se connecter au cluster à l'aide de curl
  2. Configurer le plug-in dans kubeconfig

Se connecter au cluster à l'aide de curl

Pour diagnostiquer la cause de l'erreur d'authentification et d'autorisation, connectez-vous au cluster à l'aide de curl. L'utilisation de curl contourne la CLI kubectl et le plug-in gke-gcloud-auth-plugin.

  1. Définissez les variables d'environnement :

    APISERVER=https://$(gcloud container clusters describe CLUSTER_NAME --location=COMPUTE_LOCATION --format "value(endpoint)")
TOKEN=$(gcloud auth print-access-token)

  2. Vérifiez que votre jeton d'accès est valide:

    curl https://oauth2.googleapis.com/tokeninfo?access_token=$TOKEN

  3. Essayez de vous connecter au point de terminaison de l'API principale sur le serveur d'API :

    gcloud container clusters describe CLUSTER_NAME --location=COMPUTE_LOCATION --format "value(masterAuth.clusterCaCertificate)" | base64 -d > /tmp/ca.crt
curl -s -X GET "${APISERVER}/api/v1/namespaces" --header "Authorization: Bearer $TOKEN" --cacert /tmp/ca.crt

    Si la commande curl réussit, vérifiez si le plug-in est à l'origine du problème en suivant les étapes de la section Configurer le plug-in dans kubeconfig.

    Si la commande curl échoue et affiche un résultat semblable au résultat suivant, cela signifie que vous ne disposez pas des autorisations appropriées pour accéder au cluster :

    {
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}

Pour résoudre ce problème, obtenez les autorisations appropriées pour accéder au cluster.

Configurer l'utilisation du plug-in dans kubeconfig

Si vous recevez des erreurs d'authentification et d'autorisation lorsque vous vous connectez à vos clusters, mais que vous avez pu vous connecter au cluster à l'aide de curl, assurez-vous que vous pouvez accéder à votre cluster sans avoir besoin du plug-in gke-gcloud-auth-plugin.

Pour résoudre ce problème, configurez votre environnement local pour qu'il ignore le binaire gke-gcloud-auth-plugin lors de l'authentification auprès du cluster. Dans les clients Kubernetes exécutant la version 1.25 ou ultérieure, le binaire gke-gcloud-auth-plugin est obligatoire. Vous devez donc utiliser la version 1.24 ou antérieure de la CLI kubectl.

Pour accéder à votre cluster sans avoir besoin du plug-in, procédez comme suit :

  1. Installez la version 1.24 de la CLI kubectl à l'aide de curl:

    curl -LO https://dl.k8s.io/release/v1.24.0/bin/linux/amd64/kubectl

    Vous pouvez utiliser n'importe quelle version 1.24 de la CLI kubectl ou version antérieure.

  2. Ouvrez votre fichier de script de démarrage shell, tel que .bashrc pour l'interface système Bash, dans un éditeur de texte:

    vi ~/.bashrc

    Si vous utilisez MacOS, utilisez ~/.bash_profile au lieu de .bashrc dans ces instructions.

  3. Ajoutez la ligne suivante au fichier et enregistrez-le:

    export USE_GKE_GCLOUD_AUTH_PLUGIN=False

  4. Exécutez le script de démarrage:

    source ~/.bashrc

  5. Obtenez les identifiants de votre cluster, qui configure votre fichier .kube/config:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=COMPUTE_LOCATION

    Remplacez les éléments suivants :

  6. Exécutez une commande kubectl:

    kubectl cluster-info

Si vous obtenez une erreur 401 ou une erreur d'autorisation similaire lors de l'exécution de ces commandes, assurez-vous de disposer des autorisations appropriées, puis exécutez à nouveau l'étape qui a renvoyé l'erreur.

Erreur 400: le pool de nœuds nécessite la recréation

Une erreur 400 de type "le pool de nœuds nécessite la recréation" ressemble à ce qui suit :

  ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.

Cette erreur se produit lorsque vous essayez d'effectuer une action qui recrée votre plan de contrôle et vos nœuds. Par exemple, cette erreur peut se produire lorsque vous terminez une rotation des identifiants en cours.

Sur le backend, les pools de nœuds sont marqués pour recréation, mais l'opération de recréation réelle peut prendre un certain temps. L'opération échoue, car GKE n'a pas encore recréé un ou plusieurs pools de nœuds dans votre cluster.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

  • Attendez que la recréation ait lieu. Cette opération peut prendre plusieurs heures, jours ou semaines, en fonction de facteurs tels que les intervalles de maintenance et les exclusions existants.

  • Démarrez manuellement une recréation des pools de nœuds concernés en démarrant une mise à niveau de version vers la même version que le plan de contrôle.

    Pour lancer une recréation, exécutez la commande suivante:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME

    Une fois la mise à niveau terminée, relancez l'opération.

Erreur 403: autorisations insuffisantes

Une erreur 403 de type "autorisations insuffisantes" ressemble à ce qui suit :

  ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Required "container.clusters.get" permission(s) for "projects/<your-project>/locations/<region>/clusters/<your-cluster>".

Cette erreur se produit lorsque vous essayez de vous connecter à un cluster GKE à l'aide de gcloud container clusters get-credentials, mais que le compte n'est pas autorisé à accéder au serveur d'API Kubernetes.

Pour résoudre ce problème, procédez comme suit :

  1. Identifiez le compte présentant le problème d'accès:

    gcloud auth list

  2. Accordez l'accès requis au compte en suivant les instructions de la section S'authentifier auprès du serveur d'API Kubernetes.

Erreur 403 : budget de nouvelle tentative épuisé

L'erreur suivante se produit lorsque vous essayez de créer un cluster GKE :

Error: googleapi: Error 403: Retry budget exhausted: Google Compute Engine:
Required permission 'PERMISSION_NAME' for 'RESOURCE_NAME'.

Dans ce message d'erreur, les variables suivantes s'appliquent :

  • PERMISSION_NAME : nom d'une autorisation, comme compute.regions.get.
  • RESOURCE_NAME : chemin d'accès à la ressource Google Cloud à laquelle vous tentiez d'accéder, comme une région Compute Engine.

Cette erreur se produit si le compte de service IAM associé au cluster ne dispose pas des autorisations minimales requises pour créer le cluster.

Pour résoudre ce problème, procédez comme suit :

  1. Créez ou modifiez un compte de service IAM pour disposer de toutes les autorisations requises pour exécuter un cluster GKE. Pour obtenir des instructions, consultez la section Utiliser le principe du moindre privilège pour les comptes de service IAM.
  2. Spécifiez le compte de service IAM mis à jour dans la commande de création de votre cluster à l'aide de l'option --service-account. Pour obtenir des instructions, consultez la section Créer un cluster Autopilot.

Vous pouvez également omettre l'option --service-account pour permettre à GKE d'utiliser le compte de service Compute Engine par défaut dans le projet, qui dispose des autorisations requises par défaut.

Erreur 404 : ressource introuvable lors de l'appel des commandes gcloud container

Si vous obtenez l'erreur 403 de type "Ressource introuvable" lorsque vous appelez des commandes gcloud container, résolvez le problème en vous authentifiant à nouveau auprès de Google Cloud CLI :

  gcloud auth login

Erreur 400/403 : le compte n'est pas autorisé à apporter des modifications

L'erreur 400 ou 403 de type "Le compte n'est pas autorisé à apporter des modifications" indique que l'un des éléments suivants a été supprimé ou modifié manuellement :

Lorsque vous activez l'API Compute Engine ou Kubernetes Engine, Google Cloud crée les comptes de service et les agents suivants:

  • Compte de service Compute Engine par défaut : dispose de droits de modification sur votre projet.
  • Agent de service des API Google avec des autorisations de modification sur votre projet.
  • Compte de service Google Kubernetes Engine avec le rôle Agent de service Kubernetes Engine sur votre projet.

La création du cluster et toutes les fonctionnalités de gestion échouent si, à un moment donné, quelqu'un modifie ces autorisations, supprime les liaisons de rôles sur le projet, supprime entièrement le compte de service ou désactive l'API.

Pour vérifier si le compte de service Google Kubernetes Engine dispose du rôle Agent de service Kubernetes Engine sur le projet, procédez comme suit :

  1. Utilisez le modèle suivant pour calculer le nom de votre compte de service Google Kubernetes Engine :

    service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

    Remplacez PROJECT_NUMBER par votre numéro de projet.

  2. Vérifiez que le rôle Agent de service Kubernetes Engine n'est pas encore attribué à votre compte de service Google Kubernetes Engine sur le projet. Dans cette commande, remplacez PROJECT_ID par l'ID de votre projet :

    gcloud projects get-iam-policy PROJECT_ID

Pour résoudre ce problème :

  • Si quelqu'un a supprimé le rôle Agent de service Kubernetes Engine de votre compte de service Google Kubernetes Engine, ajoutez-le à nouveau.

  • Sinon, suivez les instructions ci-dessous pour réactiver l'API Kubernetes Engine, qui restaurera correctement vos comptes de service et vos autorisations.

Console

  1. Accédez à la page API et services de la console Google Cloud.

    Accéder aux API et services

  2. Sélectionnez votre projet.

  3. Cliquez sur Activer les API et les services.

  4. Recherchez Kubernetes, puis sélectionnez l'API dans les résultats de la recherche.

  5. Cliquez sur Activer. Si vous avez déjà activé l'API, vous devez d'abord la désactiver, puis la réactiver. L'activation de l'API et des services associés peut prendre plusieurs minutes.

gcloud

Exécutez la commande suivante dans gcloud CLI :

PROJECT_NUMBER=$(gcloud projects describe "PROJECT_ID"
    --format 'get(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:service-${PROJECT_NUMBER?}@container-engine-robot.iam.gserviceaccount.com" \
    --role roles/container.serviceAgent

Résoudre les problèmes liés à la création de clusters GKE

Erreur CONDITION_NOT_MET: la contrainte constraints/compute.vmExternalIpAccess a été enfreinte

La contrainte de règle d'administration constraints/compute.vmExternalIpAccess est configurée sur Deny All ou pour limiter les adresses IP externes à des instances de VM spécifiques au niveau de l'organisation, du dossier ou du projet dans lequel vous essayez de créer une cluster GKE public.

Lorsque vous créez des clusters GKE publics, des adresses IP externes sont attribuées aux VM Compute Engine sous-jacentes, qui constituent les nœuds de calcul de ce cluster. Si vous configurez la contrainte de règle d'administration constraints/compute.vmExternalIpAccess sur Deny All ou pour limiter les adresses IP externes à des instances de VM spécifiques, la règle empêche les nœuds de calcul GKE d'obtenir des adresses IP externes, ce qui entraîne l'échec de la création du cluster.

Pour trouver les journaux de l'opération de création de cluster, vous pouvez consulter les journaux d'audit des opérations de cluster GKE à l'aide de l'explorateur de journaux avec une requête de recherche semblable à la suivante:

resource.type="gke_cluster"
logName="projects/test-last-gke-sa/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="google.container.v1beta1.ClusterManager.CreateCluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.project_id="PROJECT_ID"

Pour résoudre ce problème, assurez-vous que la règle en vigueur pour la contrainte constraints/compute.vmExternalIpAccess est Allow All sur le projet dans lequel vous essayez de créer un cluster public GKE. Pour plus d'informations sur l'utilisation de cette contrainte, consultez la page Limiter les adresses IP externes à des instances de VM spécifiques. Après avoir défini cette contrainte sur Allow All, supprimez le cluster défaillant et créez-en un autre. Cette étape est nécessaire, car il n'est pas possible de réparer le cluster défaillant.

Résoudre les problèmes liés aux charges de travail déployées

GKE renvoie une erreur en cas de problème avec les pods d'une charge de travail. Vous pouvez vérifier l'état d'un pod à l'aide de l'outil de ligne de commande kubectl ou de la console Google Cloud.

kubectl

Pour afficher tous les pods exécutés dans votre cluster, utilisez la commande suivante :

kubectl get pods

Résultat :

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

Pour obtenir plus d'informations sur un pod spécifique, exécutez la commande suivante :

kubectl describe pod POD_NAME

Remplacez POD_NAME par le nom du pod souhaité.

Console

Procédez comme suit :

  1. Accédez à la page Charges de travail dans la console Google Cloud.

    Accéder à la page Charges de travail

  2. Sélectionnez la charge de travail souhaitée. L'onglet Aperçu affiche l'état de la charge de travail.

  3. Dans la section Pods gérés, cliquez sur le message d'état d'erreur.

Les sections suivantes expliquent certaines erreurs courantes renvoyées par les charges de travail et indiquent comment les corriger.

Erreur : CrashLoopBackOff

CrashLoopBackOff indique qu'un conteneur plante de manière répétée après le redémarrage. Un conteneur peut planter pour plusieurs raisons. La consultation des journaux d'un pod peut aider à en identifier la cause.

Par défaut, les conteneurs qui ont planté redémarrent avec un délai exponentiel limité à cinq minutes. Vous pouvez modifier ce comportement en définissant la spécification de pod du déploiement de champ restartPolicy sous spec: restartPolicy. La valeur par défaut du champ est Always.

Vous pouvez résoudre les erreurs CrashLoopBackOff à l'aide de la console Google Cloud:

  1. Accédez au playbook interactif sur le plantage en boucle des pods :

    Accéder au playbook

  2. Pour Cluster, saisissez le nom du cluster que vous souhaitez dépanner.

  3. Pour l'espace de noms , saisissez l'espace de noms que vous souhaitez dépanner.

  4. (Facultatif) Créez une alerte pour être informé des futures erreurs de CrashLoopBackOff:

    1. Dans la section Conseils d'atténuation futurs, sélectionnez Créer une alerte.

Journaux d'inspection

Vous pouvez déterminer la raison pour laquelle le conteneur de votre pod plante en utilisant l'outil de ligne de commande kubectl ou la console Google Cloud.

kubectl

Pour afficher tous les pods exécutés dans votre cluster, utilisez la commande suivante :

kubectl get pods

Recherchez le pod avec l'erreur CrashLoopBackOff.

Pour obtenir les journaux du pod, exécutez la commande suivante :

kubectl logs POD_NAME

Remplacez POD_NAME par le nom du pod qui pose problème.

Vous pouvez également transmettre l'option -p pour obtenir les journaux de l'instance précédente du conteneur d'un pod, si elle existe.

Console

Procédez comme suit :

  1. Accédez à la page Charges de travail dans la console Google Cloud.

    Accéder à la page Charges de travail

  2. Sélectionnez la charge de travail souhaitée. L'onglet Aperçu affiche l'état de la charge de travail.

  3. Dans la section Pods gérés, cliquez sur le pod qui pose problème.

  4. Dans le menu du pod, cliquez sur l'onglet Journaux.

Vérifier le code de sortie du conteneur qui plante

Vous pouvez trouver le code de sortie en effectuant les tâches suivantes :

  1. Exécutez la commande suivante :

    kubectl describe pod POD_NAME

    Remplacez POD_NAME par le nom du pod.

  2. Vérifiez la valeur du champ containers: CONTAINER_NAME: last state: exit code :

    • Si le code de sortie est 1, le conteneur a planté car l'application a planté.
    • Si le code de sortie est 0, vérifiez la durée d'exécution de l'application.

    Les conteneurs se ferment à la fin du processus principal de l'application. Si l'exécution de l'application se termine très rapidement, il arrive que le conteneur continue à redémarrer.

Se connecter à un conteneur en cours d'exécution

Ouvrez une interface système sur le pod :

kubectl exec -it POD_NAME -- /bin/bash

Si le pod comporte plusieurs conteneurs, ajoutez -c CONTAINER_NAME.

Vous pouvez maintenant exécuter les commandes bash à partir du conteneur : vous pouvez tester le réseau, ou vérifier si vous avez accès aux fichiers ou aux bases de données qu'utilise votre application.

Erreurs ImagePullBackOff et ErrImagePull

ImagePullBackOff et ErrImagePull indiquent que l'image utilisée par un conteneur ne peut pas être chargée à partir du registre d'images.

Vous pouvez examiner ce problème à l'aide de la console Google Cloud ou de l'outil de ligne de commande kubectl.

kubectl

Pour obtenir plus d'informations sur l'image de conteneur d'un pod, exécutez la commande suivante :

kubectl describe pod POD_NAME

Console

Procédez comme suit :

  1. Accédez à la page Charges de travail dans la console Google Cloud.

    Accéder à la page Charges de travail

  2. Sélectionnez la charge de travail souhaitée. L'onglet Aperçu affiche l'état de la charge de travail.

  3. Dans la section Pods gérés, cliquez sur le pod qui pose problème.

  4. Dans le menu du pod, cliquez sur l'onglet Événements.

Problème : si l'image est introuvable

Si votre image est introuvable :

  1. Vérifiez que le nom de l'image est correct.
  2. Vérifiez que le tag de l'image est correct. (Essayez :latestou aucun tag pour extraire la dernière image).
  3. Si le chemin d'accès au registre de l'image est complet, vérifiez qu'il existe dans le registre Docker que vous utilisez. Si vous ne fournissez que le nom de l'image, vérifiez le registre Docker Hub.

  4. Essayez d'extraire l'image Docker manuellement :

    • Connectez-vous en SSH sur le nœud :

      Par exemple, pour vous connecter en SSH à une VM:

      gcloud compute ssh VM_NAME --zone=ZONE_NAME

      Remplacez les éléments suivants :

    • Exécutez docker-credential-gcr configure-docker. Cette commande génère un fichier de configuration dans /home/[USER]/.docker/config.json. Assurez-vous que ce fichier inclut le registre de l'image dans le champ credHelpers. Par exemple, le fichier suivant inclut des informations d'authentification pour les images hébergées dans les régions asia.gcr.io, eu.gcr.io, gcr.io, marketplace.gcr.io et us.gcr.io:

      {
  "auths": {},
  "credHelpers": {
    "asia.gcr.io": "gcr",
    "eu.gcr.io": "gcr",
    "gcr.io": "gcr",
    "marketplace.gcr.io": "gcr",
    "us.gcr.io": "gcr"
  }
}

    • Exécutez docker pull IMAGE_NAME.

    Si cette option fonctionne, vous devrez probablement spécifier ImagePullSecrets sur un pod. Les pods ne peuvent référencer que des codes secrets d'extraction d'image dans leur propre espace de noms. Ce processus doit donc être effectué une fois par espace de noms.

Erreur : Autorisation refusée

Si vous rencontrez une erreur "Autorisation refusée" ou "Aucun accès en extraction", vérifiez que vous êtes connecté et/ou que vous avez accès à l'image. Essayez l'une des méthodes suivantes en fonction du registre dans lequel vous hébergez vos images.

Artifact Registry

Si votre image se trouve dans Artifact Registry, le compte de service de votre pool de nœuds doit disposer d'un accès en lecture au dépôt contenant l'image.

Attribuez le rôle artifactregistry.reader au compte de service :

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --location=REPOSITORY_LOCATION \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role="roles/artifactregistry.reader"

Remplacez les éléments suivants :

  • REPOSITORY_NAME : nom de votre dépôt Artifact Registry
  • REPOSITORY_LOCATION : région de votre dépôt Artifact Registry
  • SERVICE_ACCOUNT_EMAIL : adresse e-mail du compte de service IAM associé à votre pool de nœuds.

Container Registry

Si votre image se trouve dans Container Registry, le compte de service de votre pool de nœuds doit disposer d'un accès en lecture au bucket Cloud Storage contenant l'image.

Attribuez le rôle roles/storage.objectViewer au compte de service afin qu'il puisse lire le contenu du bucket:

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role=roles/storage.objectViewer

Remplacez les éléments suivants :

  • SERVICE_ACCOUNT_EMAIL : adresse e-mail du compte de service associé à votre pool de nœuds. Vous pouvez répertorier tous les comptes de service de votre projet à l'aide de gcloud iam service-accounts list.
  • BUCKET_NAME: nom du bucket Cloud Storage contenant vos images. Vous pouvez répertorier tous les buckets de votre projet à l'aide de la commande gcloud storage ls.

Si votre administrateur de registre a configuré des dépôts gcr.io dans Artifact Registry pour stocker des images pour le domaine gcr.io au lieu de Container Registry, vous devez accorder un accès en lecture à Artifact Registry plutôt que Container Registry.

Registre privé

Si votre image se trouve dans un registre privé, vous devrez peut-être disposer de clés pour y accéder. Pour plus d'informations, consultez la page Utiliser des registres privés.

Erreur 401 Opération non autorisée : impossible d'extraire des images du dépôt de registre de conteneurs privé

Une erreur semblable à la suivante peut se produire lorsque vous extrayez une image d'un dépôt Container Registry privé:

gcr.io/PROJECT_ID/IMAGE:TAG: rpc error: code = Unknown desc = failed to pull and
unpack image gcr.io/PROJECT_ID/IMAGE:TAG: failed to resolve reference
gcr.io/PROJECT_ID/IMAGE]:TAG: unexpected status code [manifests 1.0]: 401 Unauthorized

Warning  Failed     3m39s (x4 over 5m12s)  kubelet            Error: ErrImagePull
Warning  Failed     3m9s (x6 over 5m12s)   kubelet            Error: ImagePullBackOff
Normal   BackOff    2s (x18 over 5m12s)    kubelet            Back-off pulling image

  1. Identifiez le nœud exécutant le pod:

    kubectl describe pod POD_NAME | grep "Node:"

  2. Vérifiez que le nœud dispose du champ d'application de stockage:

    gcloud compute instances describe NODE_NAME \
    --zone=COMPUTE_ZONE --format="flattened(serviceAccounts[].scopes)"

    Le niveau d'accès du nœud doit contenir au moins l'un des éléments suivants:

    serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

  3. Recréez le pool de nœuds auquel le nœud appartient avec un champ d'application suffisant. Vous ne pouvez pas modifier les nœuds existants. Vous devez les recréer avec le champ d'application approprié.

    • Recommandé: Créez un pool de nœuds avec le champ d'application gke-default:

      gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --scopes="gke-default"

    • Créez un pool de nœuds avec uniquement un champ d'application de stockage:

      gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --scopes="https://www.googleapis.com/auth/devstorage.read_only"

Erreur : Pod non programmable

PodUnschedulable indique que votre pod ne peut pas être planifié en raison de ressources insuffisantes ou d'une erreur de configuration.

Si vous avez configuré votre cluster GKE pour envoyer des métriques de serveur d'API Kubernetes et de programmeur Kubernetes à Cloud Monitoring, vous trouverez plus d'informations sur ces erreurs dans les sections métriques du programmeur et métriques du serveur d'API.

Vous pouvez résoudre les erreurs PodUnschedulable à l'aide de la console Google Cloud:

  1. Accédez au playbook interactif des pods non programmables:

    Accéder au playbook

  2. Pour Cluster, saisissez le nom du cluster que vous souhaitez dépanner.

  3. Pour l'espace de noms , saisissez l'espace de noms que vous souhaitez dépanner.

  4. (Facultatif) Créez une alerte pour être informé des futures erreurs de PodUnschedulable:

    1. Dans la section Conseils d'atténuation futurs, sélectionnez Créer une alerte.

Erreur : Ressources insuffisantes

Vous pouvez rencontrer une erreur indiquant un manque de ressources processeur, de mémoire ou autre. Par exemple : "Aucun nœud disponible ne correspond à tous les prédicats : processeur insuffisant (2)" indique que sur deux nœuds, le processeur disponible est insuffisant pour répondre aux requêtes d'un pod.

Si les demandes de ressources de pod dépassent celles d'un seul nœud d'un pool de nœuds éligibles, GKE ne programme pas le pod et ne déclenche pas non plus le scaling à la hausse pour ajouter un nœud. Pour que GKE planifie le pod, vous devez soit demander moins de ressources pour le pod, soit créer un pool de nœuds disposant de suffisamment de ressources.

Vous pouvez également activer le provisionnement automatique des nœuds afin que GKE puisse créer automatiquement des pools de nœuds avec des nœuds sur lesquels les pods non planifiés peuvent s'exécuter.

Le nombre de requêtes par défaut sur le processeur est de 100 millions ou 10 % d'un processeur (ou un cœur). Si vous souhaitez demander plus ou moins de ressources, indiquez la valeur dans la spécification de pod sous spec: containers: resources: requests.

Erreur : MatchNodeSelector

MatchNodeSelector indique qu’aucun nœud ne correspond au sélecteur de libellés du pod.

Pour vous en assurer, vérifiez les libellés indiqués dans le champ nodeSelector de la spécification de pod, sous spec: nodeSelector.

Pour savoir comment les nœuds de votre cluster sont libellés, exécutez la commande suivante :

kubectl get nodes --show-labels

Pour associer un libellé à un nœud, exécutez la commande suivante :

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

Remplacez les éléments suivants :

  • NODE_NAME : nœud souhaité.
  • LABEL_KEY : clé de libellé.
  • LABEL_VALUE : valeur du libellé.

Pour plus d'informations, reportez-vous à l'article Affecter des pods à des nœuds.

Erreur : PodToleratesNodeTaints

PodToleratesNodeTaints indique que le pod ne peut pas être programmé sur un nœud, car aucun nœud ne tolère actuellement sa propriété de rejet.

Pour vous en assurer, exécutez la commande suivante :

kubectl describe nodes NODE_NAME

Dans le résultat, examinez le champ Taints, qui répertorie les paires valeur/clé et les effets de planification.

Si l'effet indiqué est NoSchedule, alors aucun pod ne peut être planifié sur ce nœud sans la tolérance correspondante.

Pour résoudre ce problème, vous pouvez supprimer la propriété de rejet. Par exemple, pour supprimer le rejet NoSchedule, exécutez la commande suivante :

kubectl taint nodes NODE_NAME key:NoSchedule-

Erreur : PodFitsHostPorts

PodFitsHostPorts indique qu'un port qu'un nœud tente d'utiliser est déjà en cours d'utilisation.

Pour résoudre ce problème, vérifiez la valeur hostPort de la spécification de pod sous spec: containers: ports: hostPort. Vous devrez peut-être remplacer cette valeur par un autre port.

Erreur : Disponibilité minimale non présente

Si un nœud dispose de ressources suffisantes mais que vous obtenez toujours le message Does not have minimum availability, vérifiez l'état du pod. Si l'état est SchedulingDisabled ou Cordoned, le nœud ne peut pas planifier de nouveaux pods. Vous pouvez vérifier l'état d'un nœud à l'aide de la console Google Cloud ou de l'outil de ligne de commande kubectl.

kubectl

Pour obtenir l'état de vos nœuds, exécutez la commande suivante :

kubectl get nodes

Pour activer la planification sur le nœud, exécutez cette commande :

kubectl uncordon NODE_NAME

Console

Procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Sélectionnez le cluster souhaité. L'onglet Nœuds affiche les nœuds et leur état.

Pour activer la planification sur le nœud, procédez comme suit :

  1. Dans la liste, cliquez sur le nœud souhaité.

  2. Dans les détails du nœud, cliquez sur le bouton Reprendre l'ordonnancement.

Erreur : Nombre maximal de pods par nœud atteint

Si la limite Nombre maximal de pods par nœud est atteinte par tous les nœuds du cluster, les pods sont bloqués dans l'état non programmable. Sous l'onglet Événements du pod, un message contenant l'expression Too many pods s'affiche.

  1. Vérifiez la configuration Maximum pods per node à partir de l'onglet "Nœuds" dans les détails du cluster GKE dans la console Google Cloud.

  2. Obtenez la liste des nœuds:

    kubectl get nodes

  3. Pour chaque nœud, vérifiez le nombre de pods en cours d'exécution sur le nœud:

    kubectl get pods -o wide | grep NODE_NAME | wc -l

  4. Si la limite est atteinte, ajoutez un pool de nœuds ou ajoutez des nœuds supplémentaires au pool de nœuds existant.

Problème : Taille maximale du pool de nœuds atteinte avec l'autoscaler de cluster activé

Si le pool de nœuds a atteint sa Taille maximale Selon sa configuration d'autoscaler de cluster, GKE ne déclenche pas de scaling à la hausse pour le pod qui serait autrement programmé avec ce pool de nœuds. Si vous souhaitez que le pod soit planifié sur ce pool de nœuds, modifiez la configuration de l'autoscaler de cluster.

Problème : Taille maximale du pool de nœuds atteinte avec l'autoscaler de cluster désactivé

Si le pool de nœuds a atteint son nombre maximal de nœuds et que l'autoscaler de cluster est désactivé, GKE ne peut pas planifier le pod avec le pool de nœuds. Augmentez la taille de votre pool de nœuds ou activez l'autoscaler de cluster pour que GKE redimensionne automatiquement votre cluster.

Erreur : PersistentVolumeClaims non liés

Unbound PersistentVolumeClaims indique que le pod fait référence à un objet PersistantVolumeClaim non lié. Cette erreur peut se produire en cas d'échec du provisionnement du PersistentVolume. Vous pouvez vérifier si le provisionnement a échoué en récupérant les événements associés au PersistentVolumeClaim et en examinant s'ils signalent un échec.

Pour obtenir la liste des événements, exécutez la commande suivante :

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

Remplacez les éléments suivants :

  • STATEFULSET_NAME : nom de l'objet StatefulSet.
  • PVC_NAME : nom de l'objet PersistentVolumeClaim.

Cette erreur peut également être causée par une erreur de configuration lors du provisionnement manuel préalable d'un PersistentVolume et de sa liaison à un PersistentVolumeClaim. Dans ce cas, vous pouvez essayer de préprovisionner le volume à nouveau.

Erreur : quota insuffisant

Vérifiez que votre projet dispose d'un quota Compute Engine suffisant pour que GKE puisse effectuer le scaling à la hausse de votre cluster. Si GKE tente d'ajouter un nœud à votre cluster pour planifier le pod et que le scaling à la hausse dépasse le quota disponible de votre projet, vous recevez le message d'erreur scale.up.error.quota.exceeded.

Pour en savoir plus, consultez la section Erreurs liées au scaling à la hausse.

Problème : API obsolètes

Assurez-vous de ne pas utiliser d'API obsolètes qui sont supprimées dans la version mineure de votre cluster. Pour en savoir plus, consultez la page Abandons de GKE.

Erreur: "Échec de l'allocation pour la plage 0: aucune adresse IP dans la plage définie"

Les versions 1.18.17 et ultérieures de GKE ont résolu un problème où des événements de mémoire saturée (OOM, Out Of Memory) entraînent une éviction de pod incorrecte si le pod était supprimé avant le démarrage de ses conteneurs. Cette éviction incorrecte peut entraîner des pods orphelins qui ont continué à posséder des adresses IP réservées de la plage de nœuds allouée. Au fil du temps, GKE a épuisé ses adresses IP pour allouer de nouveaux pods en raison de l'accumulation de pods orphelins. Cela a généré le message d'erreur failed to allocate for range 0: no IP addresses in range set, car la plage de nœuds allouée n'avait pas d'adresses IP disponibles à attribuer à de nouveaux pods.

Pour résoudre ce problème, mettez à niveau le cluster et les pools de nœuds vers GKE 1.18.17 ou une version ultérieure.

Pour éviter ce problème et le résoudre sur les clusters avec des versions de GKE antérieures à 1.18.17, augmentez vos limites de ressources pour éviter les événements OOM à l'avenir, puis récupérez les adresses IP en supprimant les pods orphelins.

Vous pouvez également consulter les insights sur l'utilisation des adresses IP GKE.

Supprimer les pods orphelins des nœuds concernés

Vous pouvez supprimer les pods orphelins en drainant le nœud, en mettant à niveau le pool de nœuds ou en déplaçant les répertoires concernés.

Drainer le nœud (recommandé)

  1. Marquez le nœud comme non programmable pour empêcher que de nouveaux pods se programment sur celui-ci :

     kubectl cordon NODE

    Remplacez NODE par le nom du nœud que vous souhaitez drainer.

  2. Drainez le nœud. GKE reprogramme automatiquement les pods gérés par les déploiements sur d'autres nœuds. Utilisez l'option --force pour drainer les pods orphelins qui ne disposent pas d'une ressource de gestion.

     kubectl drain NODE --force

  3. Marquez le nœud comme non programmable pour permettre à GKE de programmer de nouveaux pods sur celui-ci :

     kubectl uncordon NODE

Déplacer des répertoires concernés

Vous pouvez identifier les répertoires de pods orphelins dans /var/lib/kubelet/pods et les déplacer hors du répertoire principal pour permettre à GKE d'arrêter les pods.

Résoudre les problèmes liés à l'arrêt des ressources

Problème : espace de noms bloqué à l'état Terminating





## Debug GKE Cluster Austoscaler issues with gcpdiag

















  
  

gcpdiag
is an open source tool. It is not an officially supported Google Cloud product.
You can use the gcpdiag tool to help you identify and fix Google Cloud
project issues. For more information, see the
gcpdiag project on GitHub.




  
This gcpdiag runbook investigates potential causes for GKE
Cluster Autoscaler failures while performing scale up or scale down operations.
It looks for the following error message in logs:
<ul>
  <li><strong>scale.up.error.out.of.resources</strong></li>
  <li><strong>scale.up.error.quota.exceeded</strong></li>
  <li><strong>scale.up.error.waiting.for.instances.timeout</strong></li>
  <li><strong>scale.up.error.ip.space.exhausted</strong></li>
  <li><strong>scale.up.error.service.account.deleted</strong></li>
  <li><strong>scale.down.error.failed.to.evict.pods</strong></li>
  <li><strong>no.scale.down.node.node.group.min.size.reached</strong></li>
</ul>







    


  
Google Cloud console

  
    
    
  1. Complete and then copy the following command. 
    2. 
       
    gcpdiag runbook gke/cluster-autoscaler --project=<var>PROJECT_ID</var> \\
    --parameter name=<var>CLUSTER_NAME</var> \\
    --parameter location=<var>LOCATION</var>
    
    
  2. Ouvrez la console Google Cloud et activez Cloud Shell.
    3. 
    

Ouvrir la console Cloud

    
  3. Collez la commande copiée.
    4. 
    
  4. Exécutez la commande gcpdiag, qui télécharge l'image Docker gcpdiag, puis effectue des vérifications de diagnostic. Le cas échéant, suivez les instructions de sortie pour corriger les échecs de vérification.
    
    5. 
  


  

    
  
    Docker
    
  
    Vous pouvez exécuter gcpdiag à l'aide d'un wrapper qui démarre gcpdiag dans un conteneur Docker. Docker ou Podman doivent être installés.
    
  
      
    
    1. Copiez et exécutez la commande suivante sur votre station de travail locale : 
      curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
      
      
      2. 
      
    2.  Exécutez la commande gcpdiag.
        
      ./gcpdiag runbook gke/cluster-autoscaler --project=<var>PROJECT_ID</var> \\
    --parameter name=<var>CLUSTER_NAME</var> \\
    --parameter location=<var>LOCATION</var>
      
      
      3. 

   
 
    

    



    


    Affichez les paramètres disponibles pour ce runbook.
    


    Remplacez les éléments suivants :
    

      
  
    • PROJECT_ID : ID du projet contenant la ressource.
      • 
  
  
  <li><var>CLUSTER_NAME</var> : nom du cluster GKE cible dans votre projet.</li>
<li><var>LOCATION</var> : emplacement du cluster GKE cible (zone pour le cluster zonal ou région pour le cluster régional).</li>



    

    Options utiles :
    



    Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.
    


    




## Résoudre les problèmes liés aux métriques de votre cluster qui n'apparaissent pas dans Cloud Monitoring {:#no_metrics}

Vérifiez que vous avez [activé l'API Monitoring](/monitoring/api/enable-api) et l'[API Logging](/logging/docs/api/enable-api) sur votre projet. Vous devez également vérifier que vous pouvez afficher votre projet dans la [Présentation de Cloud Monitoring](https://console.cloud.google.com/monitoring) de la console Google Cloud.

Si le problème persiste, penchez-vous sur les causes potentielles suivantes :

1.  Assurez-vous que vous avez activé la surveillance sur votre cluster.

    La surveillance est activée par défaut pour les clusters créés à partir de la console Google Cloud et de Google Cloud CLI, mais vous pouvez vérifier que c'est bien le cas en exécutant la commande suivante ou en cliquant sur les détails du cluster dans la [console Google Cloud](https://console.cloud.google.com/) : 

    ```sh
    gcloud container clusters describe CLUSTER_NAME
    ```

    Le résultat de cette commande doit inclure "SYSTEM_COMPONENTS" dans la liste "enableComponents" de la section "monitoringConfig", comme suit :

    ```
    monitoringConfig:
      componentConfig:
        enableComponents:
        - SYSTEM_COMPONENTS
    ```

    Si la surveillance n'est pas activée, exécutez la commande suivante pour l'activer :

    ```sh
    gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
    ```

1.  Depuis combien de temps votre cluster a-t-il été créé ou sa surveillance activée ?

    L'apparition des métriques d'un nouveau cluster dans Cloud Monitoring peut prendre jusqu'à une heure.

1.  Est-ce qu'un pod `heapster` ou `gke-metrics-agent` (Collecteur OpenTelemetry) s'exécute dans votre cluster dans l'espace de noms "kube-system" ?

    Ce pod ne parvient peut-être pas à planifier les charges de travail parce que votre cluster manque de ressources. Vérifiez si Heapster ou OpenTelemetry est en cours d'exécution en appelant la commande `kubectl get pods --namespace=kube-system` et en recherchant les pods dont le nom contient `heapster` ou `gke-metrics-agent`.

1.  Le plan de contrôle de votre cluster est-il capable de communiquer avec les nœuds ?

    Cloud Monitoring s'appuie sur cette capacité. Vous pouvez vérifier si c'est le cas en exécutant la commande suivante :

    ```sh
    kubectl logs POD_NAME
    ```

    Si cette commande renvoie une erreur, le problème peut être causé par les tunnels SSH. Pour en savoir plus, consultez [cette section](/kubernetes-engine/docs/troubleshooting#kubect_commands_stops).

Si vous rencontrez un problème lié à l'agent Cloud Logging, consultez [sa documentation de dépannage].

Pour en savoir plus, consultez la [documentation sur Logging](/logging/docs/).




## Problème : l'autorité de certification racine du cluster arrive bientôt à expiration {:#ca_expiring}

L'autorité de certification racine de votre cluster arrive bientôt à expiration. Pour éviter toute interruption des opérations normales sur les clusters, vous devez effectuer une [rotation des identifiants](/kubernetes-engine/docs/how-to/credential-rotation).

## Erreur : &quot;Instance 'Foo' ne contient pas de métadonnées 'instance-template'&quot; {:#instance-template-missing}

Il est possible que l'erreur "Instance 'Foo' ne contient pas de métadonnées 'instance-template'" s'affiche en tant qu'état d'un pool de nœuds qui ne parvient pas à mettre à se mettre à niveau, à s'ajuster ou à effectuer une réparation automatique de nœuds.

Ce message indique que les métadonnées des instances de VM, allouées par GKE, ont été corrompues. Cela se produit généralement lorsque des opérations de création d'automatisation ou de scripts personnalisés tentent d'ajouter des métadonnées d'instance (telles que [`block-project-ssh-keys`](/compute/docs/connect/restrict-ssh-keys#block-keys)), et qu'au lieu d'ajouter ou de mettre à jour des valeurs, elles suppriment également les métadonnées existantes.
Pour en savoir plus sur les métadonnées d'instance de VM, consultez la section [Définir des métadonnées personnalisées](/compute/docs/storing-retrieving-metadata#custom).

Dans le cas où une des valeurs de métadonnées critiques (entre autres : `instance-template`, `kube-labels`, `kubelet-config`, `kubeconfig`, `cluster-name`, `configure-sh`, `cluster-uid`) a été supprimée, le nœud ou le pool de nœuds entier peut s'afficher dans un état instable, car ces valeurs sont essentielles aux opérations GKE.



Si les métadonnées d'instance ont été corrompues, le meilleur moyen de récupérer les métadonnées consiste à recréer le pool de nœuds contenant les instances de VM corrompues. Vous devez [ajouter un pool de nœuds](/kubernetes-engine/docs/how-to/node-pools#add) à votre cluster et augmenter le nombre de nœuds sur le nouveau pool de nœuds, tout en marquant les nœuds comme non programmables et en supprimant les nœuds sur l'autre pool. Consultez les instructions pour [migrer des charges de travail entre des pools de nœuds](/kubernetes-engine/docs/troubleshooting/troubleshoot-node-pools#migrate-node-pools).



Pour déterminer par qui et quand les métadonnées d'instance ont été modifiées, vous pouvez consulter les [informations sur les journaux d'audit Compute Engine](/compute/docs/logging/audit-logging) ou rechercher des journaux à l'aide de l'[Explorateur de journaux](/logging/docs/view/logs-explorer-interface) avec une requête de recherche semblable à celle-ci :

```none
resource.type="gce_instance_group_manager"
protoPayload.methodName="v1.compute.instanceGroupManagers.setInstanceTemplate"
```

Dans les journaux, vous pouvez trouver l'adresse IP et le user-agent à l'origine de la requête :

``` json
requestMetadata: {
  callerIp: "REDACTED"
  callerSuppliedUserAgent: "google-api-go-client/0.5 GoogleContainerEngine/v1"
}
```





Pour en savoir plus sur les secrets dans GKE, consultez la section [Chiffrer les secrets au niveau de la couche application](/kubernetes-engine/docs/how-to/encrypting-secrets).

## Problème : échec de la mise à jour du chiffrement des secrets {:#secrets_encryption_update_failed}

Si l'opération d'activation, de désactivation ou de mise à jour de la [clé Cloud KMS](/kubernetes-engine/docs/how-to/encrypting-secrets) échoue, consultez le guide [Résoudre les problèmes de chiffrement des secrets au niveau de la couche application](/kubernetes-engine/docs/troubleshooting/troubleshoot-secrets).