Résoudre les problèmes de conflit de ressources

Cette page explique comment identifier et résoudre les problèmes de conflit de ressources dans votre environnement GKE sur VMware.

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

Présentation

Il peut arriver que votre GKE sur VMware rencontre des conflits de ressources, ce qui peut ralentir vos conteneurs, leur fournir des performances médiocres ou les arrêter. Cela peut être 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 programmé 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 par le conteneur est limitée à la limite du processeur.
    • Si l'utilisation du processeur est limitée au niveau du nœud, les cycles de processeur sont automatiquement attribués aux conteneurs en fonction des requêtes.

    En savoir plus sur la planification des pods avec des demandes de ressources.

  • Mémoire :

    • Un pod est programmé 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 l'arrêt 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 GKE Enterprise.

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'obtient pas de cycles de processeur proportionnels aux demandes de ressources de processeur ou s'il a été défini sur une valeur trop basse pour ce conteneur. Vous devez donc vérifier le ratio entre la limite de 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 :

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 des conteneurs exécutés 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. Obtenez 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 ne dispose pas de suffisamment de cycles de processeur et qu'il est sursouscrit. Suivez ces étapes pour vérifier l'utilisation du processeur par tous les autres pods de ce nœud et rechercher si un autre conteneur utilise plus de processeurs.

    1. Récupérez 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. Le pod est alors recréé sur un autre nœud pour obtenir les cycles de processeur requis.

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

Sursouscription de processeur au niveau de vSphere

Si l'utilisation 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 sursouscrite au niveau de vSphere. Par conséquent, le nœud n'est pas en mesure d'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, procédez comme suit:

Le pod est arrêté (à cause de la mémoire insuffisante)

Les pods peuvent être bloqués en raison de fuites de mémoire ou d'une mauvaise configuration des demandes 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é si l'un de ses conteneurs consomme trop de mémoire totale allouée. Vous devez donc vérifier le ratio entre les demandes 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 :

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

Un pod peut être arrêté 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 à allouer au pod, peut-être en raison d'une consommation importante de mémoire par certains processus ou autres pods.

  3. Dans 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 qui consomme beaucoup de mémoire, contactez l'assistance Google.

De plus, vous pouvez activer la fonctionnalité d'autoscaling dans GKE sur VMware pour augmenter ou réduire automatiquement le scaling des 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 défaillances de conteneurs en raison de problèmes de serveur etcd. Vous pouvez observer ce qui suit:

  • Journaux répétés du serveur d'API sous la forme suivante:

    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 de 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 de 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é OOM en raison de problèmes de conflits de ressources. Reportez-vous à la procédure décrite dans la section Le pod est arrêté (hors mémoire morte) 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 est en cours d'exécution.

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 d'utilisation du processeur ou de la mémoire sur le pod de serveur etcd ou sur 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 à 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 schéma suivant pour déterminer si la lecture de etcd à partir du disque prend trop de temps:

      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 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 du service 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_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 est continuellement 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

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 > Performance > Avancé) et sélectionnez Virtual Disk (Disque virtuel) dans la section View (Vue) afin d'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 laboratoire/équipe d'infrastructure pour vous assurer que la bande passante en lecture et en écriture n'est en aucun cas limitée.
    • Consultez votre équipe de laboratoire/d'infrastructure pour identifier les problèmes de performance du disque et de performances de stockage, le cas échéant.

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

Problèmes liés au serveur d'API

Si les conteneurs de votre environnement GKE sur VMware 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 sur celui-ci sont trop élevés. Le temps de réponse peut persister même si le serveur d'API commence à limiter les requêtes. Vous devez donc vérifier 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 plus en détail le système afin de 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 de CPU sur le pod du serveur d'API et/ou le nœud.

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

Pod du serveur d'API arrêté

Le pod du serveur d'API peut être arrêté OOM en raison de problèmes de conflit de ressources. Reportez-vous à la procédure décrite dans la section Le pod est arrêté (à cause de la mémoire insuffisante) 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 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 tels que etcdserver: request timedout ou etcdserver: leader changed, suivez les étapes de la section Problèmes Etcd pour résoudre les problèmes de disque.

Étapes suivantes

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