Domina el rendimiento de Kubernetes: 10 métricas clave y guía de tuning

¿Qué es el rendimiento de Kubernetes?

TL;DR: El rendimiento de Kubernetes se define por la eficiencia, la confiabilidad y la velocidad de tu clúster. Las áreas clave incluyen los tiempos de arranque de los pods, la capacidad de respuesta del servidor de API y el consumo de recursos. Para optimizarlo, se requiere afinar la asignación de recursos, evitar el CPU throttling y usar herramientas como ClusterLoader2 para medir los límites bajo carga.

Métricas de rendimiento críticas:

Para mantener la salud del clúster, debes monitorear activamente estas áreas centrales del sistema:

• Uso de CPU: Monitorea la utilización de CPU a nivel de pod, contenedor y nodo para identificar contención de recursos, throttling y limitaciones de capacidad.
• Uso de memoria: Da seguimiento al consumo de memoria para detectar fugas, prevenir la presión en los nodos y evitar el desalojo de pods.
• Reinicios de pods: Presta atención a los reinicios frecuentes de contenedores, que pueden indicar fallas de la aplicación, probes fallidas o límites de recursos excedidos.
• Estado y disponibilidad de los pods: Monitorea los estados y el readiness de los pods para asegurar que los workloads se mantengan saludables y puedan atender el tráfico.
• Métricas de presión en los nodos: Da seguimiento al CPU throttling, al consumo total de memoria y a la E/S de disco, ya que los cuellos de botella en los nodos se propagan a los workloads.
• E/S de disco y almacenamiento: Mide el throughput, la latencia y las IOPS para identificar cuellos de botella de almacenamiento que afecten el rendimiento de las aplicaciones.
• Rendimiento del scheduler: Da seguimiento a la latencia de scheduling, a los pods pendientes y a las fallas de scheduling para asegurar que los workloads se ubiquen de forma eficiente.
• Métricas de autoescalado: Monitorea la actividad de escalado, el número de réplicas y las métricas de utilización para verificar que los autoscalers respondan adecuadamente a los cambios de demanda.
• Métricas de aplicación: Mide la latencia, el throughput, las tasas de error y otros indicadores a nivel de servicio para entender el rendimiento que perciben los usuarios.
• Métricas del plano de control: Monitorea la latencia de etcd (idealmente <10 ms) y las latencias de las solicitudes al kube-apiserver para prevenir cuellos de botella en la API.

En este artículo:

• Por qué importa el rendimiento de Kubernetes
• Problemas comunes de rendimiento en Kubernetes
• Métricas críticas de rendimiento de Kubernetes
• Cómo diagnosticar problemas de rendimiento en Kubernetes
• Buenas prácticas de tuning de rendimiento en Kubernetes

---

Por qué importa el rendimiento de Kubernetes

El rendimiento de Kubernetes afecta la disponibilidad de las aplicaciones, la escalabilidad y la eficiencia de costos. Un clúster que funciona bien puede manejar workloads cambiantes con demoras mínimas, mientras que un rendimiento deficiente puede provocar tiempos de respuesta más lentos, interrupciones del servicio y recursos de infraestructura desaprovechados. A medida que las organizaciones dependen de Kubernetes para operar sus sistemas de producción, mantener un rendimiento sólido es indispensable para cumplir los objetivos operativos y de negocio.

• Mejora la confiabilidad de las aplicaciones: La asignación eficiente de recursos y el scheduling ayudan a que las aplicaciones se mantengan estables ante workloads variables, reduciendo el riesgo de caídas y de degradación del rendimiento.
• Mejora la experiencia de usuario: Tiempos de arranque de pods más rápidos, menor latencia y una capacidad de respuesta consistente de las aplicaciones mejoran la experiencia de los usuarios finales.
• Facilita un escalado eficiente: Los clústeres de alto rendimiento pueden responder rápidamente a los cambios en la demanda, asegurando que los workloads escalen sin demoras innecesarias.
• Reduce los costos de infraestructura: El uso optimizado de CPU, memoria, almacenamiento y red reduce la pérdida de recursos y ayuda a evitar el sobreaprovisionamiento.
• Previene la contención de recursos: El tuning de rendimiento ayuda a asegurar que los workloads no compitan en exceso por recursos compartidos, reduciendo cuellos de botella y manteniendo un comportamiento predecible.
• Mejora la eficiencia operativa: Un scheduling más rápido, una recuperación más ágil ante fallas y operaciones de clúster más fluidas reducen la carga de los equipos de plataforma y operaciones.
• Ayuda a cumplir los objetivos de nivel de servicio (SLO): Monitorear y optimizar el rendimiento permite mantener las metas de disponibilidad, tiempos de respuesta y confiabilidad.
• Fortalece la estabilidad del clúster: Identificar y resolver problemas como la presión en los nodos, los reinicios excesivos de pods o las demoras en el plano de control ayuda a mantener un entorno de Kubernetes saludable y resiliente.

---

Problemas comunes de rendimiento en Kubernetes

1. Requests y limits de recursos mal configurados

Unos requests y limits de recursos mal definidos son una causa frecuente de problemas de rendimiento en entornos de Kubernetes. Si los requests son demasiado altos, el scheduler puede dejar nodos subutilizados, lo que se traduce en recursos desaprovechados y mayores costos de infraestructura. Por el contrario, requests demasiado bajos pueden hacer que las aplicaciones compitan por CPU y memoria, aumentando la probabilidad de throttling y de errores de out-of-memory (OOM). Este desequilibrio afecta la estabilidad de los workloads y la eficiencia del clúster.

Los límites de recursos también afectan el rendimiento. Cuando los límites son demasiado agresivos, los pods pueden terminarse o sufrir throttling, interrumpiendo la disponibilidad del servicio. Sin límites, los procesos fuera de control pueden consumir todos los recursos disponibles de un nodo y afectar a los workloads vecinos.

Cómo abordarlo: Lograr el equilibrio correcto requiere un análisis continuo de los patrones de uso y el ajuste de los requests y limits a medida que evolucionan los workloads.

2. CPU Throttling

El CPU throttling ocurre cuando un contenedor intenta usar más CPU que el límite que tiene asignado, lo que hace que Kubernetes restrinja su uso. Esto puede provocar tiempos de respuesta más altos, un throughput degradado de la aplicación y un rendimiento impredecible. El throttling es especialmente problemático para los workloads sensibles a la latencia, donde ralentizaciones breves pueden afectar la experiencia de usuario o la confiabilidad del servicio. El CPU throttling frecuente suele deberse a límites de CPU demasiado bajos respecto a las necesidades del workload.

Cómo abordarlo: Monitorear las métricas de uso de CPU y de throttling ayuda a identificar los contenedores afectados. Resolver el problema suele implicar aplicar right-sizing a los requests y limits de CPU y asegurar que las políticas de autoescalado permitan picos de uso sin introducir throttling innecesario.

3. Presión de memoria y desalojo de pods

La presión de memoria se produce cuando un nodo se queda sin memoria disponible, lo que obliga al scheduler de Kubernetes a desalojar pods para liberar recursos. Esto puede afectar la disponibilidad de las aplicaciones, sobre todo si se terminan servicios críticos o si los pods desalojados tardan mucho en reiniciarse. La presión de memoria suele deberse a la sobreasignación, al uso ineficiente de memoria por parte de las aplicaciones o a la falta de límites de memoria en ciertos workloads. Los desalojos de pods por presión de memoria pueden generar fallas en cascada si otros nodos también están cerca de su capacidad o si los pods desalojados no pueden programarse en otro lugar.

Cómo abordarlo: El monitoreo continuo del uso de memoria de los nodos, la definición de requests y limits de memoria adecuados y la optimización del consumo de memoria de las aplicaciones ayudan a prevenir desalojos frecuentes y a mantener la estabilidad del clúster.

4. Autoescalado subóptimo

El autoescalado es una funcionalidad central de Kubernetes, pero una mala configuración puede llevar a un aprovisionamiento insuficiente o excesivo de recursos. Si los umbrales de escalado son demasiado conservadores, los workloads pueden no escalar con la rapidez necesaria durante los picos de demanda, generando cuellos de botella de rendimiento. Un escalado agresivo puede provocar rotación innecesaria de pods, contención de recursos y mayores costos de infraestructura.

El autoescalado subóptimo suele originarse en métricas imprecisas o insuficientes para las decisiones de escalado. Basarse solo en CPU o memoria puede no reflejar la demanda real del workload, en especial para aplicaciones sensibles a la E/S o a la latencia.

Cómo abordarlo: Ajustar la configuración del autoscaler y usar métricas personalizadas que reflejen el rendimiento de la aplicación es necesario para lograr un escalado efectivo y un comportamiento consistente de los workloads.

5. Probes en cascada

Kubernetes usa probes de readiness y liveness para determinar la salud de los pods, pero unas probes mal diseñadas pueden crear problemas de rendimiento. Si son demasiado frecuentes, pueden saturar la aplicación con solicitudes, aumentando la latencia y el consumo de recursos. En algunos casos, las fallas de las probes pueden disparar reinicios innecesarios, lo que genera inestabilidad del servicio y tiempos de recuperación más largos.

Las fallas de probes pueden agravar los problemas durante eventos de estrés del clúster, como fallas de nodos o rolling updates. Si varios pods fallan sus health checks al mismo tiempo, se pueden producir reinicios masivos y degradar el rendimiento del clúster.

Cómo abordarlo: Se requiere un ajuste cuidadoso de los intervalos, timeouts y umbrales de las probes para evitar estos efectos y asegurar que cumplan su propósito.

6. Cuellos de botella de almacenamiento

El rendimiento del almacenamiento es un cuello de botella común en los clústeres de Kubernetes, en especial para los workloads con estado. Volúmenes persistentes lentos, alta latencia de disco o IOPS limitadas pueden provocar aplicaciones más lentas, mayores tiempos de arranque de pods y, en el peor de los casos, pérdida de datos. Los cuellos de botella de almacenamiento suelen originarse en backends de almacenamiento con aprovisionamiento insuficiente o en patrones de acceso a datos ineficientes.

Cómo abordarlo: Se requiere monitorear las métricas de E/S de almacenamiento y seleccionar las storage classes adecuadas para prevenir cuellos de botella. Los workloads con requisitos de alto throughput o baja latencia deben usar soluciones de almacenamiento acordes a sus necesidades. Revisar el rendimiento del almacenamiento, ajustar los patrones de acceso de las aplicaciones y escalar los recursos de almacenamiento a medida que crece la demanda ayuda a mantener la capacidad de respuesta del clúster y la integridad de los datos.

---

Métricas críticas de rendimiento de Kubernetes

Uso de CPU

El uso de CPU es una métrica clave de rendimiento en Kubernetes porque muestra cuánta capacidad de procesamiento consumen los workloads y los nodos. Un uso alto de CPU puede indicar una carga elevada, mientras que un uso consistentemente bajo puede sugerir sobreaprovisionamiento y una asignación ineficiente de recursos. Al seguir las tendencias de utilización de CPU a lo largo del tiempo, los equipos pueden aplicar right-sizing a los workloads, mejorar la eficiencia del scheduling y configurar políticas de autoescalado que respondan a la demanda.

Por qué son importantes las métricas de CPU:

• Monitorear el uso de CPU a nivel de pod, contenedor y nodo ayuda a determinar si los workloads cuentan con suficiente capacidad de cómputo para operar de forma confiable.
• Las métricas de CPU también son importantes para identificar throttling y afinar los requests y limits de recursos.
• Si los contenedores alcanzan con frecuencia sus límites de CPU, los tiempos de respuesta de la aplicación pueden aumentar y el throughput puede disminuir.

Uso de memoria

El uso de memoria mide cuánta RAM consumen los contenedores, pods y nodos dentro de un clúster de Kubernetes. Como la memoria es un recurso no comprimible, un uso excesivo puede provocar inestabilidad, incluidos errores de out-of-memory y desalojos de pods.

Por qué son importantes las métricas de uso de memoria:

• Monitorear el uso de memoria ayuda a identificar workloads con fugas de memoria, que consumen más de lo esperado o que operan demasiado cerca de sus límites configurados.
• Dar seguimiento al uso de memoria es fundamental para definir requests y limits precisos. Si los requests de memoria son demasiado bajos, los pods pueden ubicarse en nodos que no pueden sostenerlos durante los picos de demanda.
• Si los límites son demasiado restrictivos, las aplicaciones pueden terminarse de forma inesperada.

Reinicios de pods

Los reinicios de pods indican con qué frecuencia se reinician los contenedores dentro de los pods, lo que puede señalar problemas de aplicación o de infraestructura. Los reinicios frecuentes pueden deberse a fallas de la aplicación, health checks fallidos, límites de memoria excedidos, errores de configuración o fallas en dependencias. Un conteo alto de reinicios puede reducir la disponibilidad e indicar problemas de confiabilidad en el workload.

Por qué son importantes los reinicios de pods:

• Monitorear los reinicios de pods ayuda a detectar aplicaciones inestables antes de que causen interrupciones del servicio.
• Los patrones de reinicio deben revisarse junto con los logs, el uso de recursos y los resultados de las probes para determinar la causa raíz.
• Reducir los reinicios innecesarios mejora la confiabilidad de las aplicaciones, acorta los tiempos de recuperación y favorece un rendimiento predecible de Kubernetes.

Estado y disponibilidad de los pods

Las métricas de estado y disponibilidad de los pods muestran si los workloads se ejecutan como se espera y si está disponible el número deseado de pods para atender el tráfico. Los estados importantes incluyen Running, Pending, Failed, CrashLoopBackOff e ImagePullBackOff. Los pods atascados en estados no operativos pueden indicar problemas de scheduling, problemas con las imágenes, escasez de recursos o errores de configuración.

Por qué son importantes las métricas de pods:

• Las métricas de disponibilidad son importantes para los workloads en producción porque reflejan si las aplicaciones pueden satisfacer la demanda de los usuarios.
• Monitorear los pods listos y disponibles ayuda a detectar degradación del servicio, despliegues fallidos y problemas de capacidad.
• Mantener una alta disponibilidad de pods asegura que las aplicaciones sigan respondiendo durante eventos de escalado, despliegues y fallas de nodos.

Métricas de presión en los nodos

Las métricas de presión en los nodos indican si un nodo de Kubernetes está sufriendo estrés de recursos. Las condiciones de presión comunes incluyen la presión de memoria, la presión de disco y la presión de PID. Cuando un nodo entra en un estado de presión, Kubernetes puede desalojar pods o impedir que se programen nuevos pods en ese nodo, lo que puede afectar la disponibilidad de las aplicaciones y la estabilidad del clúster.

Por qué son importantes las métricas de nodos:

• Monitorear la presión en los nodos ayuda a identificar cuellos de botella de infraestructura antes de que causen interrupciones.
• Estas métricas deben revisarse junto con los datos de CPU, memoria, disco y densidad de pods para entender por qué un nodo está bajo estrés.
• Abordar la presión en los nodos mediante la planificación de capacidad, la redistribución de workloads y el ajuste de recursos ayuda a mantener un clúster estable.

E/S de disco y almacenamiento

Las métricas de E/S de disco y almacenamiento miden con qué eficiencia los workloads de Kubernetes leen y escriben en los sistemas de almacenamiento. Estas métricas incluyen el throughput de disco, las IOPS, la latencia y la utilización de volúmenes. Un rendimiento de almacenamiento deficiente puede ralentizar los tiempos de respuesta de las aplicaciones, demorar el arranque de los pods y afectar workloads con estado como bases de datos, colas de mensajes y sistemas de analítica.

Por qué son importantes las métricas de E/S:

• Monitorear la E/S de almacenamiento es necesario para detectar cuellos de botella en los volúmenes persistentes, las storage classes y la infraestructura subyacente.
• Una latencia alta o IOPS saturadas pueden indicar que un workload necesita almacenamiento más rápido, mejores patrones de acceso a datos o capacidad adicional.
• Un buen rendimiento de almacenamiento ayuda a que las aplicaciones sigan respondiendo y a que los servicios con estado operen de manera confiable.

Rendimiento del scheduler

El rendimiento del scheduler mide con qué rapidez y eficacia el scheduler de Kubernetes asigna pods a los nodos. Los indicadores clave incluyen la latencia de scheduling de los pods, el número de pods pendientes y las fallas de scheduling. Un scheduling lento puede demorar el arranque de las aplicaciones, reducir la capacidad de respuesta del escalado y crear problemas de disponibilidad del servicio durante picos de tráfico o eventos de recuperación.

Por qué son importantes las métricas del scheduler:

• Monitorear el rendimiento del scheduler ayuda a identificar problemas como capacidad insuficiente del clúster, reglas de afinidad restrictivas, taints y tolerations, o requests de recursos que no pueden satisfacerse.
• Un scheduling eficiente asegura que los workloads se ubiquen rápidamente en los nodos apropiados y que los recursos del clúster se usen de forma efectiva.
• Esto es especialmente importante en entornos grandes o dinámicos donde los pods se crean, actualizan o reprograman con frecuencia.

Métricas de autoescalado

Las métricas de autoescalado muestran con qué eficacia Kubernetes ajusta la capacidad de los workloads y del clúster según la demanda. Estas métricas pueden incluir la actividad del horizontal pod autoscaler, el número de réplicas actuales frente a las deseadas, la utilización de CPU o memoria, métricas personalizadas de la aplicación y el comportamiento del cluster autoscaler. Un autoescalado adecuado ayuda a que las aplicaciones manejen los picos de demanda sin intervención manual.

Por qué son importantes las métricas de autoescalado:

• Monitorear estas métricas ayuda a determinar si las políticas de escalado son demasiado lentas, demasiado agresivas o se basan en señales incompletas.
• Si el autoescalado no responde con suficiente rapidez, los usuarios pueden experimentar latencia o errores. Si escala de forma demasiado agresiva, pueden aumentar los costos y la rotación de pods.
• Un autoescalado bien afinado favorece un rendimiento confiable y un uso eficiente de los recursos.

Métricas de aplicación

Las métricas de aplicación proporcionan visibilidad específica de cada workload sobre cómo se comportan los servicios desde una perspectiva de negocio y de usuario. Pueden incluir la latencia de las solicitudes, las tasas de error, el throughput, la profundidad de las colas, el volumen de transacciones e indicadores de salud propios de cada servicio. Mientras que las métricas de infraestructura muestran cómo se usan los recursos de Kubernetes, las métricas de aplicación revelan si la aplicación cumple las expectativas de rendimiento.

Por qué son importantes las métricas de aplicación:

• Monitorear estas métricas conecta el rendimiento de Kubernetes con la experiencia de usuario y los objetivos de nivel de servicio. Por ejemplo, el uso de CPU y memoria puede parecer normal mientras la latencia de las solicitudes o las tasas de error van en aumento.
• Al combinar las métricas de aplicación con las métricas de infraestructura de Kubernetes, los equipos pueden diagnosticar problemas con mayor precisión y priorizar las optimizaciones que mejoran la calidad del servicio.

Métricas del plano de control

Las métricas del plano de control miden la salud y la capacidad de respuesta de los componentes de Kubernetes responsables de gestionar el clúster. Estos componentes incluyen el servidor de API, el scheduler, el controller manager y etcd. Las métricas importantes incluyen la latencia del servidor de API, las tasas de solicitudes, el rendimiento de etcd, la profundidad de las colas de los controladores y las tasas de error del plano de control.

Por qué son importantes las métricas del plano de control:

• Un plano de control con bajo rendimiento puede afectar a todo el clúster, causando demoras en el scheduling, el escalado, los despliegues y la recuperación ante fallas.
• Monitorear las métricas del plano de control ayuda a detectar problemas como la saturación de la API, escrituras lentas en etcd o acumulación de trabajo en los controladores.
• Mantener un plano de control saludable asegura que Kubernetes pueda responder rápidamente a los cambios en los workloads y que el clúster opere de manera confiable.

---