[Antevisão da transmissão ao vivo] Os modelos grandes substituirão os programadores? "

Os recursos de gerenciamento de QoS podem agendar aplicativos on-line e off-line de maneira uniforme, melhorando significativamente a utilização de recursos.

Fonte | Equipe de infraestrutura ByteDance

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

Este artigo interpreta o artigo " Gödel: Unified Large-Scale Resource Management and Scheduling at Bytedance " publicado pela equipe de orquestração e agendamento de infraestrutura da Bytedance na SoCC 2023, a principal conferência internacional de computação em nuvem .

Link do artigo: dl.acm.org/doi/proceedings/10.1145/3620678

O artigo apresenta um sistema de agendamento de tarefas de alto rendimento baseado em Kubernetes proposto pela ByteDance que suporta a mistura de tarefas online e offline. Seu objetivo é resolver efetivamente o problema de alocação de recursos de diferentes tipos de tarefas em data centers de grande escala e melhorar o desempenho. recursos do data center Utilização, resiliência e taxa de transferência de agendamento.

Atualmente, o sistema de agendamento oferece suporte ao gerenciamento de clusters de escala ultragrande com dezenas de milhares de nós e fornece recursos de pooling de recursos para vários tipos de tarefas, incluindo microsserviços, lote, tarefas de streaming e IA. Desde 2022, ele foi implantado em lotes nos data centers internos da ByteDance. Foi verificado que o agendador Gödel fornece >60% de utilização de CPU e >95% de utilização de GPU durante períodos de pico , com uma taxa de transferência de agendamento de pico de quase 5.000 pods/s .

introdução

Nos últimos anos, com o rápido desenvolvimento das linhas de negócios da ByteDance, os tipos de negócios internos da empresa tornaram-se cada vez mais diversificados, incluindo microsserviços, pesquisa promovida (recomendação/anúncio/pesquisa), big data, aprendizado de máquina, escala de armazenamento e outras empresas estão a expandir-se rapidamente, e a quantidade de recursos informáticos necessários para elas também está a expandir-se rapidamente. No início, os negócios online e offline da Bytedance tinham pools de recursos independentes e um gerenciamento de pool separado foi adotado entre os negócios. Para lidar com o crescimento explosivo das solicitações de negócios on-line durante festivais e eventos importantes, as equipes de infraestrutura geralmente precisam fazer planos com antecedência e emprestar alguns recursos de negócios off-line ao pool de recursos de negócios on-line. Embora este método possa satisfazer necessidades temporárias, o processo de empréstimo de recursos entre diferentes conjuntos de recursos é longo, complexo e ineficiente. Ao mesmo tempo, os agrupamentos independentes de recursos conduzem a elevados custos de co-localização entre empresas offline, e o limite máximo para melhorar a utilização dos recursos é também muito limitado. Para lidar com esse problema, o artigo propõe o agendador offline unificado Gödel, que visa usar o mesmo conjunto de agendadores para agendar e gerenciar uniformemente serviços offline e realizar o pool de recursos, melhorando assim a utilização e a elasticidade dos recursos. experiência e reduzir a pressão de operação e manutenção. O agendador Gödel é baseado na plataforma Kubernetes e pode substituir perfeitamente o agendador nativo do Kubernetes. É superior ao agendador nativo do Kubernetes e outros agendadores da comunidade em termos de desempenho e funcionalidade.

Ligue o motor

A ByteDance opera dezenas de data centers multicluster de grande escala. Dezenas de milhões de tarefas em contêineres são criadas e excluídas todos os dias. O rendimento médio de tarefas de um único cluster durante o pico noturno é de >1.000 pods/s. As prioridades de negócios, os modos de operação e os requisitos de recursos dessas tarefas são diferentes. Como agendar essas tarefas de maneira eficiente e razoável para manter a alta utilização e elasticidade dos recursos e, ao mesmo tempo, garantir um SLA de tarefas de alta qualidade e diferentes requisitos de recursos de tarefas é um desafio.

Por meio de pesquisas, descobrimos que nenhum dos agendadores de cluster comumente usados na comunidade pode atender bem aos requisitos do ByteDance:

Embora o agendador nativo do Kubernetes seja muito adequado para agendamento de microsserviços e forneça uma variedade de semânticas de agendamento flexíveis, seu suporte para serviços offline não é satisfatório, porque o agendador nativo do Kubernetes tem uma baixa taxa de transferência de agendamento (<200 pods/s). ), O tamanho do cluster suportado também é limitado (geralmente <= 5.000 nós) e não pode atender às enormes necessidades de agendamento de negócios online no ByteDance.
Volcano da comunidade CNCF é um agendador voltado principalmente para serviços offline, que pode atender às necessidades de agendamento de serviços offline (por exemplo, lote, treinamento offline, etc.) (por exemplo, agendamento de gangue). No entanto, sua taxa de transferência de agendamento também é relativamente baixa e não pode suportar serviços online ao mesmo tempo.
YARN é outra ferramenta popular de gerenciamento de recursos de cluster e tem sido a primeira escolha para agendamento de negócios offline há muito tempo. Ele não apenas oferece um bom suporte para a semântica de agendamento necessária para serviços off-line, como treinamento em lote e off-line, mas também possui uma alta taxa de transferência de agendamento e pode suportar clusters de grande escala. No entanto, sua principal desvantagem é que ele não suporta bem negócios on-line, como microsserviços, e não pode atender às necessidades de agendamento de negócios on-line e off-line ao mesmo tempo.

Portanto, a ByteDance espera desenvolver um agendador que combine as vantagens do Kubernetes e do YARN para abrir pools de recursos e gerenciar uniformemente todos os tipos de negócios. Com base na discussão acima, espera-se que o escalonador tenha as seguintes características:

Pool de recursos unificado

Todos os recursos de computação no cluster são visíveis e atribuíveis a diversas tarefas online e offline. Reduza a taxa de fragmentação de recursos e os custos de operação e manutenção do cluster.

Melhor utilização de recursos

Misture tarefas de diferentes tipos e prioridades nas dimensões do cluster e do nó para melhorar a utilização dos recursos do cluster.

Alta elasticidade de recursos

Nas dimensões de cluster e nó, os recursos computacionais podem ser transferidos de forma flexível e rápida entre serviços de diferentes prioridades. Ao mesmo tempo que melhora a utilização de recursos, os direitos de atribuição de prioridade de recursos e o SLA de serviços de alta qualidade são sempre garantidos.

Alto rendimento de agendamento

Em comparação com o agendador nativo do Kubernetes e o agendador Volcano da comunidade, os serviços online e offline devem melhorar muito o rendimento do agendamento. Atenda aos requisitos de negócios > 1.000 pods/s.

Agendamento com reconhecimento de topologia

A microtopologia de recursos dos nós candidatos é identificada ao tomar decisões de agendamento, e não quando o kubelet admite, e os nós apropriados são selecionados para agendamento com base nas necessidades de negócios.

Introdução a Gödel

Gödel Scheduler é um agendador distribuído usado em ambientes de cluster Kubernetes que pode agendar serviços online e offline uniformemente. Ele pode fornecer boa escalabilidade e qualidade de agendamento, ao mesmo tempo que atende aos requisitos de função e desempenho de negócios offline. Conforme mostrado na figura abaixo, o Gödel Scheduler possui uma estrutura semelhante ao agendador nativo do Kubernetes e consiste em três componentes: Dispatcher, Scheduler e Binder. A diferença é que, para suportar clusters maiores e fornecer maior rendimento de agendamento, seu componente Scheduler pode ser multi-instância e adotar agendamento simultâneo otimista, enquanto Dispatcher e Binder são executados em uma única instância.

Componentes do núcleo

O Dispatcher é a entrada para todo o processo de agendamento e é o principal responsável pelo enfileiramento de tarefas, distribuição de tarefas, particionamento de nós, etc. Ele consiste principalmente em várias partes: Sorting Policy Manager, Dispatching Policy Manager, Node Shuffler e Scheduler Mantenedor.

Sort Policy Manager : Principalmente responsável por enfileirar tarefas. Atualmente, implementa estratégias de enfileiramento como FIFO, DRF e FairShare. Mais estratégias de enfileiramento serão adicionadas no futuro, como baseada em valor de prioridade, etc.
Dispatching Policy Manager : Principal responsável por distribuir tarefas para diferentes instâncias do Scheduler e suportar diferentes estratégias de distribuição através da configuração de plug-ins. A estratégia padrão atual é baseada em LoadBalance.
Node Shuffler : principal responsável por particionar os nós do cluster com base no número de instâncias do Scheduler. Cada nó só pode estar em uma partição. Cada instância do Scheduler corresponde a uma Partição. Quando uma instância do Scheduler funciona, ela dará prioridade aos nós de sua própria Partição. Se nenhum nó que atenda aos requisitos for encontrado, ele procurará nós em outras Partições. Se o status do cluster mudar, como adicionar ou excluir nós, ou o número de agendadores mudar, o embaralhamento do nó irá redividir os nós com base na situação real.
Mantenedor do Agendador : Principalmente responsável por manter o status de cada instância do Agendador, incluindo status de integridade da instância do Agendador, status de carga, número de nós de partição, etc.

O Agendador recebe solicitações de tarefas do Dispatcher e é responsável por tomar decisões específicas de agendamento e preempção para tarefas, mas na verdade não as executa. Assim como o agendador nativo do Kubernetes, o Agendador de Gödel também determina uma decisão de agendamento por meio de uma série de plug-ins em links diferentes. Por exemplo, os dois plug-ins a seguir são usados para encontrar nós que atendem aos requisitos.

Filtragem de plug-ins: solicitações de recursos baseadas em tarefas, filtrando nós que não atendem aos requisitos;
Plugins de pontuação: Pontue os nós filtrados acima e selecione o nó mais adequado.

Ao contrário do agendador nativo do Kubernetes, o Agendador de Gödel permite que várias instâncias sejam executadas de maneira distribuída . Para clusters e cenários de grande escala que exigem alto rendimento, podemos configurar várias instâncias do agendador para atender às necessidades. Neste momento, cada instância do agendador é agendada de forma independente e em paralelo. Ao selecionar um nó, ele é primeiro selecionado na partição à qual a instância pertence. Isso tem melhor desempenho, mas só pode garantir a otimização local; nó na partição local, ele será selecionado na partição à qual a instância pertence. Os nós são selecionados nas partições de outras instâncias, mas isso pode causar um conflito, ou seja, várias instâncias do agendador selecionam o mesmo nó ao mesmo tempo. . Quanto mais instâncias do agendador, maior a chance de conflito. Portanto, o número de instâncias deve ser definido adequadamente. Mais nem sempre é melhor.

Além disso, para suportar tarefas online e offline, o Gödel Scheduler adota semântica de agendamento de dois níveis , ou seja, suporta agendamento de dois níveis da Unidade de Agendamento e da Unidade de Execução do Pod, representando implantações de negócios como Pod Group ou ReplicaSet. O uso específico será introduzido posteriormente.

O Binder é o principal responsável pela verificação otimista de conflitos, pela execução de operações específicas de preempção, pela preparação de tarefas antes da vinculação, como a criação dinâmica de volumes de armazenamento e, finalmente, pela execução de operações de vinculação. Em geral, é semelhante ao fluxo de trabalho do Kubernetes Binder, mas em Gödel, o Binder tem que lidar com mais conflitos causados por múltiplas instâncias do Scheduler. Assim que um conflito for descoberto, ligue imediatamente e reagende. Para operações de preempção, o Binder verifica se há várias instâncias do Schduler tentando fazer a preempção da mesma instância (ou seja, Victim Pod). Se tal problema existir, o Binder tratará apenas a primeira preempção e rejeitará as solicitações de preempção emitidas pelas instâncias restantes do Schduler. Para agendamento coletivo/co, o Binder deve lidar com conflitos (se houver) para todos os pods no grupo de pods. Todos os conflitos de pod são resolvidos e cada pod é vinculado separadamente ou o agendamento de todo o grupo de pods é rejeitado.

CNR significa Custom Node Resource, que é um CRD criado pela ByteDance para complementar as informações do nó em tempo real. Embora não faça parte do próprio Gödel Scheduler, ele pode aprimorar a semântica de escalonamento do Gödel. Este CRD não apenas define a quantidade de recursos e o status de um nó, mas também define a microtopologia dos recursos, como o consumo de CPU/memória e a quantidade de recursos restantes em cada soquete no nó de soquete duplo. Isso permite que o agendador selecione nós apropriados com base no status do nó descrito pelo CNR ao agendar tarefas com requisitos de afinidade de microtopologia.

Comparado com o Kubernetes nativo que usa apenas o gerenciador de topologia, o uso do CNR pode evitar a falha de agendamento que o kubelet encontra quando os pods são agendados para nós que não atendem às restrições de topologia. Se um Pod for criado com sucesso no nó, o CNR será atualizado pelo agente do nó pertencente ao Katalyst .

Leitura relacionada: " Katalyst: prática de otimização de custos nativos da nuvem Bytedance "

agendamento em dois níveis

Quando a Bytedance estava projetando o Gödel, um de seus principais objetivos era atender às necessidades de agendamento de serviços online e offline. Para atingir este objetivo, Gödel introduz dois níveis de semântica de escalonamento, nomeadamente Unidade de Escalonamento e Unidade de Execução.

O primeiro corresponde a um trabalho implantado e consiste em uma ou mais Unidades em Execução. Por exemplo, quando um usuário implanta um trabalho por meio do Kubernetes Deployment, o trabalho é mapeado para uma unidade de agendamento e cada pod que executa a tarefa corresponde a uma unidade em execução. Ao contrário do agendamento direto orientado a Pod do Kubernetes nativo, a estrutura de agendamento de dois níveis de Gödel sempre usará o status geral da Unidade de Agendamento como princípio de admissão. Quando uma unidade de agendamento é considerada programável, as unidades em execução (ou seja, pods) que ela contém serão agendadas em sequência.

A regra para julgar se uma unidade de agendamento é programável é que existem >= Min_Member Running Units que atendem às condições de agendamento, ou seja, quando o agendador pode encontrar nós que atendam aos requisitos de recursos para pods suficientes em um trabalho, o trabalho é considerado como ser programável. Nesse momento, cada pod será agendado para o nó designado pelo agendador. Caso contrário, todos os pods não serão agendados e toda a implantação do trabalho será rejeitada.

Pode-se observar que Min_Member da Unidade de Agendamento é um parâmetro muito importante. Definir Min_Member diferentes pode atender às necessidades de diferentes cenários. O intervalo de valores de Min_Member é [1, Número de unidades em execução].

Por exemplo, quando orientado para negócios de microsserviços, Min_Member é definido como 1. Contanto que a solicitação de recursos de uma unidade/pod em execução em cada unidade de agendamento possa ser atendida, o agendamento poderá ser executado. Neste ponto, o agendador Gödel funciona basicamente da mesma forma que o agendador nativo do Kubernetes.

Ao enfrentar serviços offline como Batch e treinamento offline que exigem semântica de Gang, o valor de Min_Member é igual ao número de Unidades/Pods em Execução (alguns serviços também podem ser ajustados para um valor entre 1 e Número de Unidades em Execução de acordo com as necessidades reais ), ou seja, o agendamento começa somente quando todos os pods puderem atender às solicitações de recursos. O valor de Min_Member é definido automaticamente com base no tipo de negócio e nos parâmetros do modelo de implementação de negócios.

Otimização de performance

Devido às próprias necessidades de negócios da ByteDance, ela possui altos requisitos para agendamento de rendimento. Um dos objetivos do projeto de Gödel é fornecer alto rendimento. Para este fim, o escalonador Gödel coloca a parte mais demorada do nó de filtragem em um escalonador multi-instância que pode ser executado simultaneamente. Por um lado, porque múltiplas instâncias encontrarão conflitos, o número de instâncias Schduler nem sempre é melhor, por outro lado, a melhoria de desempenho trazida por múltiplas instâncias por si só não é suficiente para lidar com o pico noturno de 1.000-2.000 pods/; s em um único cluster. A fim de melhorar ainda mais a eficiência do agendamento, Gödel fez otimizações adicionais nos seguintes aspectos.

Nós candidatos em cache

No processo de filtragem de nós, Filtrar e Priorizar são as duas partes mais demoradas. O primeiro filtra os nós disponíveis com base nas solicitações de recursos e o último pontua os nós candidatos para encontrar o nó mais adequado. Se a velocidade de execução dessas duas partes puder ser aumentada, todo o ciclo de programação será bastante comprimido.

A equipe de desenvolvimento da ByteDance observou que, embora os recursos de computação sejam usados por diferentes aplicações de diferentes unidades de negócios, todos ou a maioria dos Pods de uma aplicação de um determinado usuário de negócios geralmente têm os mesmos requisitos de recursos.

Exemplo: Um APP social se aplica para criar 20.000 servidores HTTP. Cada servidor requer 4 núcleos de CPU e 8 GB de memória. Uma equipe de Big Data precisa executar um programa de análise de dados com 10.000 subtarefas, cada uma exigindo 1 núcleo de CPU e 4 GB de memória.

A maioria dos pods nessas tarefas criadas em massa tem o mesmo aplicativo de recursos, o mesmo segmento de rede, afinidade de dispositivo e outros requisitos. Então, os nós candidatos selecionados pelo plug-in de filtro atendem às necessidades do primeiro pod e provavelmente atenderão às necessidades de outros pods para esta tarefa.

Portanto, o agendador Gödel armazena em cache os nós candidatos após agendar o primeiro Pod e, preferencialmente, procura os nós disponíveis no cache na próxima rodada de agendamento. A menos que o status do cluster mude (nós são adicionados ou excluídos) ou pods com requisitos de recursos diferentes sejam encontrados, não há necessidade de verificar novamente os nós no cluster a cada rodada. Os nós que não possuem recursos para alocar durante o processo de agendamento serão removidos do cache e a classificação será ajustada com base no status do cluster. Essa otimização pode otimizar significativamente o processo de triagem de nós. Ao agendar um grupo de pods para o mesmo usuário comercial, idealmente pode reduzir a complexidade do tempo de O(n) para O(1) .

Reduza a proporção de nós verificados

Embora a otimização acima possa reduzir o processo de construção de nós candidatos, se o status do cluster ou o aplicativo de recursos mudar, todos os nós do cluster ainda precisarão ser verificados novamente.

A fim de reduzir ainda mais a sobrecarga de tempo, Gödel ajustou a taxa de varredura da lista de candidatos e usou a solução ótima local como um substituto aproximado para a solução ótima global. Como é necessário encontrar nós candidatos suficientes para todas as unidades/pods em execução durante o processo de agendamento, Gödel verificará pelo menos # de nós de unidades em execução. Com base na análise de dados históricos, Gödel verificará # de unidades em execução + 50 nós por padrão. para encontrar candidatos node. Se nenhum adequado for encontrado, o mesmo número será verificado novamente. Este método, combinado com o cache do nó candidato, reduzirá bastante a sobrecarga de tempo do agendador para encontrar nós adequados para os pods.

Otimize estruturas de dados e algoritmos

Além das duas otimizações acima, o escalonador Gödel também otimiza continuamente estruturas de dados e algoritmos:

A fim de manter a lista de nós candidatos a baixo custo e evitar a sobrecarga causada pela reconstrução frequente da lista de nós. Gödel reconstruiu o mecanismo de manutenção NodeList do agendador nativo do Kubernetes , resolveu os problemas de desempenho de clusters de produção em escala ultralarga discretizando a lista de nós e obteve melhores efeitos de discretização de nós com menor sobrecarga;

Para melhorar a utilização geral dos recursos, a ByteDance combina e implanta tarefas online de alta qualidade e tarefas offline de baixa qualidade. Devido às características das marés dos negócios, um grande número de negócios on-line retorna durante o pico da noite, o que muitas vezes exige preempção de alta frequência de negócios off-line de baixa qualidade. O processo de preempção envolve uma grande quantidade de cálculos de pesquisa, e a preempção frequente afeta seriamente a eficiência geral do trabalho do escalonador. Para resolver este problema, o escalonador Gödel introduz uma estratégia de poda multidimensional baseada em Pods e Nós , que permite que o rendimento da preempção se recupere rapidamente e o atraso da preempção seja significativamente reduzido.

Resultados experimentais

O artigo avalia o desempenho do escalonador Gödel em termos de taxa de transferência de agendamento, tamanho do cluster, etc.

Primeiro, para o negócio de microsserviços, a ByteDance comparou Gödel (instância única) com o agendador nativo do Kubernetes. Em termos de escala de cluster, o Kubernetes nativo só pode suportar um cluster máximo de 5.000 nós por padrão, e a taxa de transferência máxima de agendamento é inferior a 200 pods/s. Depois de usar KubeBrain , um código aberto de armazenamento de valor-chave de alto desempenho da Byte , o Kubernetes nativo pode suportar clusters maiores e a taxa de transferência de agendamento também é significativamente melhorada. Mas o desempenho da combinação Kubernetes + KubeBrain ainda é muito menor que o de Gödel. Gödel pode atingir um desempenho de 2.600 pods/s em um cluster de 5.000 nós. Mesmo com 20.000 nós, ainda existem cerca de 2.000 pods/s, o que é mais de 10 vezes o desempenho do agendador nativo do Kubernetes .

Para obter maior rendimento de agendamento, Gödel pode habilitar múltiplas instâncias. A figura à direita abaixo mostra de 1 a 6 instâncias do agendador sendo abertas em sequência em um cluster de 10.000 nós. A taxa de transferência aumenta gradualmente no estágio inicial e o valor de pico pode atingir aproximadamente 4.600 Pods/s. Mas quando o número de instâncias ultrapassa 5, o desempenho diminui. A razão é que quanto mais instâncias, mais conflitos entre as instâncias, o que afeta a eficiência do escalonamento. Portanto, não é que quanto mais instâncias de agendamento melhor.

Para tarefas offline com requisitos semânticos de Gang, o artigo compara Gödel com YARN e vulcão K8s comumente usados na comunidade de código aberto. Pode-se ver claramente que o desempenho do Gödel não é apenas muito superior ao do vulcão K8s, mas também quase o dobro do do YARN. Gödel suporta agendamento simultâneo de tarefas online e offline. O artigo simula o cenário quando diferentes negócios são misturados, alterando a proporção de tarefas offline enviadas no sistema. Pode-se observar que, independentemente da proporção de serviços off-line, o desempenho do Gödel é relativamente estável, com taxa de transferência mantida em torno de 2.000 Pods/s .

Para demonstrar por que Gödel tem uma melhoria de desempenho tão grande, o artigo se concentra na análise das contribuições de duas otimizações principais: " armazenamento em cache de nós candidatos " e " redução da taxa de varredura ". Conforme mostrado na figura abaixo, o experimento anterior foi repetido usando a versão completa do Gödel, Gödel com apenas a otimização do cache do nó ativada e Gödel com apenas a taxa de varredura reduzida ativada. Os resultados experimentais provaram que esses dois itens principais de otimização contribuíram sobre. 60% e 60 % respectivamente .

Além de usar benchmarks para avaliar o desempenho extremo de Gödel, o artigo também mostra a experiência real da ByteDance usando o agendador Gödel em um ambiente de produção, mostrando que Gödel tem boas capacidades em pooling de recursos, elasticidade e circulação.

A figura à esquerda abaixo descreve a alocação de recursos de tarefas online e offline em um determinado cluster dentro de um determinado período de tempo. No início, as tarefas online consomem poucos recursos e uma grande quantidade de recursos computacionais é alocada para tarefas offline com menor prioridade. Quando as tarefas online têm um aumento na demanda de recursos devido a um evento especial (emergência, pesquisa intensa, etc.), Gödel aloca imediatamente recursos para tarefas online, e a quantidade de alocação de recursos para tarefas offline diminui rapidamente. Quando o pico passa, as tarefas online começam a reduzir as solicitações de recursos e o agendador transfere novamente os recursos para tarefas offline. Por meio de pooling offline e transferência dinâmica de recursos, a ByteDance sempre pode manter uma alta utilização de recursos. Durante os horários de pico noturnos, a taxa média de recursos do cluster atinge mais de 60% , e também pode ser mantida em torno de 40% durante o estágio diurno.

Resumo e perspectivas futuras

O artigo apresenta o Gödel, um sistema de agendamento projetado e desenvolvido pela equipe de orquestração e agendamento da ByteDance para unificar pools de recursos offline. O sistema de agendamento oferece suporte ao agendamento simultâneo de tarefas on-line e off-line em clusters de escala ultragrande, oferece suporte ao pooling de recursos, elasticidade e circulação e possui alto rendimento de agendamento. Desde que o Gödel foi lançado em lotes no próprio data center da ByteDance em 2022, ele atendeu às necessidades de co-localização da maioria das empresas de campo, alcançando uma utilização média de recursos de mais de 60% durante o pico noturno e uma taxa de transferência de agendamento de aproximadamente 5.000 Pods/ é .

No futuro, a equipe de orquestração e agendamento continuará a promover a expansão e otimização do agendador Gödel, enriquecendo ainda mais a semântica de agendamento, melhorando a capacidade de resposta do sistema e reduzindo a probabilidade de conflitos em situações de múltiplas instâncias, ao mesmo tempo que otimiza o agendamento inicial. também construirá e fortalecerá as capacidades de reprogramação do sistema, design e desenvolvimento do Gödel Rescheduler. Através do trabalho colaborativo do Gödel Scheduler e Rescheduler, é alcançada uma alocação razoável de recursos do cluster ao longo de todo o ciclo.

O agendador Gödel é atualmente de código aberto . Sinceramente, damos as boas-vindas aos desenvolvedores e empresas da comunidade para se juntarem à comunidade e participarem da co-construção do projeto conosco. O endereço do projeto é: github.com/kubewharf/godel-scheduler !

Digitalize o código QR para ingressar na comunidade de código aberto ByteDance

Interpretação de papel SoCC: Como ByteDance implementa agendamento unificado de recursos em clusters de grande escala