Escalado de nodos de Kubernetes cuando los nodos tienen pocos recursos
De la documentación se desprende claramente que cada vez que los pods están en estado Pendiente porque no hay un nodo que tenga suficientes recursos libres para respetar la solicitud de recursos de los pods, el escalador automático del clúster creará otro nodo dentro de los 30 segundos posteriores a la creación del pod (para clústeres de tamaño razonable). .
Sin embargo, considere el caso de que un nodo esté bastante lleno. Digamos que el nodo tiene 2 núcleos de CPU y contiene 4 pods que definen una solicitud de CPU de 0,5 y un límite de CPU de 1,0. De repente, hay carga, y los 4 pods solicitan repentinamente 0,5 CPU adicionales que el nodo no puede proporcionar porque los 4 pods en ejecución ya han tomado toda su CPU.
En esta situación, esperaría que Kubernetes "entienda" que hay solicitudes de recursos pendientes mediante la ejecución de pods que no se pueden atender y "mueva" (destruya y cree) esos pods a otro nodo que pueda respetar su solicitud (más los recursos que están usando actualmente). En caso de que no exista tal nodo, esperaba que Kubernetes creara un nodo adicional y moviera los pods allí.
Sin embargo, no veo que esto suceda. Veo que los pods se ejecutan en el mismo nodo (supongo que ese nodo se puede llamar aprovisionado en exceso) independientemente de las solicitudes de recursos que no se pueden respetar y, como resultado, el rendimiento se ve afectado.
Mi pregunta es si este comportamiento se puede evitar de alguna manera aparte de establecer la relación entre las solicitudes de recursos del pod y los límites en 1:1 (donde un pod no puede solicitar más recursos de los asignados inicialmente). Obviamente, evitaría establecer solicitudes y límites iguales para evitar el aprovisionamiento insuficiente y pagar más de lo que necesito.
Respuestas
Es importante reconocer la distinción aquí entre la CPU requesten un PodSpec y la cantidad de CPU que un proceso está tratando de usar. El aprovisionamiento de Kubernetes y el ajuste de escala automático del clúster se basan únicamente requesten el PodSpec. El uso real es irrelevante para esas decisiones.
En el caso que está describiendo, el Pod aún solo solicita 0.5 CPU; ese campo es inmutable. El proceso ahora está tratando de usar 1 CPU, pero esto no se analiza.
El hecho de que los límites de la CPU sean más altos que las solicitudes permite el mejor uso de esa capacidad, pero no es una garantía, como está viendo.
En este escenario, parece que querrá usar tanto el escalador automático horizontal de pods como el escalador automático de clústeres. En una situación con mayor carga (donde los pods comienzan a usar >80 % de la CPU request, digamos), HPA aumentará la cantidad de pods para el servicio, para manejar la demanda. Si esos pods no tienen ningún lugar donde puedan caber, el escalador automático del clúster aprovisionará más nodos. De esta manera, sus pods aún pueden usar hasta el valor de la solicitud, y solo cuando comienzan a acercarse a él se aprovisionan más nodos, por lo que no aprovisionará recursos en exceso por adelantado.