Limitación de la CPU de Kubernetes: el asesino silencioso del tiempo de respuesta

Hoy en día, la mayoría de las organizaciones empresariales que ejecutan aplicaciones de misión crítica en Kubernetes lo hacen en entornos multiinquilino. Estos entornos multiinquilino se basan en el establecimiento de límites para regular el consumo de las cargas de trabajo de los arrendatarios o para utilizar límites para las devoluciones de cargo. Algunos desarrolladores optarán por establecer límites de CPU o GPU para las pruebas de referencia de sus aplicaciones.

La aceleración de la CPU, por la que la velocidad de programación de tareas en los núcleos físicos de la CPU disminuye inadvertidamente, lo que a menudo resulta en un aumento no deseado del tiempo de respuesta de la aplicación, es la consecuencia no deseada de este diseño. Eche un vistazo a este ejemplo:

En la figura anterior, el uso de CPU de un contenedor es solo del 25 %, lo que lo convierte en un candidato natural para reducir el tamaño:

Pero después de reducir el tamaño del contenedor (el uso de CPU del contenedor ahora es del 50 %, aún no es alto), el tiempo de respuesta se cuadruplicó.

Entonces, ¿qué está pasando aquí? La limitación de la CPU se produce cuando se configura un límite de CPU en un contenedor, lo que puede ralentizar de forma inversa el tiempo de respuesta de la aplicación y provocar un problema de limitación. Incluso si tiene recursos más que suficientes en su nodo subyacente, la carga de trabajo de su contenedor seguirá estando limitada porque no se configuró correctamente. Además, el impacto en el rendimiento de la regulación puede variar en función del procesador físico subyacente (Intel vs. AMD vs. NVIDIA). Los altos tiempos de respuesta están directamente relacionados con los períodos de alta limitación de la CPU, y así es exactamente como se diseñó Kubernetes para funcionar.

Para darle un poco de color a esto, imagine que establece un límite de CPU de 200 ms y ese límite se traduce en una cuota de grupo en el sistema Linux subyacente. El contenedor solo puede utilizar 20 ms de CPU a la vez (lo que se denomina segmento de tiempo de CPU) porque el período de aplicación predeterminado es de solo 100 ms. Si su tarea dura más de 20 ms, se le limitará y tardará 4 veces más en completar la tarea.

En función de este comportamiento, el rendimiento de la aplicación se verá afectado debido al aumento del tiempo de respuesta causado por la limitación y comenzará la resolución de problemas para intentar encontrar el problema.

Si está ejecutando una implementación pequeña, es posible que pueda solucionar manualmente los problemas de limitación.

En primer lugar, identificaría el pod afectado utilizando herramientas como kubectl. A continuación, revise las solicitudes y límites de recursos del pod para asegurarse de que están configurados correctamente. Compruebe si hay procesos que consumen muchos recursos en ejecución dentro del contenedor que puedan estar causando la limitación y analicen la utilización y los límites de la CPU.

Si la limitación de la CPU persiste, considere el escalado automático horizontal de pods para distribuir la carga de trabajo en más pods, o ajuste los recursos del nodo del clúster para satisfacer las demandas. Monitorice y afine continuamente la configuración de recursos para optimizar el rendimiento y evitar más problemas de limitación.

En una implementación más grande, es poco probable que este enfoque se escale o persista a medida que se añaden más pods.

La limitación de la CPU es una métrica clave de rendimiento de la aplicación debido a la correlación directa entre el tiempo de respuesta y la limitación de la CPU. Esta es una gran noticia para usted, ya que puede obtener esta métrica directamente de Kubernetes y OpenShift.

Para asegurarse de que los tiempos de respuesta de la aplicación permanezcan bajos, la CPU no se limite y continúe teniendo una aplicación de alto rendimiento, debe entender que cuando se produce la limitación de la CPU, no puede confiar únicamente en la utilización de su núcleo. Debe tener en cuenta todas las dependencias de recursos y análisis que afectan al rendimiento de la aplicación. IBM Turbonomic ha incorporado estas consideraciones en su plataforma de análisis.

Al determinar las acciones de redimensionamiento de contenedores, Turbonomic analiza continuamente cuatro dimensiones:

1. Límites de CPU
2. Solicitudes de CPU
3. Límites de memoria
4. Solicitudes de memoria

Turbonomic puede determinar los límites de CPU que mitigarán el riesgo de estrangulamiento y permitirán que sus aplicaciones funcionen sin trabas. Todo ello gracias a la potencia de añadir la aceleración de la CPU como una dimensión para que la plataforma analice y gestione las compensaciones que aparecen. La adición de la dimensión de la aceleración de la CPU garantizará tiempos de respuesta bajos de las aplicaciones.

Además, Turbonomic está generando acciones para mover sus pods y escalar sus clústeres; como todos sabemos, es un desafío full stack. Los clientes pueden consultar los KPI y preguntar: "¿Qué servicio se está viendo limitado?". También les permite comprender el historial de aceleración de la CPU para cada servicio y recordar que cada servicio está directamente correlacionado con el tiempo de respuesta de la aplicación, proporcionando a los usuarios ventanas valiosas en el rendimiento de su sistema.

En el contexto de Kubernetes, uno de los principales beneficios de Turbonomic es su capacidad para identificar y remediar rápidamente las consecuencias no deseadas de una estrategia de plataforma en lugar de que el cliente rediseñe su estrategia de plataforma multiinquilino. Turbonomic no solo puede monitorizar las métricas de estrangulamiento de la CPU, sino que la plataforma también puede ajustar automáticamente el tamaño de su límite de CPU y reducir el estrangulamiento a un nivel manejable.

IBM Turbonomic puede ayudarle a optimizar simultáneamente su gasto y rendimiento en la nube. Puede automatizar continuamente las acciones de optimización en tiempo real, sin intervención humana, que ofrecen de forma proactiva el uso más eficiente de los recursos informáticos, de memoria, almacenamiento y red a sus aplicaciones en cada capa de la pila.