Kubectl Top Pod : surveillez la consommation CPU et mémoire de vos pods Kubernetes

TLDR : kubectl top pod fournit un instantané en temps réel de l'utilisation CPU (millicores) et mémoire (Mi/Gi) par pod, grâce au Metrics Server. Utilisez-le pour repérer les pods gourmands en ressources, trier avec --sort-by=cpu/--sort-by=memory, détailler la consommation par conteneur avec --containers, et comparer l'utilisation réelle aux requests/limits configurées afin de détecter le sur- ou sous-provisionnement avant qu'il ne provoque du throttling ou des OOM kills.

Dans cet article :

• Prérequis pour utiliser kubectl top pod
• Syntaxe de base de kubectl top pod
• Cas d'usage de kubectl top pod
• Comment lire la sortie de kubectl top pod
• Bonnes pratiques pour utiliser kubectl top pod

Comment lire la sortie de kubectl top pod

La sortie de kubectl top pod fournit un instantané de l'utilisation CPU et mémoire actuelle des pods. Comprendre la signification de chaque colonne aide à identifier les workloads gourmands en ressources et à diagnostiquer les problèmes de performance.

Exemple de sortie :

NAME                      CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    2m           15Mi
api-server-7f89c7d9d      25m          120Mi

Les colonnes représentent :

• NAME — Le nom du pod
• CPU (cores) — L'utilisation CPU actuelle
• MEMORY (bytes) — La consommation mémoire actuelle

Les valeurs CPU sont généralement exprimées en millicores (m) :

• 1000m équivaut à 1 cœur CPU
• 250m équivaut à 0,25 cœur CPU

Par exemple :

• 2m signifie que le pod utilise très peu de CPU
• 500m signifie que le pod consomme un demi-cœur CPU

Les valeurs mémoire sont affichées en unités binaires :

• Ki = kibioctets
• Mi = mébioctets
• Gi = gibioctets

Les valeurs affichées correspondent à l'utilisation actuelle collectée par le Metrics Server. Il ne s'agit pas de moyennes historiques et elles peuvent varier d'une exécution à l'autre. C'est pourquoi kubectl top pod convient davantage aux vérifications opérationnelles rapides qu'au monitoring à long terme.

Sortie pour les conteneurs :

Avec le flag --containers, la sortie inclut les métriques de chaque conteneur du pod :

kubectl top pod nginx-6d4cf56db6-xk8rt --containers

Exemple de sortie :

POD                       NAME    CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    nginx   2m           15Mi

Utiliser la sortie de top pod pour diagnostiquer les problèmes :

Après avoir identifié une consommation de ressources inhabituelle, comparez l'utilisation réelle aux requests et limits configurées. Cela permet de déterminer si les pods sont correctement dimensionnés ou s'ils nécessitent des ajustements pour améliorer les performances et l'efficacité des ressources.

Bonnes pratiques pour utiliser kubectl top pod

Voici quelques pratiques utiles à garder à l'esprit lors de l'utilisation de cette commande.

1. Vérifier que le Metrics Server est installé et opérationnel

Avant de vous appuyer sur kubectl top pod, vérifiez que le Metrics Server est installé et fonctionne correctement dans votre cluster. Vous pouvez contrôler son état avec kubectl get deployment metrics-server -n kube-system et inspecter les logs à la recherche d'erreurs.

Si le Metrics Server est mal configuré ou défaillant, kubectl top pod peut renvoyer des données incomplètes ou échouer complètement. Surveillez régulièrement l'état du Metrics Server pour vous assurer que les métriques reflètent l'état actuel de vos workloads.

Exemple :

kubectl --namespace=kube-system get deployment metrics-server

Sortie :

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           45d

Vérifier la collecte des métriques :

kubectl top nodes

Sortie :

NAME             CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
worker-node-1    420m         21%    3120Mi           39%
worker-node-2    365m         18%    2875Mi           36%

2. Toujours vérifier le bon namespace

Les clusters Kubernetes hébergent souvent plusieurs namespaces, chacun contenant des workloads ou des environnements différents. Avec kubectl top pod, précisez le namespace approprié avec le flag -n si vous ne travaillez pas dans le namespace par défaut.

Omettre le namespace peut conduire à passer à côté de problèmes ou à tirer des conclusions erronées sur l'utilisation des ressources. Vous pourriez par exemple manquer un pic de consommation dans un environnement de staging si vous ne consultez que le namespace par défaut.

Exemple :

kubectl --namespace production top pod

Sortie :

NAME                        CPU(cores)   MEMORY(bytes)
frontend-76d9c7f7f5-qn9p8   65m          210Mi
backend-5c8b7d9f67-jh2wt    220m         580Mi
redis-0                     15m          140Mi

3. Trier par CPU ou mémoire pour repérer plus vite les pods les plus gourmands

Trier les pods par utilisation CPU ou mémoire met en évidence ceux qui consomment le plus de ressources. Utilisez --sort-by=cpu ou --sort-by=memory pour placer les pods les plus gourmands en tête de la sortie. Passer en revue les pods selon leur consommation aide à traiter les goulets d'étranglement et facilite la planification de capacité.

Exemple :

kubectl top pods -n production --sort-by=memory

Sortie :

NAME                          CPU(cores)   MEMORY(bytes)
analytics-worker-7f4b7d5c8d   320m         1850Mi
api-server-6b8f4d5f4d         140m         720Mi
frontend-76d9c7f7f5           60m          220Mi

4. Comparer l'utilisation aux requests et limits

Pour interpréter les métriques de ressources, comparez l'utilisation réelle rapportée par kubectl top pod aux requests et limits définies dans les spécifications des pods. Si un pod s'approche fréquemment de ses limites de ressources, il peut subir du throttling ou une éviction. À l'inverse, une utilisation constamment faible par rapport aux requests suggère un surprovisionnement. Cette comparaison aide les équipes à ajuster les allocations de ressources et à éviter des problèmes comme les OOMKills ou le CPU throttling.

Exemple :

Afficher l'utilisation actuelle :

kubectl -n production top pod api-server-6b8f4d5f4d

Sortie :

NAME                     CPU(cores)   MEMORY(bytes)
api-server-6b8f4d5f4d    850m         920Mi

Vérifier les ressources configurées :

kubectl -n production describe pod api-server-6b8f4d5f4d

Sortie (extrait) :

Limits:
  cpu:     1
  memory:  1Gi
Requests:
  cpu:     500m
  memory:  512Mi

Dans cet exemple, le pod s'approche à la fois de ses limites CPU et mémoire et pourrait nécessiter des ajustements.

5. Utiliser les labels pour des vérifications au niveau des workloads

Les labels Kubernetes permettent de filtrer et de regrouper les pods par application, environnement ou clé personnalisée. En combinant kubectl top pod avec le flag -l, vous pouvez surveiller l'utilisation des ressources d'un workload, d'une équipe ou d'un microservice spécifique.

Exemple :

Récupérer les pods portant un label spécifique :

kubectl -n production get pods -l app=web

Sortie :

NAME                       READY   STATUS
web-6d7f9d8f8b-7xt2m       1/1     Running
web-6d7f9d8f8b-kq4pn       1/1     Running

Vérifier l'utilisation des ressources de ces pods :

kubectl top pod -n production | grep web

Sortie :

web-6d7f9d8f8b-7xt2m   35m   120Mi
web-6d7f9d8f8b-kq4pn   42m   135Mi

Les opérateurs peuvent ainsi évaluer rapidement la consommation de ressources d'une application ou d'un service donné sans passer en revue des workloads sans rapport.

Right-sizing continu des ressources des pods avec PerfectScale

Si kubectl top pod vous fournit un instantané en temps réel de l'utilisation CPU et mémoire, transformer ces relevés en requests et limits adaptées pour des centaines de workloads reste un travail manuel permanent. La solution d'optimisation des performances de PerfectScale améliore les performances Kubernetes grâce au right-sizing autonome des workloads, en prévenant les interruptions de service et en optimisant l'utilisation des ressources pour une disponibilité de 99,99 %. Les schémas d'utilisation que vous repérez avec kubectl top pod se traduisent ainsi directement en changements de configuration sûrs et basés sur les données.

Fonctionnalités clés de PerfectScale :

• Correction automatique des problèmes : Identifie et corrige instantanément les risques pour la résilience, y compris les problèmes de sous-provisionnement des ressources comme les OOM, le CPU throttling et les évictions, afin de maximiser la disponibilité et d'éliminer la latence.
• Right-sizing autonome du CPU et de la mémoire : Analyse en continu vos workloads et ajuste les requests et limits CPU et mémoire en fonction de la demande réelle, réduisant le risque de throttling tout en diminuant les coûts cloud — et corrige ainsi le sur- et le sous-provisionnement que kubectl top pod vous aide à détecter.
• Renforcement de l'infrastructure : Offre une visibilité globale sur vos nœuds pour détecter proactivement les erreurs de configuration, prévenir la surallocation des nœuds grâce à des recommandations précises de limites mémoire, valider les affinités de nœuds et les taints, et sélectionner les types de nœuds les plus adaptés à vos pods.
• Priorisation selon l'impact : Résout les problèmes critiques en temps réel grâce à la priorisation automatique, aligne les alertes sur vos SLA/SLO, envoie des notifications instantanées via Slack, MS Teams ou Datadog, et transforme un incident en ticket en un seul clic.

Prêt à passer des instantanés manuels à l'optimisation autonome ? Découvrez comment PerfectScale améliore les performances Kubernetes.

FAQ

Pourquoi kubectl top pod renvoie-t-il l'erreur Metrics API not available ? Le Metrics Server n'est pas installé ou n'est pas opérationnel dans votre cluster. Vérifiez avec kubectl get deployment metrics-server -n kube-system et installez-le à partir du manifeste officiel des composants s'il est absent.

Que signifie réellement la colonne CPU(cores) ? Elle est exprimée en millicores (m). 1000m équivaut à un cœur CPU complet : 250m représente donc un quart de cœur et 2m une quantité négligeable de CPU.

kubectl top pod convient-il au monitoring à long terme ? Non. Il s'agit d'un instantané en direct fourni par le Metrics Server, et non d'une moyenne historique : la commande est donc idéale pour des vérifications opérationnelles rapides plutôt que pour l'analyse de tendances. Utilisez Prometheus/Grafana ou un outil similaire pour le monitoring à long terme.

Comment afficher les métriques par conteneur plutôt que par pod ? Ajoutez le flag --containers : kubectl top pod <pod-name> --containers.

Comment trouver les pods les plus gourmands dans un namespace ? Utilisez kubectl top pod -n <namespace> --sort-by=cpu ou --sort-by=memory pour trier les pods par consommation, du plus élevé au plus faible.

Comment savoir si un pod est sous- ou surprovisionné ? Comparez l'utilisation en direct affichée par kubectl top pod aux requests et limits configurées du pod (visibles via kubectl describe pod). Une utilisation constamment proche de la limite indique un risque de sous-provisionnement ; une utilisation très inférieure à la request suggère un surprovisionnement.