Cuando se ejecuta un contenedor de spring-boot en Kubernetes, la cantidad activa de procesadores se establece con la CPU del host, no con el límite de CPU de k8s para el contenedor.
Ejecutamos contenedores spring-boot creados utilizando la tarea bootBuildImage de Gradle en Kubernetes.
Proporcionamos límites de CPU y memoria a los pods al iniciar en k8s.
Utilizamos:
- Versión de spring-boot 2.6.2
- Imagen de Docker construida con la tarea bootBuildImage del plugin spring-boot de Gradle
- spring-boot-admin para administrar nuestras implementaciones basadas en spring-boot
- JDK 11 (para habilitar blockhound)
- Hosts de GCP GKE con 32 CPUs
- En desarrollo, limitamos nuestro contenedor a 1 CPU y 1 GB de memoria
Hemos observado que todos nuestros contenedores basados en spring-boot se provisionan (es decir, número de hilos) como si se estuvieran ejecutando en instancias con 32 CPUs.
Los registros de inicio de Docker muestran:
Estableciendo el recuento activo de procesadores en 32
[…]
Recogiendo JAVA_TOOL_OPTIONS: […] -XX:ActiveProcessorCount=32
En spring-boot-admin, vemos que los servidores web (netty para reactivos, undertow para servlets) se provisionan con grupos de hilos como si la aplicación se estuviera ejecutando en un contenedor con 32 CPUs asignadas, incluso si el contenedor se limitó a 1 CPU por k8s. Sin embargo, la memoria asignada a la JVM es correcta.
¿Cómo podemos asegurarnos de que el recuento activo de CPU refleje la limitación de CPU de k8s?
Gracias de antemano.
davy.ai
Para asegurarse de que la cantidad de CPUs activas refleje la limitación de CPU de k8s, puede configurar la siguiente variable de entorno en su archivo yaml de implementación de Kubernetes:
El comando
nprocdevolverá el número de procesadores en el contenedor actual, que estará limitado por el límite de CPU establecido en la especificación del pod de Kubernetes. Esto permitirá que la JVM configure correctamente la cantidad de procesadores activos y provisione la cantidad apropiada de hilos basada en la cantidad de CPUs disponibles.