Práctica de optimización de costos nativa de Bytedance Cloud Proyecto de código abierto Katalyst | ¡Lanzamiento del desafío de programación comunitaria!

Wuhan Yuan Chuanghui regresa, hablemos de modelos grandes el 20 de abril”

Introducción a Katalyst

Repositorio de GitHub: https://github.com/kubewharf/katalyst-core

Katalyst es el sistema de práctica de optimización de costos de código abierto de ByteDance. Su objetivo es resolver el problema de la utilización irrazonable de recursos en escenarios nativos de la nube y brindar soluciones para la gestión de recursos y la optimización de costos.

Katalyst fue oficialmente de código abierto en marzo de este año. Desde el lanzamiento de la versión 0.1.0, ha completado la producción de varias capacidades principales a través de la iteración de la versión 0.2.0. El 8 de agosto, Katalyst lanzó la versión v0.3.0 . Las funciones principales incluyen capacidades API KCNR mejoradas, escalabilidad mejorada del marco, capacidades mejoradas de coubicación, etc. Para obtener más detalles, consulte Katalyst GitHub .

Antecedentes de la actividad

Katalyst, como proyecto de código abierto en el que el equipo nativo de la nube de ByteDance continúa invirtiendo, valora el valor a largo plazo del código abierto y los comentarios y participación de la comunidad de código abierto. Al mismo tiempo, también alienta a los estudiantes universitarios a hacerlo. participe en proyectos reales de código abierto en las primeras etapas y experimente cómo opera la comunidad de código abierto, mejore sus habilidades personales. En el campamento de verano de programación GLCC en el que participé antes , los temas relevantes publicados por Katalyst atrajeron a muchos estudiantes universitarios a inscribirse para participar. Durante el proyecto, los instructores y los estudiantes del proyecto se comunicaron activamente sobre los planes factibles y ayudaron a los estudiantes a participar en el desarrollo del proyecto.

Debido a las restricciones temáticas de actividades anteriores, finalmente solo un estudiante participó en el proyecto. Para alentar a más estudiantes universitarios interesados en la nube nativa a participar en la comunidad, y también esperar que la comunidad tenga más voces externas y fuerzas nuevas, planeamos reutilizar este modelo de desarrollo de colaboración con estudiantes universitarios en la versión del proyecto. proceso de iteración Proporcionar a los estudiantes universitarios rutas y orientación para participar en la comunidad de código abierto, al tiempo que ayuda a la comunidad a recopilar más comentarios y necesidades. En base a esto, lanzaremos el evento de la comunidad de código abierto Katalyst [ Desafío de programación ] en la comunidad en septiembre. Según la planificación de capacidades relevantes en la futura nueva versión de la comunidad, se publicarán tareas temáticas y se invitará a estudiantes universitarios. participar en el diseño y desarrollo de algunos temas del proyecto, y por la realización de Proporcionar ciertas recompensas a los estudiantes que completen la tarea.

Introducción al tema

Tema 1: Soporte para prioridad OOM como mejora de QoS Soporte para prioridad OOM como mejora de QoS

Problema de GitHub: https://github.com/kubewharf/katalyst-core/issues/216

Agregue las siguientes capacidades a Katalyst:

Los usuarios pueden especificar la prioridad OOM como una mejora de QoS.
Implemente la prioridad OOM con oom_score_adj.
Los usuarios pueden especificar la prioridad OOM como mejora de QoS
oom_score_adjImplementar la prioridad OOM usando

Tema Descripción:

Actualmente, Kubernetes configurará diferentes oom_score_adjvalores para diferentes clases de QoS. Sin embargo, el orden de OOM también depende de otros factores dimensionales, como el uso de memoria del contenedor.

En el escenario de colocación, es importante garantizar estrictamente que los servicios web finalicen más tarde que los trabajos por lotes debido a OOM cuando los recursos de memoria del clúster escasean.

oom_score_adjActualmente, Kubernetes configura diferentes valores para diferentes clases de QoS . Sin embargo, el orden de OOM también depende de otras dimensiones, como el uso de memoria del contenedor.

En un escenario de coubicación, cuando los recursos de memoria del clúster escasean, se debe garantizar estrictamente que el trabajo de procesamiento por lotes finalice debido a OOM antes que el servicio web.

Tema 2: Soportar informes de granularidad NUMA para recursos recuperados Soportar informes de granularidad NUMA de recursos recuperados

Problema de GitHub: https://github.com/kubewharf/katalyst-core/issues/217

Agregue las siguientes capacidades a Katalyst:

Mejorar el mecanismo de informes de recursos para admitir informes de recursos recuperados en la granularidad de los nodos NUMA.

Mecanismo de informes de recursos mejorado para admitir informes granulares de recursos reciclados del nodo NUMA.

Tema Descripción:

Actualmente, los informes de recursos recuperados se realizan a nivel de granularidad de nodo. Sin embargo, en entornos con arquitecturas NUMA, este enfoque podría dar lugar a resultados de programación subóptimos y posibles desalojos de pods debido a interferencias de nivel NUMA.

Actualmente, los informes de recursos reciclados se realizan a nivel de granularidad de nodo. Sin embargo, en entornos con arquitecturas NUMA, este enfoque puede generar resultados de programación subóptimos y posibles desalojos de Pod debido a interferencias de nivel NUMA.

Tema 3: Soporte de afinidad y antiafinidad entre pods a nivel NUMA Soporte de afinidad y antiafinidad entre pods a nivel NUMA

Problema de GitHub: https://github.com/kubewharf/katalyst-core/issues/220

Agregue las siguientes capacidades a Katalyst:

Admite afinidad y antiafinidad entre pods a nivel NUMA en Kubernetes.

Admite afinidad y antiafinidad entre pods de nivel NUMA en Kubernetes.

Tema Descripción:

Actualmente, Kubernetes admite afinidad y antiafinidad entre pods a nivel de nodo. Sin embargo, existe una necesidad creciente de ampliar este apoyo al nivel de la NUMA.

Por ejemplo, en un trabajo de entrenamiento de tensorflow, los pods que consumen mucho ancho de banda de memoria, como los trabajadores, pueden afectar el rendimiento de otros pods en el mismo nodo NUMA, como los servidores de parámetros. La asignación de estos pods a diferentes nodos NUMA puede mitigar dichas interferencias.

Actualmente, Kubernetes admite afinidad y antiafinidad entre pods a nivel de nodo. Sin embargo, existe una necesidad creciente de ampliar este apoyo al nivel de la NUMA.

Por ejemplo, en el entrenamiento de tensorflow, el alto consumo de ancho de banda de memoria de los trabajadores afectará al servidor de parámetros en el mismo nodo NUMA. Asignar estos pods a diferentes nodos NUMA puede mitigar esta interferencia.

cosecha esperada

Experimente proyectos reales de código abierto, familiarícese con los procedimientos operativos de las comunidades de código abierto y acumule experiencia práctica en el desarrollo.
Participe en reuniones comunitarias, comuníquese con entusiastas del código abierto y aprenda sobre la dinámica de la comunidad.
Mentor de proyecto, tutoría individual, preguntas y respuestas cara a cara
Los contribuyentes excelentes que completen el proyecto también recibirán un bono de incentivo comunitario de 5.000 yuanes (equivalente a una tarjeta Jingdong).

Requisitos de participación

Estudiantes universitarios mayores de 18 años.
Ama la cultura del código abierto y acepta el modelo de colaboración de código abierto.

*Si los estudiantes no universitarios están interesados en el tema, pueden participar en la comunidad para construirlo y desarrollarlo~

Participa en el proceso.

Elija 1 problema de los siguientes problemas de GitHub
Enviar currículum + propuesta de tema a contactos relevantes
1. Persona de contacto: Sr. Tang
2. Correo electrónico: [email protected]
Después de aprobar, el mentor del proyecto se comunicará con usted para comunicarle tareas de desarrollo específicas y comenzar el desarrollo.
Después de completar la tarea, debe escribir un artículo sobre su experiencia y sentimientos al participar en proyectos de código abierto y publicarlo en una comunidad de terceros (InfoQ/CSDN/Zhihu/Open Source China, etc.) o en un blog del campus.

tiempo de actividad

Fecha de inscripción: 1 de septiembre - 14 de septiembre
Notificación de selección: 15 de septiembre
Tiempo de desarrollo: 16 de septiembre - 30 de octubre
Fecha de publicación del artículo: antes del 10 de noviembre.
Tema destacado y anuncio del estudiante: 10 de noviembre - 15 de noviembre

Si tiene alguna pregunta, comuníquese con Bytedance Cloud Native Assistant:

imagen.imagen

Por favor indique [nombre+empresa/escuela+título]