Gestión y programación de CPU de Kubernetes
Entonces, ¿qué significa CPU en Kubernetes? La CPU equivale a un núcleo de CPU proporcionado por el sistema operativo del nodo.
A diferencia de la memoria, la CPU es comprimible en Kubernetes, lo que significa que se puede limitar. Cuando especifica un límite de CPU para un contenedor, en realidad está limitando el tiempo de CPU del contenedor en el nodo, en lugar de establecer la afinidad del contenedor para una CPU o un conjunto de CPU específicos. Esto significa que incluso si especifica un límite que es menor que el número total de CPU en un nodo, su contenedor seguirá viendo (y usando) todas las CPU en ese nodo, solo estará limitado en cuánto tiempo puede usar su contenedor. la CPU.
Por ejemplo, especificar un límite de 4 CPU para un contenedor en un nodo con 8 núcleos de CPU también significa que el contenedor solo puede usar el equivalente a tiempo completo de 4 núcleos de CPU, pero se puede distribuir entre todas las CPU de el núcleo. Para un único contenedor que se ejecuta en un nodo dedicado, en este caso la utilización máxima permitida de todos los núcleos de CPU en ese nodo es del 50 %.
Entonces, ¿en qué tipo de control se traduce esta limitación de Kuberne en Docker? K8s implementa la aceleración de la CPU en Kubernetes pasando las opciones cpu-period y cpu-quota. cpu-period siempre se establece en 100000μs (100ms), lo que representa el período de tiempo durante el cual se realiza el seguimiento de la utilización de la CPU del contenedor. Ambas configuraciones controlan el Programador Completamente Justo (CFS) del kernel. Así es como los diferentes límites de CPU de K8 se traducen en las configuraciones de Docker:
límites ?1:?cpu-quota=100000
límites ?4:?cpu-quota=400000
límites ?0.5:?cpu-quota=50000
límites ?1 significa que el tiempo total de CPU permitido para usarse cada 100 milisegundos equivale al 100% del tiempo de CPU de un núcleo de CPU, mientras que los límites ?4 significan que el tiempo total de CPU permitido por 100 milisegundos equivale al 400% del tiempo de CPU de un núcleo de CPU (o al 100% del tiempo de CPU de cuatro núcleos de CPU). No olvide que este tiempo de CPU se distribuye entre todos los núcleos de la CPU. Debido a la forma en que funcionan las cuotas de CFS, cualquier contenedor que exceda la cuota en un período de tiempo determinado no podrá ejecutarse nuevamente hasta el siguiente período de tiempo, lo que significa que su programa se sentirá inexplicablemente suspendido, especialmente si su programa está configurado vinculado a la CPU. y muy sensible a la latencia.
Puede especificar cuánta CPU (o fracción de CPU) requiere un pod especificando la solicitud del pod. Kubernetes no permite que las solicitudes de un nodo superen la cantidad de núcleos de CPU que tiene el nodo en el momento de la solicitud especificada (la suma de las solicitudes de todas las CPU del pod que pertenecen a un nodo determinado). Puede establecer el número total de solicitudes según el número de núcleos de CPU del nodo, pero ¿qué sucede si la carga de trabajo en el nodo es demasiado alta, como si la utilización de la CPU alcanza o supera el 100%? En este caso, la prioridad de programación de la CPU del contenedor está determinada por el valor de "solicitudes" del Pod, que se multiplica por 1024 y se pasa a Docker como la opción cpu-shares. cpu-shares es en realidad un peso; si todos los contenedores que se ejecutan en un nodo tienen el mismo peso, entonces, en caso de carga excesiva (sin CPU libre), no es necesario establecer el número de solicitudes en el número de núcleos de CPU del nodo. nodo.
Si un contenedor tiene un peso mayor que otros contenedores, tendrá una prioridad de programación de CPU más alta y, en caso de sobrecarga, obtendrá más tiempo de CPU que otros contenedores.
En el capítulo de memoria, la configuración QoS ampliable significa que cuando otros contenedores no usan la CPU, su contenedor usará tiempo de CPU inactivo, posiblemente más tiempo de CPU del solicitado. Esto puede conducir a un uso más eficiente de los recursos subyacentes, pero introduce más imprevisibilidad; por ejemplo, la latencia de respuesta de una aplicación que depende más de la CPU puede verse afectada temporalmente por otros contenedores en el mismo nodo. En el peor de los casos, demasiados contenedores explotables en un solo nodo provocarán una carga de CPU muy alta, lo que se afectará negativamente entre sí.
Si es nuevo en K8, es una buena idea asegurarse de que su pod sea un tipo de contenedor garantizado estableciendo los valores de solicitud y límite en los mismos. A medida que aprenda más sobre las características de la utilización de recursos de CPU, es posible que descubra que hay un exceso de recursos de CPU y que desee considerar la introducción de contenedores Burstable para obtener más beneficios o incluso aumentar la utilización general de la CPU.
¿Cuánta CPU deberías asignar a un contenedor? No existe ninguna respuesta estándar para esto, depende de las características del grupo de la aplicación, el rendimiento aceptable, la estrategia de programación del pod, el tipo de host y el costo, etc.
Sin embargo, si conoces bien tu aplicación, puedes probar diferentes configuraciones en un entorno de prueba de rendimiento o incluso en un entorno de producción. Con el tiempo, encontrará un equilibrio entre rendimiento y costo, pero el consumo de tiempo del contenedor tiene un impacto significativo en las aplicaciones con uso intensivo de CPU que se ejecutan en Linux. Por lo general, puede usar Prometheus para ver información relacionada con la CPU, o puede ingresar directamente al contenedor para ver las estadísticas de CPU de cgroup:
cat /sys/fs/cgroup/cpu,cpuacct/cpu.stat
Este archivo contiene un total de cuántos planes de CPU se ejecutaron. El número total de veces que se ha acelerado el contenedor y el tiempo de aceleración acumulado en nanosegundos.
Referencia: /expedia-group-tech/kubernetes-container-resource-requirements-part-2-cpu-83ca227a18b1
Referencia