Kubernetes v1.32 habilita QueueingHint para optimizar el rendimiento de la programación de pods

En una publicación en el blog de Kubernetes en diciembre de 2024, Kensei Nakada de Tetrate.io detalló una mejora interna significativa en el planificador de Kubernetes introducida en la versión 1.32. Esta actualización estabiliza y habilita por defecto el mecanismo QueueingHint, una función diseñada para reducir la carga de procesamiento innecesaria del planificador mediante una gestión inteligente de los reintentos de pods no programables.

Qué ocurrió

El planificador de Kubernetes es responsable de asignar nuevos Pods a nodos dentro de un clúster. Procesa estos Pods de forma secuencial, lo que significa que a medida que los clústeres crecen, el rendimiento del planificador se convierte en un cuello de botella crítico. Durante varios años, el grupo SIG Scheduling de Kubernetes ha implementado diversas mejoras para aumentar este rendimiento. La última gran mejora, incluida en Kubernetes v1.32, introduce un elemento de contexto de planificación llamado QueueingHint.

Antes de esta versión, el planificador gestionaba los Pods no programados utilizando tres estructuras de datos internas: ActiveQ para Pods nuevos o listos para ser reintentados, BackoffQ para Pods que esperan tras un periodo de backoff después de intentos fallidos, y el Unschedulable Pod Pool (conjunto de pods no programables) para Pods que actualmente no pueden ser programados. Cuando un Pod falla en un ciclo de planificación, normalmente pasa al Unschedulable Pod Pool. El planificador solo mueve estos Pods de vuelta a ActiveQ o BackoffQ si ocurren cambios específicos en el clúster que podrían resolver el fallo de programación.

Previamente, la lógica para determinar qué eventos del clúster podían resolver un fallo era amplia y a menudo ineficiente. Los plugins registraban eventos generales del clúster, como la creación o eliminación de objetos, mediante EnqueueExtensions. Si ocurría cualquier evento registrado, el planificador reintentaba el Pod, incluso si el evento era irrelevante para la razón específica del fallo anterior. Además, una función interna llamada preCheck intentaba filtrar eventos basándose en restricciones principales, pero no era extensible a plugins personalizados y carecía de precisión.

Cómo funciona

QueueingHint perfecciona este mecanismo de reintento permitiendo que cada plugin se suscriba a eventos específicos del clúster y tome una decisión granular sobre si un evento entrante podría hacer realmente que un Pod específico sea programable. En lugar de reintentar ampliamente un Pod cada vez que ocurre cualquier evento registrado, el planificador ahora pregunta al plugin relevante si el cambio específico importa.

Por ejemplo, considere un Pod llamado pod-a que requiere una afinidad de Pod específica. Si el plugin InterPodAffinity rechaza pod-a porque ningún nodo existente tiene un Pod coincidente, pod-a entra en el Unschedulable Pod Pool. El planificador registra que InterPodAffinity causó el rechazo. Con QueueingHint, el plugin InterPodAffinity se suscribe a las actualizaciones de etiquetas de Pod. Si un Pod en ejecución recibe una actualización de etiqueta que ahora coincide con el requisito de afinidad de pod-a, la devolución de llamada QueueingHint del plugin detecta esta coincidencia e insta al planificador a mover pod-a de vuelta a ActiveQ o BackoffQ. Si la actualización de etiqueta no coincide, el Pod permanece en el conjunto, ahorrando un ciclo de planificación.

Esta función ha estado en desarrollo desde Kubernetes v1.28. Inicialmente estaba habilitada por defecto, pero fue deshabilitada en una versión de parche debido a una fuga de memoria reportada. Entre v1.28 y v1.31, los colaboradores corrigieron la fuga de memoria e implementaron QueueingHints en todos los plugins integrados. En v1.32, la función vuelve a estar habilitada por defecto, con la implementación completada y los problemas de estabilidad resueltos.

Detalles clave

• Versión: La función QueueingHint está habilitada por defecto en Kubernetes v1.32.
• Mecanismo: QueueingHint permite a los plugins evaluar eventos específicos del clúster para decidir si se debe reintentar un Pod no programable.
• Problema previo: Los métodos anteriores utilizaban un registro amplio de eventos, lo que llevaba a reintentos de planificación innecesarios para Pods que permanecían no programables.
• Extensibilidad: A diferencia de la antigua función preCheck, QueueingHint es extensible y funciona con plugins personalizados, abordando el problema #110175.
• Historial: La función se introdujo experimentalmente en v1.28, se deshabilitó debido a una fuga de memoria y se estabilizó en versiones posteriores.
• Componente: La optimización apunta a la cola de planificación, específicamente al movimiento de Pods entre el Unschedulable Pod Pool y ActiveQ/BackoffQ.

Por qué es importante

Para los ingenieros que gestionan clústeres de Kubernetes a gran escala, el rendimiento del planificador impacta directamente en la velocidad de despliegue de aplicaciones y la utilización de recursos. Cada vez que el planificador intenta colocar un Pod que no tiene posibilidades de ser programado, consume ciclos de CPU y añade latencia al procesamiento de otros Pods pendientes. Al eliminar estos reintentos inútiles, QueueingHint reduce la sobrecarga computacional en el plano de control.

Esta optimización es particularmente valiosa para clústeres con requisitos de planificación complejos, como aquellos que utilizan reglas extensas de afinidad o anti-afinidad de Pods. En tales entornos, los Pods entran frecuentemente en el Unschedulable Pod Pool. Sin una lógica de reintento precisa, el planificador podría despertar estos Pods repetidamente para cambios irrelevantes del clúster, creando ruido y retrasando la programación de Pods viables. QueueingHint asegura que solo los cambios significativos desencadenen un reintento, manteniendo eficiente el flujo de trabajo de planificación.

Además, la extensibilidad de QueueingHint beneficia a los desarrolladores que escriben plugins de planificación personalizados. Previamente, los plugins personalizados no podían aprovechar el filtrado eficiente proporcionado por preCheck, obligándolos a depender de disparadores de eventos más amplios y menos eficientes. Ahora, los plugins personalizados pueden implementar su propia lógica QueueingHint, asegurando que se integren sin problemas con el mecanismo de reintento optimizado del planificador. Esto conduce a un rendimiento más consistente tanto en flujos de trabajo de planificación estándar como personalizados.

Qué puede hacer

• Actualice sus clústeres de prueba a Kubernetes v1.32 para observar el comportamiento estabilizado de QueueingHint.
• Revise los plugins de planificación personalizados para asegurar que implementen devoluciones de llamada QueueingHint para el manejo preciso de eventos.
• Monitoree las métricas del planificador para detectar tasas de reintento reducidas y mejor rendimiento en escenarios de alta carga.
• Verifique cualquier patrón residual de uso de memoria si previamente experimentó problemas con la implementación experimental de v1.28.
• Consulte la documentación del SIG Scheduling de Kubernetes para obtener orientación detallada sobre la implementación de QueueingHint en plugins personalizados.
• Evalúe el rendimiento del clúster antes y después de la actualización para cuantificar la reducción en ciclos de planificación innecesarios.