Kubectl Top Pod: monitorea el uso de CPU y memoria en Kubernetes

TLDR: kubectl top pod te da una instantánea en vivo del uso de CPU (milicores) y memoria (Mi/Gi) por pod, con datos del Metrics Server. Úsalo para detectar pods que consumen muchos recursos, ordena con --sort-by=cpu/--sort-by=memory, desglosa el uso por contenedor con --containers y compara el uso real con los requests/limits configurados para detectar el sobreaprovisionamiento o subaprovisionamiento antes de que provoque throttling u OOM kills.

En este artículo:

• Requisitos para usar kubectl top pod
• Sintaxis básica de kubectl top pod
• Casos de uso de kubectl top pod
• Cómo interpretar la salida de kubectl top pod
• Buenas prácticas al usar kubectl top pod

Cómo interpretar la salida de kubectl top pod

La salida de kubectl top pod ofrece una instantánea del uso actual de CPU y memoria de los pods. Entender el significado de cada columna ayuda a identificar workloads que consumen muchos recursos y a diagnosticar problemas de rendimiento.

Ejemplo de salida:

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

Las columnas representan:

• NAME — El nombre del pod
• CPU (cores) — El uso actual de CPU
• MEMORY (bytes) — El consumo actual de memoria

Los valores de CPU se muestran normalmente en milicores (m):

• 1000m equivale a 1 core de CPU
• 250m equivale a 0.25 cores de CPU

Por ejemplo:

• 2m significa que el pod usa una cantidad mínima de CPU
• 500m significa que el pod consume medio core de CPU

Los valores de memoria se muestran en unidades binarias:

• Ki = kibibytes
• Mi = mebibytes
• Gi = gibibytes

Los valores mostrados son métricas de uso actual que recopila el Metrics Server. No son promedios históricos y pueden cambiar entre ejecuciones del comando. Por eso, kubectl top pod resulta más adecuado para verificaciones operativas rápidas que para el monitoreo a largo plazo.

Salida por contenedor:

Al usar el flag --containers, la salida incluye las métricas de cada contenedor dentro del pod:

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

Ejemplo de salida:

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

Usar la salida de top pod para diagnosticar problemas en los pods:

Después de identificar un consumo de recursos inusual, compara el uso real con los requests y limits configurados. Así se determina si los pods están correctamente dimensionados o si requieren ajustes para mejorar el rendimiento y la eficiencia de los recursos.

Buenas prácticas al usar kubectl top pod

Estas son algunas prácticas que conviene tener en cuenta al usar este comando.

1. Confirma que el Metrics Server esté instalado y en buen estado

Antes de confiar en kubectl top pod, verifica que el Metrics Server esté instalado y funcionando correctamente en tu clúster. Puedes comprobar su estado con kubectl get deployment metrics-server -n kube-system e inspeccionar los logs en busca de errores.

Si el Metrics Server está mal configurado o presenta fallas, kubectl top pod puede devolver datos incompletos o fallar por completo. Monitorea con regularidad el estado del Metrics Server para asegurarte de que las métricas de recursos reflejen el estado actual de tus workloads.

Ejemplo:

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

Salida:

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

Verifica la recolección de métricas:

kubectl top nodes

Salida:

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

2. Revisa siempre el namespace correcto

Los clústeres de Kubernetes suelen alojar varios namespaces, cada uno con distintos workloads o entornos. Al usar kubectl top pod, especifica el namespace correcto con el flag -n si no estás trabajando en el predeterminado.

No especificar el namespace puede llevar a pasar por alto problemas o a sacar conclusiones erróneas sobre el uso de recursos. Por ejemplo, podrías no detectar un pico de recursos en un entorno de staging si solo revisas el namespace predeterminado.

Ejemplo:

kubectl --namespace production top pod

Salida:

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

3. Ordena por CPU o memoria para encontrar más rápido los pods problemáticos

Ordenar los pods por uso de CPU o memoria destaca los que más recursos consumen. Usa --sort-by=cpu o --sort-by=memory para colocar al inicio de la salida los pods con mayor consumo. Revisar los pods según su consumo de recursos ayuda a resolver cuellos de botella y facilita la planificación de capacidad.

Ejemplo:

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

Salida:

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

4. Compara el uso real con los requests y limits

Para interpretar las métricas de recursos, compara el uso real que reporta kubectl top pod con los requests y limits definidos en las especificaciones del pod. Si un pod se acerca con frecuencia a sus límites de recursos, puede sufrir throttling o eviction. Un uso consistentemente bajo en relación con los requests sugiere sobreaprovisionamiento. Esta comparación ayuda a los equipos a ajustar la asignación de recursos y a evitar problemas como los OOMKills o el CPU throttling.

Ejemplo:

Ver el uso actual:

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

Salida:

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

Revisar los recursos configurados:

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

Salida (fragmento):

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

En este ejemplo, el pod se acerca tanto al límite de CPU como al de memoria y podría requerir ajustes.

5. Usa labels para verificaciones a nivel de workload

Los labels de Kubernetes te permiten filtrar y agrupar pods por aplicación, entorno o cualquier clave personalizada. Al combinar kubectl top pod con el flag -l, puedes monitorear el uso de recursos de un workload, equipo o microservicio específico.

Ejemplo:

Obtener los pods con un label específico:

kubectl -n production get pods -l app=web

Salida:

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

Revisar el uso de recursos de esos pods:

kubectl top pod -n production | grep web

Salida:

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

Así, los operadores pueden evaluar rápidamente el consumo de recursos de una aplicación o servicio específico sin revisar workloads no relacionados.

Cómo hacer right-sizing continuo de los recursos de tus pods con PerfectScale

Aunque kubectl top pod te da una instantánea en vivo del uso de CPU y memoria, convertir esas lecturas en los requests y limits correctos para cientos de workloads es un esfuerzo manual y constante. La solución de optimización de rendimiento de PerfectScale mejora el rendimiento de Kubernetes aplicando right-sizing de forma autónoma a tus workloads, previniendo caídas y optimizando el uso de recursos para lograr una disponibilidad del 99.99%, de modo que los patrones de uso que detectas con kubectl top pod se traducen directamente en cambios de configuración seguros y basados en datos.

Capacidades clave de PerfectScale:

• Remediación automática de problemas: Identifica y corrige al instante los riesgos de resiliencia, incluidos los problemas de subaprovisionamiento de recursos como OOM, CPU throttling y eviction, para maximizar el tiempo de actividad y eliminar la latencia.
• Right-sizing autónomo de CPU y memoria: Analiza continuamente tus workloads y ajusta los requests y limits de CPU y memoria según la demanda real, reduciendo el riesgo de throttling y recortando el costo de la nube, lo que resuelve el sobreaprovisionamiento y subaprovisionamiento que kubectl top pod te ayuda a detectar.
• Refuerzo de la infraestructura: Ofrece visibilidad integral de tus nodos para detectar proactivamente configuraciones incorrectas, prevenir la sobreasignación de nodos con recomendaciones precisas de límites de memoria, validar node affinities y taints, y seleccionar los tipos de nodo más adecuados para tus pods.
• Priorización según el impacto: Resuelve los problemas críticos en tiempo real con priorización automática, alinea las alertas con tus SLA/SLO, envía notificaciones instantáneas por canales como Slack, MS Teams o Datadog, y escala los problemas a un ticket con un solo clic.

¿Listo para pasar de las instantáneas manuales a la optimización autónoma? Descubre cómo PerfectScale mejora el rendimiento de Kubernetes.

Preguntas frecuentes

¿Por qué kubectl top pod devuelve "Metrics API not available"? El Metrics Server no está instalado o no funciona correctamente en tu clúster. Verifícalo con kubectl get deployment metrics-server -n kube-system e instálalo desde el manifiesto oficial de componentes si falta.

¿Qué significa realmente la columna CPU(cores)? Se muestra en milicores (m). 1000m equivale a un core completo de CPU, así que 250m es un cuarto de core y 2m es una cantidad insignificante de CPU.

¿Sirve kubectl top pod para el monitoreo a largo plazo? No. Es una instantánea en vivo del Metrics Server, no un promedio histórico, por lo que resulta más adecuado para verificaciones operativas rápidas que para el análisis de tendencias. Para el monitoreo a largo plazo, usa Prometheus/Grafana o herramientas similares.

¿Cómo veo las métricas por contenedor en lugar de por pod? Agrega el flag --containers: kubectl top pod <pod-name> --containers.

¿Cómo encuentro los pods que más consumen en un namespace? Usa kubectl top pod -n <namespace> --sort-by=cpu o --sort-by=memory para ordenar los pods por consumo, de mayor a menor.

¿Cómo sé si un pod está subaprovisionado o sobreaprovisionado? Compara el uso en vivo de kubectl top pod con los requests y limits configurados del pod (visibles con kubectl describe pod). Un uso consistentemente cercano al límite sugiere riesgo de subaprovisionamiento; un uso muy por debajo del request sugiere sobreaprovisionamiento.