Résoudre les problèmes de conflits de ressources

Version 1.16 

• Dernière version
• Version 1.16
• Versions antérieures (non compatibles)

Cette page explique comment identifier et résoudre les problèmes de conflits de ressources dans votre environnement Clusters Anthos sur VMware (GKE sur VMware). Si vous avez besoin d'une aide supplémentaire, consultez la page Obtenir de l'aide.

Présentation

Il peut arriver que vos clusters Anthos sur VMware rencontrent des conflits au niveau des ressources, ce qui peut ralentir vos conteneurs, leur nuire ou les arrêter. Cela peut se produire en raison d'une utilisation élevée du processeur ou de la mémoire par les conteneurs.

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

• Processeur :

  • 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 dans un pod ne peut pas utiliser plus de processeurs que la limite spécifiée par le conteneur.
  • L'utilisation du processeur par le conteneur est limitée à la limite du 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.

  Découvrez comment les pods avec des demandes de ressources sont planifiés.

• 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 OOM-Killer (Out Of Memory Killer) et évincer les pods de faible priorité.

Pour en savoir plus, consultez Attribuer des ressources de processeur, Attribuer des ressources de mémoire dans Kubernetes et Métriques Anthos.

Issues

Le conteneur devient lent

Les problèmes de conflit de CPU 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'est pas soumis à des cycles de processeur proportionnels aux demandes de ressources de processeur, ou s'il a été défini sur une valeur trop faible par rapport aux besoins du conteneur. Vous devez donc vérifier le ratio entre la limite du processeur et l'utilisation du processeur pour le conteneur.

Dans la console Google 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 :

• Si ce ratio est élevé (>=0,8), cela signifie que la limite du processeur sur le conteneur est faible et que Kubernetes limite les cycles de processeur du conteneur afin de maintenir l'utilisation du processeur dans les limites de la limite. Pour résoudre ce problème, augmentez la limite de processeur sur le conteneur.
• Si ce ratio n'est pas élevé (< 0,8), vérifiez si l'utilisation du processeur est élevée sur le nœud.

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

Si le ratio entre la limite du 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 de conteneurs s'exécutant sur le nœud. Pour vérifier le ratio entre l'utilisation réelle du processeur et le nombre de processeurs pouvant être alloués sur le nœud, procédez comme suit:

1. Récupérez le nœud du pod qui fonctionne lentement:

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

2. Dans la console Google 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 n'a pas assez de cycles de processeur et qu'il est surabonné. Suivez donc ces étapes pour vérifier l'utilisation du processeur par tous les autres pods de ce nœud et déterminer si un autre conteneur utilise plus de processeurs.

   1. Obtenez tous les pods du 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 ressources processeur sur le nœud, augmentez les demandes et les limites de ressources de processeur sur le conteneur qui fonctionne lentement. Cette opération recrée le pod sur un autre nœud afin d'obtenir les cycles de processeur requis.

S'il s'agit d'un pod système qui fonctionne lentement, contactez l'assistance Google.

Sursouscription du processeur au niveau de vSphere

Si la consommation du processeur n'est pas élevée sur le nœud ou le pod, et que le conteneur est toujours lent, il est possible que la VM soit surabonnée au niveau de vSphere. Par conséquent, le nœud n'est pas en mesure d'obtenir les cycles de processeur attendus à partir de la virtualisation sous-jacente.

Suivez ces étapes pour vérifier si la VM est surabonnée. En cas de sursouscription, procédez comme suit:

• Déplacez des VM vers d'autres hôtes.
• Évaluer et réduire le nombre de processeurs virtuels par VM pour l'hôte
• Allouez davantage de ressources aux VM Anthos.
• Augmentez les demandes et les limites de processeur sur le conteneur. Cette opération recrée le pod sur un autre nœud afin d'obtenir les cycles de processeur requis.

Le pod est bloqué en mémoire morte

Les pods peuvent être arrêtés "OOMKilled" en raison de fuites de mémoire ou d'une mauvaise configuration des requêtes et 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é "OOMkill" si l'un de ses conteneurs consomme trop de mémoire totale allouée. Vous devez donc vérifier le ratio entre les requêtes de mémoire et les limites de mémoire sur le conteneur.

Dans la console Google 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 :

• Si ce ratio est élevé (>= 0,8), augmentez la limite de mémoire du conteneur.
• Si ce ratio n'est pas élevé (< 0,8), vérifiez si l'utilisation de la mémoire sur le nœud est élevée.

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

Un pod peut être arrêté "OOMkill" si l'utilisation de 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 inspectez la section Conditions:

   kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME
   

2. Si la condition MemoryPressure est définie sur 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 pour l'allouer au pod.Cela peut être dû à des processus ou à d'autres pods qui consomment beaucoup de mémoire.

3. Dans la console Google Cloud > Surveillance > 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 du 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.

S'il s'agit d'un pod système consommant beaucoup de mémoire, contactez l'assistance Google.

De plus, vous pouvez activer la fonctionnalité d'autoscaling dans Clusters Anthos sur VMware pour augmenter ou diminuer automatiquement les pools de nœuds en fonction des exigences de vos charges de travail.

Découvrez comment activer l'autoscaler.

Problèmes liés à etc.

Il peut arriver que vos clusters Anthos sur VMware rencontrent des échecs de conteneur en raison de problèmes de serveur etcd. Vous pouvez observer ce qui suit:

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

  etcdserver: request timed out et etcdserver: leader changed

• Journaux etcd répétés de la forme:

  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 du nœud sur lequel le serveur etcd s'exécute. Reportez-vous aux étapes de la section Le conteneur devient lent pour rechercher d'éventuels problèmes de conflit du processeur.

Si vous détectez des conflits de processeurs sur le pod du serveur ectd ou sur le nœud, ajoutez des processeurs au nœud de 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 OOMkilled

Le pod etcd peut être arrêté OOMkill en raison de problèmes de conflits de ressources. Reportez-vous à la procédure décrite dans la section Le pod est bloqué en mémoire insuffisante pour rechercher d'éventuels problèmes de conflit de mémoire avec le pod de serveur etcd et/ou le nœud sur lequel le serveur etcd s'exécute.

Si vous détectez des OOMkills pour le pod etcd, augmentez la mémoire disponible pour le nœud de 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

En l'absence de problèmes de processeur ou de consommation de mémoire sur le pod de serveur etcd ou le nœud, etcd peut être lent si le magasin de données sous-jacent est lent ou limité.

Recherchez les problèmes suivants:

• Pour vérifier si le serveur etcd prend trop de temps pour lire ou é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éterminer si etcd prend trop de temps pour 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éterminer si etcd prend trop de temps pour écrire sur le disque:

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

  Si l'un des schémas de journaux ci-dessus (ou les deux) apparaît 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 etcd wal:

     Dans la console Google 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 console Google 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 continuellement supérieur à 10 ms et/ou p99 pour etcd_disk_backend_commit_duration_seconds reste continuellement supérieure à 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

Suivez ces étapes pour vérifier les latences de lecture/écriture sur le disque virtuel de VM

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 ci-dessus. Dans vSphere, accédez à Monitor > Performance > Advanced (Surveiller > Performances > Avancé), puis sélectionnez Virtual Disk (Disque virtuel) dans la section View (Vue) 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 du nombre d'opérations d'entrée/de sortie par seconde (IOPS). Si une VM présente des pics d'IOPS, évaluez son fonctionnement.
   • Consultez votre atelier ou votre équipe chargée de l'infrastructure pour vous assurer que la bande passante en lecture et en écriture n'est en aucun cas limitée ou limitée.
   • Consultez votre atelier ou l'équipe chargée de l'infrastructure pour identifier les problèmes de performances du disque et de performances de stockage, le cas échéant.

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

Problèmes liés au serveur d'API

Si les conteneurs de vos clusters Anthos sur VMware connaissent 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 important de requêtes API

Le serveur d'API peut être lent à répondre si la fréquence et le volume des requêtes sur celui-ci sont trop élevés. Le temps de réponse peut persister même si le serveur d'API commence à réguler les requêtes. Vérifiez donc le taux de requêtes API sur le serveur d'API.

Dans la console Google 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 du nombre de requêtes API, utilisez Cloud Audit Logging pour identifier le pod qui risque d'interroger 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 la situation plus en détail 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 de conflits au niveau du processeur au niveau du pod du serveur d'API et/ou du nœud.

Reportez-vous à la section Le conteneur devient lent pour rechercher d'éventuels problèmes de conflit de processeur au niveau du pod et/ou du nœud.

Opération OOMkilled du pod du serveur d'API

Il est possible que le pod du serveur d'API soit arrêté OOMkill en raison de problèmes de conflits de ressources. Reportez-vous à la procédure décrite dans la section Le pod est bloqué en mémoire morte pour rechercher d'éventuels problèmes de conflit de mémoire au niveau du pod et/ou du nœud.

Réponses etcd lentes

Le serveur d'API s'appuie sur la communication avec le cluster etcd pour diffuser des requêtes de lecture / écriture aux clients. Si le etcd est lent ou ne répond plus, 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 à cause des problèmes liés à etcd:

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Si vous observez des journaux récurrents comme etcdserver: request timedout ou etcdserver: leader changed, suivez la procédure décrite dans Problèmes Etcd pour résoudre les problèmes de disque.