Tengo un clúster de GKE Kubernetes y una implementación.
Configuré la estrofa de recursos en la implementación para
resources.requests.memory: 4G
resources.requests.cpu: 2
resources.limits.memory: 4G
el límite de CPU no está establecido
Implemento el pod (una aplicación web de Django) y lo golpeo con una prueba de carga. Cuando está saturado, el uso de CPU del módulo sube a 1 CPU, pero esencialmente se niega a superar 1 CPU.
¿Alguna idea de lo que debería solucionar aquí?
Respuesta1
Dejé esta publicación abierta, así que cerrémosla.
En mi caso específico, el cuello de botella resultó estar aguas arriba del K8S Pod, en la base de datos. La instancia de Postgres simplemente no era lo suficientemente grande y estaba alcanzando un máximo de uso de CPU del 100 % y provocaba tiempos de espera descendentes.
Sospecho, pero no estoy seguro, que la nivelación de la CPU en los Pods se debió simplemente a que los Pods estaban esperando una respuesta del flujo ascendente y no podían realizar aproximadamente 1 uso de CPU porque no tenían nada más que hacer.
Además, las instancias de Django utilizan canales de Django y el modelo asincrónico ASGI, que es de un solo subproceso y no tiene el mismo modelo de "subproceso secundario" que UWSGI; Otra razón, o tal vez la razón real, es que el uso de CPU en el Pod alcanza un máximo de 1 CPU.
Así que estoy bastante seguro de que la forma correcta de ampliar esto es
- Escalar verticalmente Postgres
- Aumentar el número base de Pods
- Reduzca el umbral del escalador automático (HPA) para ampliar y agregar nuevos Pods
EDITAR: información adicional
El problema también tiene que ver con la forma en que está diseñada la aplicación. Estamos intentando utilizar Python asíncrono de Django Channels y ejecutar htat en un contenedor Daphne ASGI; sin embargo, no toda la aplicación es asíncrona y aparentemente eso es malo. Investigué mucho sobre este problema de aplicación asíncrona versus sincronización y los interbloqueos resultantes y, mientras hago que el equipo de desarrollo rediseñe la aplicación, también rediseñé la implementación.
- Agregue un servidor uWSGI a la implementación
- Implementar el código base en dos implementaciones/pods
- Uno tiene el ASGI Pod
- Uno tiene el uWSGI Pod
- Enrute todos los puntos finales ASGI (solo hay uno) al pod ASGI en las reglas de ruta de ingreso
- Enrute todos los puntos finales de uWSGI al pod de sincronización en las reglas de ruta de ingreso
Esto funciona; sin embargo, todavía no he realizado las pruebas de carga completa.