Limitación de 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 inquilinos o en el uso de límites para las devoluciones de cargo. Algunos desarrolladores optarán por establecer límites de CPU o GPU para las pruebas de punto de referencia de sus aplicaciones.

La aceleración de la CPU, por la cual la tasa 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 en el 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 %, todavía no es alto), el tiempo de respuesta se cuadruplicó.

Entonces, ¿qué está pasando aquí? La limitación de CPU se produce cuando configura un límite de CPU en un contenedor, lo que puede ralentizar de forma inversa el tiempo de respuesta de su aplicación y causar 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 limitación puede variar según el 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 usar 20 ms de CPU a la vez (llamado 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 en el tiempo de respuesta causado por la limitación y comenzará la resolución de problemas para intentar encontrar el problema.

Si está ejecutando un despliegue pequeño, es posible que pueda solucionar manualmente los problemas de limitación.

Primero, identificaría el pod afectado mediante herramientas como kubectl. A continuación, revise las solicitudes y límites de recursos del pod para asegurarse de que estén configurados adecuadamente. Verifique si hay procesos que consumen muchos recursos que se ejecutan dentro del contenedor que pueden 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 autoescalado horizontal de pod para distribuir la carga de trabajo en más pod, o ajuste los Recursos de nodo del clúster para satisfacer las demandas. Supervise y ajuste continuamente la configuración de recursos para optimizar el rendimiento y evitar más problemas de limitación.

En un despliegue más grande, es poco probable que este enfoque escalará o persista a medida que agrega más pods.

La limitación de CPU es una métrica clave de rendimiento de las aplicaciones debido a la correlación directa entre el tiempo de respuesta y la limitación de 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 primero que cuando se produce una limitación de la CPU, no puede confiar únicamente en la utilización del núcleo de la CPU. Debe tener en cuenta todas las analytics y dependencias de Recursos que afectan el rendimiento de la aplicación. IBM Turbonomic ha incorporado estas consideraciones en su plataforma de analytics.

Al determinar las acciones de reajustar 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 obstáculos. Todo esto se debe al poder de agregar la limitación de CPU como una dimensión para que la plataforma analice y gestione las compensaciones que aparecen. Agregar la dimensión de la limitación de la CPU garantizará tiempos de respuesta de la aplicación bajos.

Además, Turbonomic está generando acciones para mover sus pods y escalar sus clústeres; como todos sabemos, es un desafío de conjunto. Los clientes tienen la capacidad de ver los KPI y preguntar "¿Cuál de mis servicios se está limitando?" También les permite comprender el historial de limitación de la CPU para cada servicio y recordar que cada servicio está directamente correlacionado con el tiempo de respuesta de la aplicación, lo que proporciona a los usuarios ventanas valiosas para conocer 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 monitorear las métricas de limitación de CPU, sino que la plataforma también puede ajustar automáticamente el tamaño correcto de su límite de CPU y reducir la limitación a un nivel manejable.

IBM Turbonomic puede ayudar 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, de almacenamiento y de red a sus aplicaciones en cada capa de la pila.