Résoudre les problèmes de contention des ressources

Cette page explique comment identifier et résoudre les problèmes de contention des ressources dans votre environnement Google Distributed Cloud.

Présentation

Il peut arriver que Google Distributed Cloud rencontre des problèmes de contention des ressources, ce qui peut ralentir vos conteneurs, réduire leurs performances ou les arrêter. Cela peut être dû à une consommation élevée de processeur ou de mémoire par les conteneurs.

Fonctionnement de la gestion du processeur et de la mémoire

  • CPU :

    • Un pod est planifié sur un nœud en fonction des requêtes de processeur spécifiées par les conteneurs du pod.
    • Un conteneur d'un pod ne peut pas utiliser plus de processeurs que la limite spécifiée par le conteneur.
    • L'utilisation du processeur du conteneur est limitée à la limite de processeur.
    • Si l'utilisation du processeur est limitée au niveau du nœud, les conteneurs se voient automatiquement attribuer les cycles de processeur proportionnels aux requêtes.

    En savoir plus sur la planification des pods avec des requêtes de ressources.

  • Mémoire :

    • Un pod est planifié sur un nœud en fonction des requêtes de mémoire spécifiées par les conteneurs du pod.
    • Un conteneur ne peut pas utiliser plus de mémoire que la limite spécifiée par le conteneur.
    • Si aucune limite de mémoire n'est spécifiée, un conteneur peut consommer toute la mémoire disponible sur un nœud. Le système peut alors déclencher le tueur de mémoire insuffisante et évincer les pods de faible priorité.

Pour en savoir plus, consultez les ressources suivantes :

Problèmes

Le conteneur devient lent

Les problèmes de contention du processeur peuvent ralentir les conteneurs. Voici quelques-unes des raisons possibles :

Utilisation élevée du processeur sur le conteneur :

Un conteneur peut devenir lent s'il n'obtient pas de cycles de processeur proportionnels aux requêtes de processeur, ou si les requêtes de processeur ont été définies sur une valeur inférieure à celle dont le conteneur a besoin. Vérifiez donc le rapport entre la limite de processeur et l'utilisation du processeur pour le conteneur.

Dans la Google Cloud console > Monitoring > Explorateur de métriques, dans l' éditeur PromQL, exécutez la requête suivante :

  avg_over_time({
    "__name__"="kubernetes.io/anthos/container/cpu/limit_utilization",
    "monitored_resource"="k8s_container",
    "cluster_name"="CLUSTER_NAME",
    "container_name"="CONTAINER_NAME",
    "pod_name"="POD_NAME",
    "namespace_name"="NAMESPACE_NAME"
  }[${__interval}])

Effectuez l' une des opérations suivantes :

Utilisation élevée du processeur sur le nœud

Si le rapport entre la limite de processeur et l'utilisation n'est pas élevé pour un conteneur individuel du pod, il est possible que le nœud ne dispose pas de suffisamment de cycles de processeur à allouer à l'ensemble des conteneurs exécutés sur le nœud. Suivez donc ces étapes pour vérifier le rapport entre l'utilisation réelle du processeur et les processeurs pouvant être alloués sur le nœud :

  1. Obtenez le nœud pour le pod qui fonctionne lentement :

    kubectl get pod –kubeconfig CLUSTER_KUBECONFIG --namespace NAMESPACE POD --output wide

  2. Dans la Google Cloud console > Monitoring > Explorateur de métriques, dans l' éditeur PromQL, exécutez la requête suivante :

    avg_over_time({
  "__name__"="kubernetes.io/anthos/node/cpu/allocatable_utilization",
  "monitored_resource"="k8s_node",
  "cluster_name"="CLUSTER_NAME",
  "node_name"="NODE_NAME"
}[${__interval}])

    Si ce ratio est élevé (>= 0,8), cela signifie que le nœud ne dispose pas de suffisamment de cycles de processeur et qu'il fait l'objet d'une sursouscription. Suivez donc ces étapes pour vérifier l'utilisation du processeur pour tous les autres pods de ce nœud et déterminez si un autre conteneur utilise plus de processeurs.

    1. Obtenez tous les pods sur le nœud :
    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
    1. Vérifiez l'utilisation du processeur sur chaque conteneur :
    avg_over_time({
  "__name__"="kubernetes.io/anthos/container/cpu/limit_utilization",
  "monitored_resource"="k8s_container",
  "cluster_name"="CLUSTER_NAME",
  "container_name"="CONTAINER_NAME",
  "pod_name"="POD_NAME",
  "namespace_name"="NAMESPACE_NAME"
}[${__interval}])

    Si un autre conteneur utilise un processeur élevé sur le nœud, augmentez les requêtes et les limites de processeur sur le conteneur qui fonctionne lentement. Cela recréera le pod sur un autre nœud pour obtenir les cycles de processeur requis.

Si c'est un pod système qui fonctionne lentement, contactez l'assistance Google.

Sursouscription du processeur au niveau de vSphere

Si la consommation de processeur n'est pas élevée sur le nœud ou le pod, et que le conteneur est toujours lent, la VM peut faire l'objet d'une sursouscription au niveau de vSphere. Par conséquent, le nœud ne peut pas obtenir les cycles de processeur attendus de la virtualisation sous-jacente.

Suivez ces étapes pour vérifier si la VM fait l'objet d'une sursouscription. Si une sursouscription est détectée, essayez les solutions suivantes :

Le pod est arrêté pour cause de mémoire insuffisante

Les pods peuvent être arrêtés en raison de fuites de mémoire ou d'une mauvaise configuration des requêtes et des limites de mémoire sur les conteneurs. Voici quelques-unes des raisons possibles :

Utilisation élevée de la mémoire sur le conteneur

Un pod peut être arrêté par manque de mémoire si un conteneur du pod consomme la totalité de la mémoire allouée. Vérifiez donc le rapport entre les requêtes de mémoire et les limites de mémoire sur le conteneur.

Dans la Google Cloud console > Monitoring > Explorateur de métriques, dans l' éditeur PromQL, exécutez la requête suivante :

avg_over_time({
  "__name__"="kubernetes.io/anthos/container/memory/limit_utilization",
  "monitored_resource"="k8s_container",
  "memory_type"="non-evictable",
  "cluster_name"="CLUSTER_NAME",
  "container_name"="CONTAINER_NAME",
  "pod_name"="POD_NAME",
  "namespace_name"="NAMESPACE_NAME"
}[${__interval}])

Effectuez l' une des opérations suivantes :

Utilisation élevée de la mémoire sur le nœud

Un pod peut être arrêté par manque de mémoire si l'utilisation de la mémoire de tous les pods exécutés sur le nœud dépasse la mémoire disponible. Vérifiez donc si la condition MemoryPressure sur le nœud est True.

  1. Exécutez la commande suivante et examinez la section Conditions :

    kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME

  2. Si la condition MemoryPressure est True, vérifiez l'utilisation de la mémoire sur le nœud :

    avg_over_time({
  "__name__"="kubernetes.io/anthos/node/memory/allocatable_utilization",
  "monitored_resource"="k8s_node",
  "memory_type"="non-evictable",
  "cluster_name"="CLUSTER_NAME",
  "node_name"="NODE_NAME",
}[${__interval}])

    Si ce ratio est élevé (>= 0,8), cela signifie que le nœud ne dispose pas de suffisamment de mémoire à allouer au pod, probablement en raison de certains processus ou d'autres pods qui consomment beaucoup de mémoire.

  3. Dans la Google Cloud console > Monitoring > Explorateur de métriques, dans l' éditeur PromQL, exécutez la requête suivante pour vérifier l'utilisation de la mémoire pour les conteneurs sur le nœud :

    avg_over_time({
  "__name__"="kubernetes.io/anthos/container_memory_usage_bytes",
  "monitored_resource"="k8s_node",
  "cluster_name"="CLUSTER_NAME",
  "node_name"="NODE_NAME",
}[${__interval}])

    Si un conteneur utilise beaucoup de mémoire, examinez son fonctionnement ou augmentez la requête de mémoire pour le conteneur, si nécessaire.

Si c'est un pod système qui consomme beaucoup de mémoire, contactez l'Assistance Google.

Vous pouvez également activer la fonctionnalité d'autoscaling dans Google Distributed Cloud pour effectuer automatiquement un scaling à la hausse et à la baisse des pools de nœuds en fonction des exigences de vos charges de travail.

Découvrez comment activer l'autoscaler.

Problèmes liés à etcd

Parfois, vos Clusters Anthos sur VMware peuvent rencontrer des échecs de conteneur en raison de problèmes liés au serveur etcd. Vous pouvez alors observer les problèmes suivants :

  • Journaux de serveur d'API répétés au format :

    etcdserver: request timed out et etcdserver: leader changed

  • Journaux etcd répétés au format :

    W | wal: sync duration of 2.466870869s, expected less than 1s et W | etcdserver: read-only range request * took too long

Voici quelques-unes des raisons possibles :

Limitation du CPU

Le serveur etcd peut être lent en raison de la limitation du processeur sur le pod du serveur etcd et/ou le nœud sur lequel le serveur etcd est exécuté. Reportez-vous à la section Le conteneur devient lent pour vérifier tout problème de contention du processeur.

Si vous détectez une contention de processeur sur le pod de serveur ectd ou sur le nœud, ajoutez des processeurs au nœud du plan de contrôle du cluster d'utilisateur. Utilisez gkectl update pour modifier le champ cpus dans le fichier de configuration du cluster d'utilisateur.

Pod etcd arrêté pour cause de mémoire insuffisante

Le pod etcd peut être arrêté en raison de problèmes de conflit de ressources. Reportez-vous à la section Le pod est arrêté pour cause de mémoire insuffisante pour vérifier tout problème de conflit de mémoire avec le pod du serveur etcd et/ou le nœud sur lequel le serveur etcd est exécuté.

Si vous détectez que le pod etcd est arrêté pour cause de mémoire insuffisante, augmentez la mémoire disponible pour le nœud du plan de contrôle du cluster d'utilisateur. Utilisez gkectl update pour modifier le champ memoryMB dans le fichier de configuration du cluster d'utilisateur.

Lenteur du disque

S'il n'y a aucun problème de consommation de processeur ou de mémoire sur le pod du serveur etcd ou le nœud, l'etcd peut être lent si le datastore sous-jacent est lent ou limité.

Recherchez les problèmes suivants :

  • Pour vérifier si le serveur etcd met trop de temps à lire/écrire sur le disque sous-jacent :

    1. Récupérez les journaux etcd :

      kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n ETCD_POD_NAMESPACE ETCD_POD

    2. Recherchez les entrées du modèle suivant pour détecter si etcd met trop de temps à lire à partir du disque :

      W | etcdserver: read-only range request "key:\"/registry/configmaps/default/clusterapi-vsphere-controller-manager-leader-election\" " with result "range_response_count:1 size:685" took too long (6.893127339s) to execute

    3. Recherchez les entrées du modèle suivant pour détecter si etcd met trop de temps à écrire sur le disque :

      W | wal: sync duration of 2.466870869s, expected less than 1s

    Si l'un ou les deux modèles de journal ci-dessus s'affichent fréquemment dans les journaux etcd, cela indique une lenteur du disque. Vérifiez ensuite les performances du datastore et des disques.

  • Pour vérifier les métriques etcd :

    1. Récupérez les latences de synchronisation wal etcd :

      Dans la Google Cloud console > Monitoring > Explorateur de métriques, dans l' éditeur PromQL, exécutez la requête suivante :

      histogram_quantile(0.99,
  sum by ("le") (
    increase({
      "__name__"="kubernetes.io/anthos/etcd_disk_wal_fsync_duration_seconds_bucket",
      "monitored_resource"="k8s_container",
      "cluster_name"="CLUSTER_NAME",
      "pod_name"="POD_NAME",
      "namespace_name"="NAMESPACE_NAME"
    }[${__interval}])
  )
)

    2. Récupérez les latences d'écriture etcd :

      Dans la Google Cloud console > Monitoring > Explorateur de métriques, dans l' éditeur PromQL, exécutez la requête suivante :

      histogram_quantile(0.99,
  sum by ("le") (
    increase({
      "__name__"="kubernetes.io/anthos/etcd_disk_backend_commit_duration_seconds",
      "monitored_resource"="k8s_container",
      "cluster_name"="CLUSTER_NAME",
      "pod_name"="POD_NAME",
      "namespace_name"="NAMESPACE_NAME"
    }[${__interval}])
  )
)

    Si p99 pour etcd_disk_wal_fsync_duration_seconds est constamment supérieur à 10 ms, et/ou si p99 pour etcd_disk_backend_commit_duration_seconds est constamment supérieur à 25 ms, cela indique une lenteur du disque. Vérifiez ensuite les performances du datastore et des disques.

Latences de lecture/écriture sur le disque de la VM

Pour vérifier les latences de lecture/écriture sur le disque virtuel de la VM, procédez comme suit :

  1. Identifiez le nœud pour le pod etcd lent :

    kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods -n ETCD_POD_NAMESPACE ETCD_POD -owide

  2. Connectez-vous à vSphere et sélectionnez la VM identifiée à l'étape précédente : dans vSphere, accédez à Surveiller > Performances > Avancé, puis sélectionnez Disque virtuel dans la section Afficher pour identifier les latences de lecture et d'écriture des disques virtuels.

    Si la latence de lecture/écriture du disque virtuel est élevée :

    • Examinez les autres VM exécutées sur le datastore pour vérifier l'utilisation élevée des opérations d'entrée/de sortie par seconde (IOPS). Si une VM présente des pics dans les IOPS, évaluez le fonctionnement de cette VM.
    • Consultez votre équipe de laboratoire/d'infrastructure pour vous assurer que la bande passante de lecture et d'écriture n'est pas limitée à aucun moment.
    • Consultez votre équipe de laboratoire/d'infrastructure pour identifier les problèmes de performances du disque et de stockage, le cas échéant.

Pour en savoir plus, consultez les bonnes pratiques concernant le scaling de vos ressources.

Problèmes liés au serveur d'API

Si les conteneurs de votre Google Distributed Cloud rencontrent une latence lors de la communication avec le serveur d'API, ou si les commandes Kubectl échouent ou mettent trop de temps à répondre, cela peut indiquer des problèmes avec le serveur d'API.

Voici quelques-unes des raisons possibles :

Volume élevé de requêtes API

Le serveur d'API peut mettre du temps à répondre si la fréquence et le volume des requêtes sont trop élevés. Le temps de réponse lent peut persister même après que le serveur d'API commence à limiter les requêtes. Vérifiez donc le taux de requêtes API sur le serveur d'API.

Dans la Google Cloud console > Monitoring > Explorateur de métriques, dans l' éditeur PromQL, exécutez la requête suivante :

sum by (verb) (
  rate({
    "__name__"="kubernetes.io/anthos/apiserver_request_total",
    "monitored_resource"="k8s_container",
    "cluster_name"="CLUSTER_NAME",
    "pod_name"="APISERVER_POD_NAME",
    "namespace_name"="NAMESPACE_NAME"
   }[${__interval}])
)

En cas d'augmentation inattendue des requêtes API, utilisez la journalisation d'audit Cloud pour identifier le pod qui interroge peut-être trop souvent le serveur d'API.

  • S'il s'agit d'un pod système, contactez l'assistance Google.
  • S'il s'agit d'un pod utilisateur, examinez-le plus en détail pour déterminer si les requêtes API sont attendues.

Limitation du CPU

Un taux de demandes élevé sur le serveur d'API peut entraîner une limitation du processeur. Le serveur d'API peut alors devenir lent en raison de la contention du processeur sur le pod du serveur d'API et/ou le nœud.

Reportez-vous à la section Le conteneur devient lent pour vérifier tout problème de contention du processeur avec le pod et/ou le nœud.

Pod du serveur d'API arrêté pour cause de mémoire insuffisante

Le pod du serveur d'API peut être arrêté en raison de problèmes de conflit de ressources. Reportez-vous à la section Le pod est arrêté pour cause de mémoire insuffisante pour vérifier les problèmes de conflit de mémoire avec le pod et/ou le nœud.

Réponses etcd lentes

Le serveur d'API s'appuie sur la communication avec le cluster etcd pour traiter les requêtes de lecture / écriture des clients. Si l'etcd est lent ou ne répond pas, le serveur d'API devient également lent.

Récupérez les journaux du serveur d'API pour vérifier si le serveur d'API est lent en raison de problèmes liés à etcd :

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Si vous observez les journaux récurrents tels que etcdserver: request timedout ou etcdserver: leader changed, suivez les étapes décrites dans Problèmes liés à etcd pour résoudre les problèmes liés au disque.

Si votre cluster n'exporte pas de métriques

Les techniques présentées précédemment dans ce document reposent sur l'exportation de métriques de votre cluster vers un Google Cloud projet.

Si votre cluster n'exporte pas de métriques, vous pouvez utiliser la ligne de commande pour examiner la contention des ressources. Voici quelques commandes que vous pouvez exécuter sur votre station de travail d'administrateur pour afficher les métriques.

Afficher les métriques d'un nœud :

kubectl --kubeconfig CLUSTER_KUBECONFIG get --raw \
    /apis/metrics.k8s.io/v1beta1/nodes/NODE_NAME | jq

Remplacez les éléments suivants :

  • CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster
  • NODE_NAME : nom du nœud

Afficher les métriques d'un pod :

kubectl --kubeconfig CLUSTER_KUBECONFIG get --raw \
    /apis/metrics.k8s.io/v1beta1/namespaces/NAMESPACE/pods/POD_NAME | jq

Remplacez les éléments suivants :

  • NAMESPACE : espace de noms du pod
  • POD_NAME : nom du pod

Afficher les métriques de tous les nœuds :

kubectl --kubeconfig CLUSTER_KUBECONFIG top node

Afficher les métriques de tous les pods d'un espace de noms :

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --namespace NAMESPACE

Afficher les métriques des conteneurs de tous les pods d'un espace de noms :

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --containers --namespace NAMESPACE

Pour en savoir plus, consultez kubectl top pod et kubectl top node.

Vous pouvez également exécuter la commande top à partir d'un conteneur exécuté sur un nœud.

Voici deux méthodes permettant d'exécuter une commande dans un conteneur :

  • Sur votre station de travail d'administrateur, exécutez kubectl exec pour obtenir une interface système dans le conteneur. Exécutez la commande dans l'interface système.

  • Établissez une connexion SSH à un nœud. Utilisez ensuite docker exec pour obtenir une interface système dans le conteneur. Exécutez la commande dans l'interface système.

Étape suivante

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

Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris en ce qui concerne les thématiques suivantes :