[Vista previa de la transmisión en vivo] ¿Los modelos grandes reemplazarán a los programadores? "

Las capacidades de administración de QoS pueden programar uniformemente aplicaciones en línea y fuera de línea, lo que mejora en gran medida la utilización de recursos.

Fuente | Equipo de infraestructura de ByteDance

Código abierto | github.com/kubewharf/godel-scheduler

Este artículo interpreta el artículo " Gödel: programación y gestión unificada de recursos a gran escala en Bytedance " publicado por el equipo de programación y orquestación de infraestructura de Bytedance en SoCC 2023, la principal conferencia internacional de computación en la nube .

Enlace del artículo: dl.acm.org/doi/proceedings/10.1145/3620678

El artículo presenta un sistema de programación de tareas de alto rendimiento basado en Kubernetes propuesto por ByteDance que admite la combinación de tareas en línea y tareas fuera de línea. Su objetivo es resolver eficazmente el problema de asignación de recursos de diferentes tipos de tareas en centros de datos a gran escala y mejorar el. recursos del centro de datos. Utilización, resiliencia y rendimiento de programación.

Actualmente, el sistema de programación admite la gestión de clústeres de gran escala con decenas de miles de nodos y proporciona capacidades de agrupación de recursos para múltiples tipos de tareas, incluidos microservicios, tareas por lotes, tareas de transmisión e inteligencia artificial. Desde 2022, se ha implementado en lotes en los centros de datos internos de ByteDance. Se ha verificado que el programador Gödel proporciona >60 % de utilización de CPU y >95 % de utilización de GPU durante los períodos pico , con un rendimiento de programación máximo de casi 5000 pods/seg .

introducción

En los últimos años, con el rápido desarrollo de las líneas de negocios de ByteDance, los tipos de negocios internos de la compañía se han vuelto cada vez más diversos, incluidos microservicios, búsqueda promocionada (recomendación/publicidad/búsqueda), big data, aprendizaje automático y escala de almacenamiento. y otras empresas se están expandiendo rápidamente, y la cantidad de recursos informáticos que necesitan también se está expandiendo rápidamente. En los primeros días, el negocio en línea y el negocio fuera de línea de Bytedance tenían grupos de recursos independientes y se adoptó una gestión de grupos separada entre las empresas. Para hacer frente al crecimiento explosivo de las solicitudes comerciales en línea durante festivales y eventos importantes, los equipos de infraestructura a menudo necesitan hacer planes con anticipación y prestar algunos recursos comerciales fuera de línea al grupo de recursos comerciales en línea. Aunque este método puede satisfacer necesidades temporales, el proceso de préstamo de recursos entre diferentes grupos de recursos es largo, complejo e ineficiente. Al mismo tiempo, los grupos de recursos independientes generan altos costos de coubicación entre empresas fuera de línea, y el límite para mejorar la utilización de los recursos también es muy limitado. Para abordar este problema, el documento propone el programador fuera de línea unificado Gödel, cuyo objetivo es utilizar el mismo conjunto de programadores para programar y administrar de manera uniforme los servicios fuera de línea y realizar la agrupación de recursos, mejorando así la utilización de los recursos y la elasticidad de los recursos. experiencia y reducir la presión de operación y mantenimiento. El programador Gödel se basa en la plataforma Kubernetes y puede reemplazar sin problemas al programador nativo de Kubernetes. Es superior al programador nativo de Kubernetes y a otros programadores de la comunidad en términos de rendimiento y funcionalidad.

Encender el motor

ByteDance opera docenas de centros de datos de múltiples clústeres a ultra gran escala cada día se crean y eliminan decenas de millones de tareas en contenedores. El rendimiento promedio de tareas de un solo clúster durante el pico de la noche es >1000 pods/seg. Las prioridades comerciales, los modos operativos y los requisitos de recursos de estas tareas son diferentes. Cómo programar estas tareas de manera eficiente y razonable para mantener una alta utilización y elasticidad de los recursos mientras se garantiza un SLA de tareas de alta calidad y diferentes requisitos de recursos de las tareas es un trabajo muy desafiante.

A través de la investigación, descubrimos que ninguno de los programadores de clústeres comúnmente utilizados en la comunidad puede cumplir bien con los requisitos de ByteDance:

Aunque el programador nativo de Kubernetes es muy adecuado para la programación de microservicios y proporciona una variedad de semánticas de programación flexibles, su soporte para servicios fuera de línea no es satisfactorio, porque el programador nativo de Kubernetes tiene un rendimiento de programación bajo (<200 pods/seg). ), El tamaño del clúster admitido también es limitado (generalmente <= 5000 nodos) y no puede satisfacer las enormes necesidades de programación comercial en línea dentro de ByteDance.
Volcano de la comunidad CNCF es un programador dirigido principalmente a servicios fuera de línea, que puede satisfacer las necesidades de programación de servicios fuera de línea (por ejemplo, lotes, capacitación fuera de línea, etc.) (por ejemplo, programación grupal). Sin embargo, su tasa de rendimiento de programación también es relativamente baja y no puede admitir servicios en línea al mismo tiempo.
YARN es otra herramienta popular de gestión de recursos de clúster y ha sido la primera opción para la programación empresarial fuera de línea durante mucho tiempo en el pasado. No solo tiene un buen soporte para la semántica de programación requerida para servicios fuera de línea, como el entrenamiento por lotes y fuera de línea, sino que también tiene una alta tasa de rendimiento de programación y puede admitir clústeres a gran escala. Sin embargo, su principal inconveniente es que no admite bien las empresas en línea, como los microservicios, y no puede satisfacer las necesidades de programación de las empresas en línea y fuera de línea al mismo tiempo.

Por lo tanto, ByteDance espera desarrollar un programador que combine las ventajas de Kubernetes y YARN para abrir grupos de recursos y administrar de manera uniforme todo tipo de negocios. Según la discusión anterior, se espera que el planificador tenga las siguientes características:

Fondo de recursos unificado

Todos los recursos informáticos del clúster son visibles y asignables a diversas tareas tanto en línea como fuera de línea. Reduzca la tasa de fragmentación de recursos y los costos de operación y mantenimiento del clúster.

Utilización mejorada de recursos

Mezcle tareas de diferentes tipos y prioridades en las dimensiones del clúster y del nodo para mejorar la utilización de los recursos del clúster.

Alta elasticidad de recursos

En las dimensiones de clúster y nodo, los recursos informáticos se pueden transferir de manera flexible y rápida entre servicios de diferentes prioridades. Al tiempo que se mejora la utilización de los recursos, los derechos de asignación de prioridad de recursos y el SLA de servicios de alta calidad están garantizados en todo momento.

Alto rendimiento de programación

En comparación con el programador nativo de Kubernetes y el programador Volcano de la comunidad, los servicios en línea y fuera de línea deben mejorar en gran medida el rendimiento de la programación. Cumplir con los requisitos comerciales > 1000 pods/seg.

Programación consciente de la topología

La microtopología de recursos de los nodos candidatos se identifica al tomar decisiones de programación en lugar de cuando kubelet lo admite, y se seleccionan los nodos apropiados para la programación en función de las necesidades comerciales.

Introducción a Gödel

Gödel Scheduler es un programador distribuido utilizado en entornos de clúster de Kubernetes que puede programar de manera uniforme servicios en línea y fuera de línea. Puede proporcionar buena escalabilidad y calidad de programación al mismo tiempo que cumple con los requisitos de rendimiento y funciones comerciales fuera de línea. Como se muestra en la figura siguiente, Gödel Scheduler tiene una estructura similar al programador nativo de Kubernetes y consta de tres componentes: Dispatcher, Scheduler y Binder. La diferencia es que para admitir clústeres más grandes y proporcionar un mayor rendimiento de programación, su componente Programador puede ser de múltiples instancias y adoptar una programación concurrente optimista, mientras que Dispatcher y Binder se ejecutan en una sola instancia.

componentes centrales

Dispatcher es la entrada a todo el proceso de programación y es el principal responsable de la cola de tareas, la distribución de tareas, la partición de nodos, etc. Consta principalmente de varias partes: Administrador de políticas de clasificación, Administrador de políticas de envío, Mezclador de nodos y Mantenedor del programador.

Administrador de políticas de clasificación : Principalmente responsable de las tareas de cola. Actualmente implementa estrategias de cola como FIFO, DRF y FairShare. Se agregarán más estrategias de cola en el futuro, como las basadas en valores de prioridad, etc.
Administrador de políticas de despacho : Principalmente responsable de distribuir tareas a diferentes instancias del Programador y respaldar diferentes estrategias de distribución a través de la configuración del complemento. La estrategia predeterminada actual se basa en LoadBalance.
Node Shuffler : Principalmente responsable de particionar los nodos del clúster según la cantidad de instancias del Programador. Cada nodo sólo puede estar en una partición. Cada instancia de Scheduler corresponde a una Partición. Cuando una instancia de Scheduler funciona, dará prioridad a los nodos en su propia Partición. Si no encuentra ningún nodo que cumpla con los requisitos, buscará nodos en otras Particiones. Si el estado del clúster cambia, como agregar o eliminar nodos, o cambia la cantidad de Programadores, la reproducción aleatoria de nodos volverá a dividir los nodos según la situación real.
Mantenedor del programador : Principalmente responsable de mantener el estado de cada instancia del Programador, incluido el estado de salud de la instancia del Programador, el estado de carga, la cantidad de nodos de partición, etc.

Scheduler recibe solicitudes de tareas de Dispatcher y es responsable de tomar decisiones específicas de programación y preferencia de tareas, pero en realidad no las ejecuta. Al igual que el programador nativo de Kubernetes, el Programador de Gödel también determina una decisión de programación a través de una serie de complementos en diferentes enlaces. Por ejemplo, los dos complementos siguientes se utilizan para encontrar nodos que cumplan con los requisitos.

Complementos de filtrado: solicitudes de recursos basadas en tareas, filtrado de nodos que no cumplen con los requisitos;
Complementos de puntuación: califique los nodos filtrados anteriormente y seleccione el nodo más adecuado.

A diferencia del programador nativo de Kubernetes, el Programador de Gödel permite que se ejecuten múltiples instancias de manera distribuida . Para escenarios y clústeres de muy gran escala que requieren un alto rendimiento, podemos configurar varias instancias del programador para satisfacer las necesidades. En este momento, cada instancia del programador se programa de forma independiente y en paralelo. Al seleccionar un nodo, primero se selecciona de la partición a la que pertenece la instancia. Esto tiene mejor rendimiento, pero solo puede garantizar la optimización local cuando no hay una adecuada. nodo en la partición local, se seleccionará de la partición a la que pertenece la instancia. Los nodos se seleccionan en las particiones de otras instancias, pero esto puede causar un conflicto, es decir, varias instancias del programador seleccionan el mismo nodo al mismo tiempo. Cuantas más instancias del programador haya, mayores serán las posibilidades de que se produzca un conflicto. Por lo tanto, el número de instancias debe establecerse adecuadamente no siempre es mejor.

Además, para admitir tareas en línea y fuera de línea, Gödel Scheduler adopta una semántica de programación de dos niveles , es decir, admite la programación de dos niveles de la Unidad de programación y la Unidad de ejecución de Pod que representan implementaciones comerciales como Pod Group o ReplicaSet. El uso específico se presentará más adelante.

Binder es el principal responsable de la verificación optimista de conflictos, la realización de operaciones de preferencia específicas, la preparación de tareas antes de la vinculación, como la creación dinámica de volúmenes de almacenamiento y, finalmente, la realización de operaciones de vinculación. En general, es similar al flujo de trabajo de Kubernetes Binder, pero en Gödel, Binder tiene que lidiar con más conflictos causados por múltiples instancias de Scheduler. Una vez que se descubre un conflicto, llámelo inmediatamente y reprograme. Para las operaciones de preferencia, Binder verifica si hay varias instancias de Schduler que intentan adelantarse a la misma instancia (es decir, Victim Pod). Si existe tal problema, Binder solo maneja la primera preferencia y rechaza las solicitudes de preferencia emitidas por las instancias restantes de Schduler. Para la programación en grupo o conjunta, el Binder debe manejar los conflictos (si los hay) para todos los Pods del grupo de Pods. O se resuelven todos los conflictos de Pod y cada Pod se vincula por separado o se rechaza la programación de todo el grupo de Pod;

CNR significa Custom Node Resource, que es un CRD creado por ByteDance para complementar la información del nodo en tiempo real. Aunque no forma parte del propio Gödel Scheduler, puede mejorar la semántica de programación de Gödel. Este CRD no solo define la cantidad de recursos y el estado de un nodo, sino que también define la microtopología de los recursos, como el consumo de CPU/memoria y la cantidad de recursos restantes en cada socket del nodo de doble socket. Esto permite al programador seleccionar nodos apropiados según el estado del nodo descrito por CNR al programar tareas con requisitos de afinidad de microtopología.

En comparación con Kubernetes nativo, que solo usa el administrador de topología, el uso de CNR puede evitar el error de programación que encuentra kubelet cuando los pods se programan en nodos que no cumplen con las restricciones de topología. Si un Pod se crea con éxito en el nodo, el agente del nodo que pertenece a Katalyst actualizará el CNR .

Lectura relacionada: " Katalyst: práctica de optimización de costos nativa de Bytedance Cloud "

programación de dos niveles

Cuando Bytedance estaba diseñando Gödel, uno de sus principales objetivos era satisfacer las necesidades de programación de servicios tanto online como offline. Para lograr este objetivo, Gödel introduce dos niveles de semántica de programación, a saber, Unidad de programación y Unidad de ejecución.

El primero corresponde a un trabajo desplegado y consta de una o más Unidades en Marcha. Por ejemplo, cuando un usuario implementa un trabajo a través de Kubernetes Deployment, el trabajo se asigna a una Unidad de programación y cada Pod que ejecuta la tarea corresponde a una Unidad en ejecución. A diferencia de la programación directa orientada a Pod de Kubernetes nativo, el marco de programación de dos niveles de Gödel siempre utilizará el estado general de la Unidad de programación como principio de admisión. Cuando una unidad de programación se considera programable, las unidades en ejecución (es decir, pods) que contiene se programarán en secuencia.

La regla para juzgar si una unidad de programación es programable es que haya >= Min_Member unidades en ejecución que cumplan las condiciones de programación, es decir, cuando el programador puede encontrar nodos que cumplan con los requisitos de recursos para suficientes Pods en un trabajo, se considera que el trabajo ser programable. En este momento, el programador programará cada Pod en el nodo designado por turno. De lo contrario, no se programarán todos los Pods y se rechazará toda la implementación del trabajo.

Se puede ver que Min_Member de la unidad de programación es un parámetro muy importante. Configurar diferentes Min_Member puede satisfacer las necesidades de diferentes escenarios. El rango de valores de Min_Member es [1, Número de unidades en ejecución].

Por ejemplo, cuando está orientado al negocio de microservicios, Min_Member se establece en 1. Siempre que se pueda satisfacer la solicitud de recursos de una unidad en ejecución/pod en cada unidad de programación, se podrá realizar la programación. En este punto, el programador de Gödel se ejecuta básicamente igual que el programador nativo de Kubernetes.

Cuando se enfrentan servicios fuera de línea como Batch y entrenamiento fuera de línea que requieren semántica de Gang, el valor de Min_Member es igual a la cantidad de Unidades en ejecución/Pods (algunos servicios también se pueden ajustar a un valor entre 1 y Número de unidades en ejecución según las necesidades reales). ), es decir, la programación comienza solo cuando todos los Pods pueden satisfacer las solicitudes de recursos. El valor de Min_Member se establece automáticamente según el tipo de empresa y los parámetros de la plantilla de implementación empresarial.

Optimización del rendimiento

Debido a las propias necesidades comerciales de ByteDance, tiene altos requisitos para programar el rendimiento. Uno de los objetivos de diseño de Gödel es proporcionar un alto rendimiento. Con este fin, el programador de Gödel coloca la parte del nodo de filtrado que consume más tiempo en un programador de instancias múltiples que puede ejecutarse simultáneamente. Por un lado, debido a que varias instancias encontrarán conflictos, el número de instancias de Schduler no siempre es mejor; por otro lado, la mejora del rendimiento aportada por varias instancias por sí sola no es suficiente para hacer frente al pico nocturno de 1000-2000 pods/; s en un solo clúster. Para mejorar aún más la eficiencia de la programación, Gödel ha realizado más optimizaciones en los siguientes aspectos.

Nodos candidatos de caché

En el proceso de filtrado de nodos, Filtrar y Priorizar son las dos partes que consumen más tiempo. El primero filtra los nodos disponibles en función de las solicitudes de recursos y el segundo puntúa los nodos candidatos para encontrar el nodo más adecuado. Si se puede aumentar la velocidad de ejecución de estas dos partes, todo el ciclo de programación se comprimirá enormemente.

El equipo de desarrollo de ByteDance observó que aunque los recursos informáticos son utilizados por diferentes aplicaciones de diferentes unidades de negocio, todos o la mayoría de los Pods de una aplicación de un determinado usuario empresarial suelen tener los mismos requisitos de recursos.

Ejemplo: una aplicación social se aplica para crear 20.000 servidores HTTP. Cada servidor requiere 4 núcleos de CPU y 8 GB de memoria. Un equipo de Big Data necesita ejecutar un programa de análisis de datos con 10.000 subtareas, cada una de las cuales requiere 1 núcleo de CPU y 4 GB de memoria.

La mayoría de los Pods en estas tareas creadas en masa tienen la misma aplicación de recursos, el mismo segmento de red, afinidad de dispositivo y otros requisitos. Luego, los nodos candidatos seleccionados por el complemento de filtro satisfacen las necesidades del primer Pod y es probable que satisfagan las necesidades de otros Pods para esta tarea.

Por lo tanto, el programador de Gödel almacena en caché los nodos candidatos después de programar el primer Pod y busca preferentemente nodos disponibles en el caché en la siguiente ronda de programación. A menos que el estado del clúster cambie (se agreguen o eliminen nodos) o se encuentren pods con diferentes requisitos de recursos, no es necesario volver a escanear los nodos en el clúster en cada ronda. Los nodos que no tengan recursos para asignar durante el proceso de programación se eliminarán de la caché y la clasificación se ajustará según el estado del clúster. Esta optimización puede optimizar significativamente el proceso de selección de nodos. Al programar un grupo de Pods para el mismo usuario empresarial, idealmente puede reducir la complejidad del tiempo de O(n) a O(1) .

Reducir la proporción de nodos escaneados.

Aunque la optimización anterior puede reducir el proceso de construcción de nodos candidatos, si el estado del clúster o la aplicación de recursos cambia, aún es necesario volver a escanear todos los nodos del clúster.

Para reducir aún más el tiempo, Gödel ajustó la proporción de escaneo de la lista de candidatos y utilizó la solución óptima local como reemplazo aproximado de la solución óptima global. Debido a que es necesario encontrar suficientes nodos candidatos para todas las unidades en ejecución/pods durante el proceso de programación, Gödel escaneará al menos el número de nodos de las unidades en ejecución. Según el análisis de los datos históricos, Gödel escanea el número de unidades en ejecución + 50 nodos de forma predeterminada. para encontrar candidatos. Si no se encuentra ninguno adecuado, se escaneará nuevamente el mismo número. Este método, combinado con el almacenamiento en caché de los nodos candidatos, reducirá en gran medida la sobrecarga de tiempo del programador para encontrar nodos adecuados para los Pods.

Optimizar estructuras de datos y algoritmos.

Además de las dos optimizaciones anteriores, el programador de Gödel también optimiza continuamente estructuras de datos y algoritmos:

Para mantener la lista de nodos candidatos a bajo costo y evitar la sobrecarga causada por la reconstrucción frecuente de la lista de nodos. Gödel reconstruyó el mecanismo de mantenimiento NodeList del programador nativo de Kubernetes , resolvió los problemas de rendimiento de los clústeres de producción a gran escala discretizando la lista de nodos y logró mejores efectos de discretización de nodos con menores gastos generales;

Para mejorar la utilización general de los recursos, ByteDance combina e implementa tareas en línea de alta calidad y tareas fuera de línea de baja calidad. Debido a las características de marea de los negocios, una gran cantidad de negocios en línea regresan durante el pico de la tarde, lo que a menudo requiere una preferencia de alta frecuencia sobre negocios fuera de línea de baja calidad. El proceso de preferencia implica una gran cantidad de cálculos de búsqueda, y la preferencia frecuente afecta gravemente la eficiencia general del trabajo del programador. Para resolver este problema, el programador Gödel introduce una estrategia de poda multidimensional basada en Pods y Nodes , que permite que el rendimiento de preferencia se recupere rápidamente y el retraso de preferencia se reduzca significativamente.

Resultados experimentales

El artículo evalúa el rendimiento del planificador de Gödel en términos de rendimiento de programación, tamaño del clúster, etc.

En primer lugar, para el negocio de microservicios, ByteDance comparó Gödel (instancia única) con el programador nativo de Kubernetes. En términos de escala de clúster, Kubernetes nativo solo puede admitir un clúster máximo de 5000 nodos de forma predeterminada y el rendimiento máximo de programación es inferior a 200 Pods/s. Después de usar KubeBrain , un almacén clave-valor de alto rendimiento de código abierto de Byte , Kubernetes nativo puede admitir clústeres más grandes y el rendimiento de la programación también mejora significativamente. Pero el rendimiento de la combinación de Kubernetes + KubeBrain es aún mucho menor que el de Gödel. Gödel puede lograr un rendimiento de 2600 Pods/s en un clúster de 5000 nodos. Incluso con 20 000 nodos, todavía hay alrededor de 2000 Pods/s, lo que es más de 10 veces el rendimiento del programador nativo de Kubernetes .

Para lograr un mayor rendimiento de programación, Gödel puede habilitar múltiples instancias. La figura de la derecha a continuación muestra de 1 a 6 instancias del programador que se abren en secuencia en un grupo de 10 000 nodos. El rendimiento aumenta gradualmente en la etapa inicial y el valor máximo puede alcanzar aproximadamente 4600 Pods/s. Pero cuando el número de instancias excede 5, el rendimiento disminuye. La razón es que cuantas más instancias, más conflictos entre instancias, lo que afecta la eficiencia de la programación. Por lo tanto, no es que cuantas más instancias de programación, mejor.

Para tareas fuera de línea con requisitos semánticos de Gang, el artículo compara a Gödel con YARN y K8s-volcano comúnmente utilizados en la comunidad de código abierto. Se puede ver claramente que el rendimiento de Gödel no sólo es mucho mayor que el del volcán K8s, sino también casi el doble que el de YARN. Gödel admite la programación simultánea de tareas en línea y fuera de línea. El documento simula el escenario en el que se mezclan diferentes negocios cambiando la proporción de tareas fuera de línea enviadas al sistema. Se puede ver que independientemente de la proporción de servicios fuera de línea, el rendimiento de Gödel es relativamente estable y el rendimiento se mantiene en alrededor de 2000 Pods/s .

Para demostrar por qué Gödel tiene una mejora de rendimiento tan grande, el artículo se centra en analizar las contribuciones de dos optimizaciones principales: " almacenar en caché los nodos candidatos " y " reducir la tasa de escaneo ". Como se muestra en la figura siguiente, el experimento anterior se repitió usando la versión completa de Gödel, Gödel solo con la optimización de caché de nodo activada y Gödel solo con la relación de escaneo reducida activada. Los resultados experimentales demostraron que estos dos elementos principales de optimización contribuyeron aproximadamente. 60% y 60 % respectivamente .

Además de utilizar puntos de referencia para evaluar el rendimiento extremo de Gödel, el documento también muestra la experiencia real de ByteDance utilizando el programador de Gödel en un entorno de producción, lo que demuestra que Gödel tiene buenas capacidades en la agrupación, elasticidad y circulación de recursos.

La siguiente figura de la izquierda describe la asignación de recursos de tareas en línea y tareas fuera de línea en un determinado grupo dentro de un determinado período de tiempo. Al principio, las tareas en línea consumen pocos recursos y una gran cantidad de recursos informáticos se asignan a tareas fuera de línea con menor prioridad. Cuando las tareas en línea tienen un aumento en la demanda de recursos debido a un evento especial (emergencia, búsqueda activa, etc.), Gödel asigna recursos inmediatamente a las tareas en línea y la cantidad de asignación de recursos para tareas fuera de línea disminuye rápidamente. Cuando pasa el pico, las tareas en línea comienzan a reducir las solicitudes de recursos y el programador vuelve a transferir recursos a tareas fuera de línea. A través de la agrupación fuera de línea y la transferencia dinámica de recursos, ByteDance siempre puede mantener una alta utilización de los recursos. Durante las horas pico de la tarde, la tasa de recursos promedio del clúster alcanza más del 60% y también se puede mantener en alrededor del 40% durante la etapa mínima del día.

Resumen y perspectivas de futuro

El artículo presenta a Gödel, un sistema de programación diseñado y desarrollado por el equipo de programación y orquestación de ByteDance para unificar grupos de recursos fuera de línea. El sistema de programación admite la programación simultánea de tareas en línea y fuera de línea en clústeres de escala ultragrande, admite la agrupación, elasticidad y circulación de recursos y tiene un alto rendimiento de programación. Desde que Gödel se lanzó en lotes en el propio centro de datos de ByteDance en 2022, ha satisfecho las necesidades de coubicación de la mayoría de las empresas internas, logrando una utilización de recursos promedio de más del 60 % durante el pico de la tarde y un rendimiento de programación de aproximadamente 5000 Pods/ s .

En el futuro, el equipo de orquestación y programación continuará promoviendo la expansión y optimización del programador Gödel, enriqueciendo aún más la semántica de programación, mejorando la capacidad de respuesta del sistema y reduciendo la probabilidad de conflictos en situaciones de múltiples instancias mientras optimizan la programación inicial. También construirá y fortalecerá el sistema de redireccionamiento de capacidades de programación, diseño y desarrollo de Gödel Rescheduler. Mediante el trabajo colaborativo de Gödel Scheduler y Rescheduler, se logra una asignación razonable de recursos del clúster durante todo el ciclo.

Actualmente, el planificador de Gödel es de código abierto . Damos la más sincera bienvenida a los desarrolladores y empresas de la comunidad para que se unan a la comunidad y participen en la construcción conjunta del proyecto con nosotros. La dirección del proyecto es: github.com/kubewharf/godel-scheduler .

Escanea el código QR para unirte a la comunidad de código abierto ByteDance

Interpretación del artículo SoCC: cómo ByteDance implementa la programación unificada de recursos en clústeres a gran escala