Cómo Netflix simplificó el procesamiento por lotes con Kueue

Por Alvin Bao, Alex Petrov, Jennifer Lai, Aidan Sherr y Samartha Chandrashekar Como parte del proceso de transición de la infraestructura de computación de Netflix para que sea más nativa de Kubernetes, hemos incorporado componentes del ecosistema de Kubernetes en nuestra plataforma de contenedores Titus. Un ejemplo de esto es nuestro uso de Kueue, un sistema de colas de trabajos nativo de la nube para cargas de trabajo por lotes, que ha reemplazado en gran medida la lógica de encolado y planificación personalizada en nuestra solución de lotes gestionada hecha en casa, Compute Managed Batch (CMB). En esta publicación, daremos un resumen de lo que motivó la migración, cómo migramos millones de trabajos por lotes para utilizar Kueue y qué nos permite ofrecer Kueue como plataforma de computación. Breve descripción de CMB y Titus CMB es una solución de lotes gestionada que permite a los usuarios y aplicaciones ejecutar y gestionar cargas de trabajo que se completan. Utilizando una jerarquía de inquilinos, las cargas de trabajo se gestionan y se encolan con ejecución ordenada a través de prioridades, y la capacidad se gestiona de manera individual por inquilino. Las cargas de trabajo que se envían a CMB se ejecutan en Titus. Las características de Titus relevantes para CMB son la federación de cargas de trabajo a través de múltiples celdas (clusters de Kubernetes) y las reservas de capacidad federadas. Esto significa que CMB puede comunicarse con un único punto final de Titus para obtener/enviar cargas de trabajo y actualizar reservas de capacidad sin preocuparse por la topología de celdas/clusters subyacente. Jerarquía de inquilinos de CMB Los inquilinos proporcionan un mecanismo de agrupación para los trabajos enviados en nombre de ciertas organizaciones, plataformas o aplicaciones. Los usuarios pueden crear y organizar inquilinos de la manera que mejor se adapte a su organización o caso de uso. Por ejemplo, una organización puede utilizar un único inquilino en varias aplicaciones o una estructura jerárquica compleja que coincida con su equipo y estructura de propiedad de aplicaciones. Los inquilinos están asociados con una configuración de capacidad. La configuración de capacidad define la cantidad de capacidad computacional disponible para el inquilino y proporciona ciertas garantías sobre el aislamiento respecto a otros inquilinos. La configuración de capacidad contiene peso (utilizado para el uso equitativo) y dimensiones de recursos. Hay dos tipos de inquilinos en CMB: Inquilinos Internos: destinados a facilitar la creación de un árbol de inquilinos. Los hijos de los inquilinos internos pueden ser tanto inquilinos internos como inquilinos hoja. Los inquilinos internos en sí no aceptan trabajo y, por lo tanto, no tienen colas asociadas. Inquilinos Hoja: pueden aceptar trabajo y tienen colas asociadas. Los inquilinos hoja no pueden tener hijos. En lo que respecta a la configuración de capacidad, los inquilinos pueden utilizar 2 tipos de capacidad: Capacidad Reservada Para los inquilinos internos, si un usuario especifica capacidad reservada, esta se comparte equitativamente a través del subárbol y es utilizable por los inquilinos hoja bajo ese inquilino interno. Para los inquilinos hoja, si un usuario especifica capacidad reservada, se divide la capacidad dentro de la jerarquía para que otros inquilinos no puedan reservar los mismos recursos. Esos recursos reservados no se comparten con ningún otro inquilino, asegurando el rendimiento para un inquilino hoja determinado. Capacidad Compartida El equipo de Computación mantiene un fondo global de capacidad compartida en el que cualquier inquilino puede utilizar, además de su capacidad reservada. No se requieren reservas para utilizar CMB, por lo que un inquilino puede quedarse sin capacidad compartida por completo. El fondo se comparte equitativamente entre inquilinos, pero en CMB, esto se aplicaba solo al ingreso: CMB no tenía prevención, por lo que una vez que un trabajo era admitido, se ejecutaba hasta su finalización independientemente de los cambios en la demanda de uso equitativo. Kueue cambia la semántica para ambos tipos de capacidad, lo que se cubre en la sección de uso equitativo y prevención. Aquí hay un ejemplo de cómo se ve una jerarquía de inquilinos: Flujo de envío de carga de trabajo de usuario/aplicación de CMB Flujo de gestión de inquilinos de usuario/aplicación de CMB ¿Por qué Kueue? CMB se creó en 2018, antes o junto con muchas de las ofertas de computación por lotes de código abierto disponibles hoy en día. A lo largo de los años, a medida que el ecosistema de Kubernetes ha evolucionado, muchas de las características que CMB ofrecía o buscaba ofrecer se han incluido en estos proyectos de código abierto, por ejemplo, uso equitativo, inquilinos jerárquicos, gestión de capacidad, encolado por prioridad. Además, se volvió cada vez más complicado desarrollar nuevas funciones como la prevención cuando CMB estaba tan alejado del cluster de Kubernetes subyacente. El equipo examinó lo que se necesitaría para modernizar nuestra abstracción de lotes y se decidió por Kueue por las siguientes razones: A diferencia de otras opciones como YuniKorn o Volcano, Kueue no reemplaza la programación de pods por el kube-scheduler, lo que permite la integración con los perfiles de programación existentes de Titus. Reemplazar los perfiles del programador de Titus puede fragmentar la colocación de trabajos, lo que potencialmente perjudica la eficiencia. Momentum de adopción y ritmo de innovación. Kueue admite gestión de cuotas multi-inquilino sobre hardware heterogéneo. Kueue puede operar sobre primitivas como v1.Pod y batch/v1.Job, y también admite abstracciones de nivel superior como RayJob / RayCluster para una futura extensibilidad. Kueue tiene características nativas que el equipo hubiera querido implementar en CMB, como la prevención, la programación de todo o nada, y la programación consciente de la topología. Migración a Kueue Esta iniciativa de migrar las cargas de trabajo de CMB a Kueue se conoció como Netflix Batch. Los principios clave de nuestra migración fueron los siguientes: La migración no debe requerir esfuerzo alguno para los usuarios finales de CMB y ser completamente transparente para ellos No debe haber regresiones en la tasa de lanzamiento de contenedores y en el rendimiento máximo total Reemplazar el encolado y la programación de CMB por Kueue Flujo de envío de carga de trabajo de usuario/aplicación de Netflix Batch La diferencia clave entre los flujos antiguos y nuevos es que delegamos el encolado y la programación a Kueue, que está habilitado en cada celda de Titus habilitada para Kueue. La federación de Titus dirige el trabajo a las celdas de Kueue utilizando nuestro enrutador Kueue personalizado. Flujo de gestión de inquilinos de usuario/aplicación de Netflix Batch Para nosotros como operadores, la migración fue tan simple como hacer clic en un botón en un inquilino en nuestra interfaz de usuario (como se muestra en el ejemplo anterior). Esto también nos permite revertir fácilmente los cambios si hay problemas. En segundo plano, esta inscripción convierte a los inquilinos internos en Cohortes y a los inquilinos hoja en un ClusterQueue + LocalQueue. La configuración de capacidad en un inquilino dado se convierte en sabores de recursos y cuotas nominales. La arquitectura para esto se ve así: Lecciones Aprendidas Mantener paridad de API con el sistema existente (en lugar de exponer una nueva superficie de API) y migrar los componentes subyacentes como primer paso disminuyó el riesgo del proyecto al desacoplar apuestas y también garantizó que no interrumpiéramos la experiencia del cliente. No esperes hasta el final para migrar el caso de uso más complejo. Decidimos desde el principio migrar a nuestro cliente más grande y complejo primero. Esto nos permitió construir confianza en que podríamos migrar posteriormente a otros clientes a Netflix Batch sin complicaciones, y resultó en que la migración a producción duró solo 4 semanas. Tuvimos que ejecutar Kueue con QPS, Burst y groupKindConcurrency mucho más altos que la configuración predeterminada para satisfacer nuestras necesidades de rendimiento. Esto se redujo tempranamente al realizar pruebas de carga en un entorno de desarrollo que imita a Titus. Estado Actual de Kueue en Netflix Kueue está completamente desplegado en producción, gestionando millones de cargas de trabajo por lotes. En el futuro, estamos considerando opciones para inscribir más cargas de trabajo por lotes de Titus en esta experiencia más gestionada. También hemos producido más uso equitativo y prevenciones para mejorar la utilización de la capacidad reservada. Además, nuestras enseñanzas están siendo aprovechadas por otros equipos internos, incluidos aquellos que construyen infraestructura de entrenamiento nativa de Kubernetes, para informar sobre sus configuraciones de programación y encolado de trabajos. Uso Equitativo y Prevención Con Kueue, el Uso Equitativo Basado en Prevención permite a Netflix Batch mantener la semántica de reservas mientras presta recursos a otros inquilinos cuando esas reservas no están en uso. Además, la prevención permite a Netflix Batch interrumpir cargas de trabajo de menor prioridad para cargas de trabajo de mayor prioridad. Para nuestros clientes, esto significa que los inquilinos pueden utilizar más capacidad inactiva de reservas, enviar más trabajos sin el riesgo de escasez y tener tiempos de respuesta más rápidos para cargas de trabajo críticas para el negocio. Un ejemplo de configuración de prevención en un ClusterQueue que estaríamos utilizando es el siguiente:apiVersion: kueue.x-k8s.io/v1beta2 kind: ClusterQueue metadata: name: "team-a-cq" spec: preemption: reclaimWithinCohort: Any withinClusterQueue: LowerPriority Con estas características implementadas, el equipo de Computación ha visto un aumento significativo en la utilización promedio de recursos. Reconocimiento Este trabajo no habría sido posible sin el gran trabajo de todo el equipo de Computación en Netflix. Cómo Netflix Simplificó la Computación por Lotes con Kueue fue publicado originalmente en Netflix TechBlog en Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.