Résoudre les problèmes de conflit de 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 se produire en raison d'une forte consommation 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 demandes de processeur spécifiées par les conteneurs du pod.
    • Un conteneur dans 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 des cycles de processeur proportionnels aux demandes.

    En savoir plus sur la programmation des pods avec des demandes de ressources

  • Mémoire :

    • Un pod est planifié sur un nœud en fonction des demandes 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 demandes de processeur, ou si les demandes de processeur ont été définies sur une valeur trop faible par rapport à ce 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 consoleGoogle Cloud  > Monitoring > Explorateur de métriques, dans l'éditeur MQL, exécutez la requête suivante :

  fetch k8s_container
  | metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
  | group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
  | filter resource.cluster_name == 'CLUSTER_NAME'
  | filter resource.container_name == 'CONTAINER_NAME'
  | filter resource.pod_name == 'POD_NAME'
  | filter resource.namespace_name == 'NAMESPACE_NAME'
  | every 1m

Effectuez l' une des opérations suivantes :

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

Si le ratio entre la limite de processeur et l'utilisation n'est pas élevé pour un conteneur individuel du pod, il se peut 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. Pour vérifier le ratio entre l'utilisation réelle du processeur et les processeurs pouvant être alloués sur le nœud, procédez comme suit :

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

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

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

    fetch k8s_node
| metric 'kubernetes.io/anthos/node/cpu/allocatable_utilization'
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| every 1m

    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 ces étapes pour vérifier l'utilisation du processeur pour tous les autres pods de ce nœud et déterminer 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 :
    fetch k8s_container
| metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

    Si un autre conteneur utilise beaucoup de processeur sur le nœud, augmentez les demandes et les limites de processeur sur le conteneur qui fonctionne lentement. Le pod sera recréé 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 demandes 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 ratio entre les demandes de mémoire et les limites de mémoire sur le conteneur.

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

fetch k8s_container
| metric 'kubernetes.io/anthos/container/memory/limit_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

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 :

    fetch k8s_node
| metric 'kubernetes.io/anthos/node/memory/allocatable_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name = 'NODE_NAME'
| every 1m

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

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

    fetch k8s_node
| metric 'kubernetes.io/anthos/container_memory_usage_bytes'
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| group_by 1m,
    [value_container_memory_usage_bytes_mean:
      mean(value.container_memory_usage_bytes)]
| every 1m

    Si un conteneur utilise beaucoup de mémoire, examinez son fonctionnement ou augmentez la demande 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.

De plus, vous pouvez activer la fonctionnalité d'autoscaling dans Google Distributed Cloud pour augmenter ou réduire automatiquement la taille 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 du serveur d'API répétés au format suivant :

    etcdserver: request timed out et etcdserver: leader changed

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

    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 sur le nœud sur lequel le serveur etcd s'exécute. Reportez-vous à la section Le conteneur devient lent pour vérifier les problèmes de conflit de 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 ou le nœud du serveur etcd, il est possible que l'etcd soit 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 les données sur le 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. Ensuite, vérifiez 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 consoleGoogle Cloud  > Monitoring > Explorateur de métriques, dans l'éditeur MQL, exécutez la requête suivante :

      fetch k8s_container::kubernetes.io/anthos/etcd_disk_wal_fsync_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99

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

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

      fetch k8s_container::kubernetes.io/anthos/etcd_disk_backend_commit_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99

    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. Ensuite, vérifiez 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 du 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 si l'utilisation des opérations d'entrée/sortie par seconde (IOPS) est élevée. Si des pics d'IOPS sont constatés pour une VM, évaluez son fonctionnement.
    • Consultez votre équipe de laboratoire/d'infrastructure pour vous assurer que la bande passante de lecture et d'écriture n'est pas limitée ni bridée à un moment donné.
    • Consultez votre équipe de laboratoire/d'infrastructure pour identifier les problèmes de performances des disques et de performances de stockage, le cas échéant.

Pour en savoir plus, consultez les bonnes pratiques pour mettre à l'échelle vos ressources.

Problèmes liés au serveur d'API

Si les conteneurs de votre expérience Google Distributed Cloud présentent 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. La lenteur du temps de réponse peut persister même après que le serveur API a commencé à limiter les requêtes. Vérifiez donc le taux de requêtes API sur le serveur d'API.

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

fetch k8s_container::kubernetes.io/anthos/apiserver_request_total
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'APISERVER_POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| align rate(1m)
| every 1m
| group_by [metric.verb]

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, effectuez des recherches supplémentaires pour déterminer si les requêtes API sont attendues.

Limitation du CPU

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

Reportez-vous à la section Le conteneur devient lent pour vérifier les problèmes de conflit de 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 répondre aux requêtes de lecture / écriture des clients. Si etcd est lent ou ne répond pas, le serveur d'API le devient également.

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

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Si vous observez des 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 des métriques de votre cluster vers un projet Google Cloud .

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.

Pour 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

Affichez 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

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

kubectl --kubeconfig CLUSTER_KUBECONFIG top node

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

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --namespace NAMESPACE

Affichez 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 façons 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 le shell.

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

É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 les suivantes :

  • Conditions requises pour ouvrir une demande d'assistance.
  • Des outils pour vous aider à résoudre les problèmes, tels que les journaux et les métriques.
  • Composants, versions et fonctionnalités compatibles de Google Distributed Cloud pour VMware (logiciel uniquement).