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 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 consommation élevée du processeur ou de la 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 dans un pod ne peut pas utiliser plus de CPU 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 requêtes.

    Découvrez comment programmer des pods avec des demandes 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 pages 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 contention de processeur peuvent ralentir les conteneurs. Voici quelques raisons possibles:

Utilisation élevée du processeur dans le conteneur:

Un conteneur peut devenir lent s'il ne reçoit 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 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 de la limite de processeur sur l'utilisation n'est pas élevé pour un conteneur spécifique du pod, cela peut signifier 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 allouables 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 fait l'objet d'une sursouscription. Suivez donc ces étapes pour vérifier l'utilisation du processeur de tous les autres pods sur ce nœud et déterminer s'il existe un autre conteneur qui 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 une grande quantité de processeur sur le nœud, augmentez les demandes et les limites de processeur du conteneur qui fonctionne lentement. Le pod sera ainsi 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 :

  • Déplacez certaines VM vers d'autres hôtes.
  • Évaluez et réduisez le nombre de processeurs virtuels par VM pour l'hôte.
  • Allouez davantage de ressources aux VM GKE Enterprise.
  • Augmentez les demandes de processeur et les limites du conteneur. Le pod sera ainsi recréé sur un autre nœud pour obtenir les cycles de processeur requis.

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 raisons possibles:

Utilisation élevée de la mémoire dans 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 des requêtes de mémoire par rapport aux 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é 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 inspectez 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, probablement en raison de certains processus ou d'autres pods qui consomment beaucoup de mémoire.

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

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

Découvrez comment activer l'autoscaler.

Problèmes avec 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 de la forme:

    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 raisons possibles:

Limitation du CPU

Le serveur etcd peut être lent en raison du débit limité 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 CPU.

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

Si aucun problème de consommation de processeur ou de mémoire n'est détecté sur le pod de serveur etcd ou sur le nœud, 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 la lecture à partir du disque prend trop de temps pour etcd:

      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 format 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 d'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. Extrayez les latences d'écriture d'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 supérieur à 10 ms en continu et/ou si p99 pour etcd_disk_backend_commit_duration_seconds est supérieur à 25 ms en continu, cela indique une lenteur du disque. Vérifiez ensuite les performances du datastore et des disques.

Latence 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 elles utilisent un nombre élevé d'opérations d'entrée/sortie par seconde (IOPS). Si une VM présente des pics d'IOPS, évaluez son fonctionnement.
    • Consultez votre équipe de laboratoire/d'infrastructure pour vous assurer que la bande passante de lecture et d'écriture n'est à aucun moment limitée ou limitée.
    • 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 faire évoluer vos ressources.

Problèmes liés au serveur d'API

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

Voici quelques raisons possibles:

Volume élevé de requêtes d'API

Le serveur d'API peut être lent à répondre si la fréquence et le volume des requêtes qui lui sont adressées sont trop élevés. Le temps de réponse lent peut persister même après que le serveur API a commencé à limiter les requêtes. Vérifiez donc le taux de requêtes d'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 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 plus approfondies pour déterminer si les requêtes API sont attendues.

Limitation du CPU

Un débit de requêtes élevé sur le serveur d'API peut entraîner le débit limité du processeur. Le serveur d'API peut alors ralentir en raison d'un conflit de CPU sur le pod du serveur d'API et/ou le nœud.

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 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 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 la procédure décrite dans la section Problèmes 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 s'appuient sur l'exportation de 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 les conflits de 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 pour 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

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.

Il existe 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.