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 Google Distributed Cloud.

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

Présentation

Il peut arriver que votre Google Distributed Cloud rencontre des conflits de ressources, entraînant un ralentissement, une sous-performance ou l'arrêt de vos conteneurs. 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 programmé sur un nœud en fonction des demandes de ressources 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 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.

    Apprenez-en plus sur la planification des pods avec des demandes de ressources.

  • Mémoire :

    • Un pod est programmé 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 définie.
    • Si aucune limite de mémoire n'est spécifiée, un conteneur peut consommer toute la mémoire disponible sur un nœud. Ensuite, le système peut 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 GKE Enterprise.

Problèmes

Le conteneur devient lent

Les problèmes de conflits au niveau du processeur peuvent entraîner la lenteur des 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 est défini sur une valeur trop faible par rapport aux besoins du conteneur. Vérifiez donc 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 limite de processeur/utilisation n'est pas élevé pour un conteneur individuel du pod, il se peut que le nœud n'ait pas assez de cycles de processeur à allouer à l'ensemble des conteneurs en cours d'exécution 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 n'a pas assez de cycles de processeur et qu'il est sursouscription. Procédez donc comme suit pour vérifier l'utilisation du processeur pour tous les autres pods de ce nœud et déterminer si un autre conteneur utilise davantage 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 une utilisation élevée du processeur sur le nœud, augmentez les demandes et les limites de processeur sur le conteneur qui fonctionne lentement. Le pod est alors recréé 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 de processeurs au niveau de vSphere

Si la consommation de processeurs n'est pas élevée sur le nœud ni sur le pod, et que le conteneur est toujours lent, il est possible que la VM soit sursoumise 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 en sursouscription. Si vous détectez un sursouscription, procédez comme suit:

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

Les pods peuvent subir un arrêt OOMKilled 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 éliminé OOMkill (OOMkill) si un conteneur d'un pod consomme la mémoire totale allouée. Vérifiez donc 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 éliminé 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 que 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 pour allouer au pod.Cela peut être dû à certains 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 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.

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 Google Distributed Cloud pour augmenter ou réduire automatiquement le nombre de pools de nœuds en fonction des exigences de vos charges de travail.

Découvrez comment activer l'autoscaler.

Problèmes d'etc.

Parfois, vos clusters Anthos sur VMware peuvent rencontrer des défaillances de conteneur en raison de problèmes de serveur etcd, et vous pouvez constater 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 suivante:

    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 s'exécute. Reportez-vous aux étapes de la section Le conteneur devient lent pour rechercher d'éventuels problèmes de conflits au niveau du processeur.

Si vous détectez des conflits au niveau des processeurs sur le pod du 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.

Arrêt de la fonction OOM du pod Etcd

Le pod etcd peut être arrêté pour cause d'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 bloqué en raison de l'arrêt hors mémoire du pod pour rechercher d'éventuels problèmes de conflit de mémoire avec le pod du serveur etcd et/ou le nœud sur lequel le serveur etcd est en cours d'exécution.

Si vous détectez des événements OOMkill 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 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 prend trop de temps en lecture/écriture 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 la lecture d'etcd sur le 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 à écrire sur le disque:

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

    Si l'un des formats de journal ci-dessus, ou les deux, s'affiche 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 de la wal pour 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 constamment supérieur à 10 ms et/ou que p99 pour etcd_disk_backend_commit_duration_seconds est constamment supérieur à 25 ms, cela signifie que le disque est lent. 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és), 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:

    • Examiner les autres VM exécutées sur le datastore pour vérifier que le nombre d'opérations d'entrée/de sortie par seconde (IOPS) est élevé Si une VM présente des pics d'IOPS, évaluez son fonctionnement.
    • Consultez votre laboratoire ou votre équipe chargée de l'infrastructure pour vous assurer que la bande passante de lecture et d'écriture n'est jamais limitée ni limitée.
    • Consultez l'équipe de l'atelier/de l'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 pour le scaling de vos ressources.

Problèmes liés au serveur d'API

Si les conteneurs de votre Google Distributed Cloud subissent une latence lorsqu'ils communiquent avec le serveur d'API, ou si les commandes Kubectl échouent ou mettent trop de temps à répondre, cela peut indiquer des problèmes au niveau du 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 lorsque 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 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]

Si vous constatez une augmentation inattendue du nombre de requêtes API, utilisez Cloud Audit Logging pour identifier le pod susceptible d'interroger le serveur d'API trop souvent.

  • S'il s'agit d'un pod système, contactez l'assistance Google.
  • S'il s'agit d'un pod utilisateur, approfondissez vos recherches 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. Ensuite, le serveur d'API peut devenir lent en raison d'un conflit de processeur sur le pod du serveur d'API et/ou le nœud.

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

Pod de serveur d'API tué par l'OOM

Le pod du serveur d'API peut être arrêté définitivement en raison de problèmes de conflit de ressources. Reportez-vous à la procédure décrite dans la section Le pod est bloqué en raison d'un blocage de mémoire insuffisante (OOMkilling) pour rechercher d'éventuels problèmes de conflit de mémoire entre 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 fournir les requêtes de lecture / écriture aux clients. Si 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 s'il est lent en raison des 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 de la section Problèmes Etcd pour résoudre les problèmes liés au disque.

Étapes suivantes

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