Autor: You Yi, Lu Feng
fundo
O Koordinator é um projeto de código aberto concebido e nascido com base nos anos de experiência acumulada do Alibaba no campo de agendamento de contêineres. Ele pode melhorar o desempenho do contêiner e reduzir os custos de recursos do cluster. Por meio de recursos técnicos, como combinação de departamentos, criação de perfil de recursos e otimização de agendamento, ele pode melhorar a eficiência operacional e a confiabilidade de cargas de trabalho sensíveis a atrasos e trabalhos em lote, além de otimizar a eficiência do uso de recursos do cluster.
Desde seu lançamento em abril de 2022, o Koordinator lançou 10 iterações até agora, atraindo um grande número de engenheiros de destaque, incluindo Alibaba, Xiaomi, Xiaohongshu, iQiyi, 360, Youzan, etc. Com a chegada da primavera de 2023, o Koordinator também inaugurou seu primeiro aniversário e estamos felizes em anunciar a você que o Koordinator v1.2 foi lançado oficialmente. Na nova versão, o Koordinator oferece suporte à função de reserva de recursos do nó e é compatível com a estratégia de reprogramação da comunidade K8s. Ao mesmo tempo, adiciona suporte ao ambiente AMD L3 Cache e isolamento de largura de banda de memória no lado autônomo.
Na nova versão, um total de 12 novos desenvolvedores participaram da construção da comunidade Koordiantor, eles são @Re-Grh, @chengweiv5, @kingeasternsun, @shelwinnn, @yuexian1234, @Syulin7, @tzzcfrank, @Dengerwei, @complone , @AlbeeSo, @xigang, @leason00 , agradecemos aos desenvolvedores acima por suas contribuições e participação.
Conheça os novos recursos com antecedência
Reserva de recursos do nó
Existem várias formas de aplicativos incluídos no cenário híbrido. Além dos contêineres nativos da nuvem, também existem muitos aplicativos que ainda não foram conteinerizados. Esses aplicativos serão executados em conjunto com os contêineres K8s na forma de processos na máquina host . A fim de reduzir a competição de recursos entre os aplicativos K8s e outros tipos de aplicativos no lado do nó, o Koordinator oferece suporte à reserva de alguns recursos para que não participe do agendamento de recursos do agendador ou da alocação de recursos no lado do nó, obtendo o efeito de separação de recursos. Na versão v1.2, Koordiantor já suporta a reserva de CPU e dimensões de recursos de memória, e permite especificar diretamente o número de CPU reservado, como segue.
Declaração de reserva de recurso do nó
A quantidade de recursos a serem reservados ou o número de CPU específico pode ser configurado no Node, por exemplo, da seguinte forma:
apiVersion: v1
kind: Node
metadata:
name: fake-node
annotations: # specific 5 cores will be calculated, e.g. 0, 1, 2, 3, 4, and then those core will be reserved.
node.koordinator.sh/reservation: '{"resources":{"cpu":"5"}}'
---
apiVersion: v1
kind: Node
metadata:
name: fake-node
annotations: # the cores 0, 1, 2, 3 will be reserved.
node.koordinator.sh/reservation: '{"reservedCPUs":"0-3"}'
Quando o componente autônomo Koordlet relatar as informações de topologia do recurso do nó, ele atualizará o número específico da CPU reservada para a anotação do objeto NodeResourceTopology.
Agendamento e reagendamento da adaptação da cena
No processo de alocação de recursos, o escalonador envolve a verificação de recursos em várias situações, incluindo gerenciamento de cotas, verificação de capacidade de nó, verificação de topologia de CPU, etc. Esses cenários precisam aumentar a consideração de recursos reservados de nó, por exemplo, quando o escalonador calcula o Capacidade da CPU de um nó, ela precisa deduzir os recursos reservados pelo nó.
cpus(alloc) = cpus(total) - cpus(allocated) - cpus(kubeletReserved) - cpus(nodeAnnoReserved)
Além disso, o cálculo de recursos sobrevendidos no mix de lote também precisa deduzir essa parte dos recursos e, considerando o consumo de recursos de alguns processos do sistema no nó, o Koord-Manager levará o valor máximo de reserva de nó e uso do sistema durante o cálculo ,Especificamente:
reserveRatio = (100-thresholdPercent) / 100.0
node.reserved = node.alloc * reserveRatio
system.used = max(node.used - pod.used, node.anno.reserved)
Node(BE).Alloc = Node.Alloc - Node.Reserved - System.Used - Pod(LS).Used
Para o reagendamento, cada estratégia de plug-in precisa perceber a quantidade de recursos reservados do nó em cenários como capacidade do nó e cálculo da taxa de utilização. Além disso, se já houver contêineres ocupando os recursos reservados do nó, o reescalonamento precisa considerar expulsão para garantir a capacidade do nó Seja gerenciado adequadamente para evitar a competição por recursos. Apoiaremos esta parte das funções relacionadas ao reagendamento em versões subsequentes, e os fãs são bem-vindos a participar da construção conjunta.
Gerenciamento de recursos autônomo
Para Pods do tipo LS, o componente Koordlet autônomo calculará dinamicamente o pool de CPU compartilhada de acordo com a alocação da CPU, e os núcleos de CPU reservados pelo nó serão excluídos para garantir o isolamento dos pods do tipo LS e outros não conteinerizados recursos do processo. Ao mesmo tempo, para políticas de QoS relacionadas a autônomos, como a política de supressão CPUSuppress, a quantidade de recursos reservados será levada em consideração ao calcular a utilização do nó.
suppress(BE) := node.Total * SLOPercent - pod(LS).Used - max(system.Used, node.anno.reserved)
Para obter uma descrição detalhada da função de reserva de recursos do nó, consulte a introdução no documento de design, consulte: https://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/scheduling/20221227- node-resource -reservation.md
Compatível com as políticas de reagendamento da comunidade
Graças à estrutura cada vez mais madura do Koordinator Descheduler, na versão Koordinator v1.2, ao introduzir um mecanismo de adaptação de interface, ele pode ser perfeitamente compatível com os plug-ins existentes do Kubernetes Desceheduler. Ao usá-lo, você só precisa implantar o Koordinator Descheduler que é Todas as funções até upstream podem ser usadas.
Em termos de implementação, o Koordinator Descheduler não faz nenhuma alteração intrusiva ao importar código upstream, garantindo total compatibilidade com todos os plug-ins upstream, configurações de parâmetros e suas estratégias operacionais. Ao mesmo tempo, o Koordinator permite que os usuários especifiquem evictors aprimorados para plug-ins upstream, reutilizando políticas de segurança como reserva de recursos, garantia de disponibilidade de carga de trabalho e controle de fluxo global fornecido pelo Koordinator.
Lista de plugins compatíveis:
- HighNodeUtilization
- LowNodeUtilization
- PodLifeTime
- RemoveFailedPods
- Remover Duplicatas
- RemovePodsHavingTooManyRestarts
- RemovePodsViolatingInterPodAntiAffinity
- RemovePodsViolatingNodeAffinity
- RemovePodsViolatingNodeTaints
- RemovePodsViolatingTopologySpreadConstraint
- PadrãoEvictor
Ao usá-lo, você pode consultar a seguinte configuração, tomando como exemplo RemovePodsHavingTooManyRestarts:
apiVersion: descheduler/v1alpha2
kind: DeschedulerConfiguration
clientConnection:
kubeconfig: "/Users/joseph/asi/koord-2/admin.kubeconfig"
leaderElection:
leaderElect: false
resourceName: test-descheduler
resourceNamespace: kube-system
deschedulingInterval: 10s
dryRun: true
profiles:
- name: koord-descheduler
plugins:
evict:
enabled:
- name: MigrationController
deschedule:
enabled:
- name: RemovePodsHavingTooManyRestarts
pluginConfig:
- name: RemovePodsHavingTooManyRestarts
args:
apiVersion: descheduler/v1alpha2
kind: RemovePodsHavingTooManyRestartsArgs
podRestartThreshold: 10
Recursos aprimorados de reserva e agendamento de recursos
O Koordinator introduziu o mecanismo de reserva em uma versão anterior, que ajuda a resolver o problema do determinismo de entrega de recursos, reservando recursos e reutilizando-os para pods com características especificadas. Por exemplo, no cenário de reprogramação, espera-se que o Pod que é despejado tenha recursos para usar, em vez de não ter recursos disponíveis após ser despejado, causando problemas de estabilidade; ou quando a expansão da capacidade é necessária, algumas plataformas PaaS esperam primeiro determine se os recursos para agendamento e orquestração de aplicativos são atendidos e, em seguida, decida se deseja expandir ou fazer algum trabalho preparatório com antecedência.
A reserva do coordenador é definida pelo CRD. Cada objeto de reserva será falsificado como um Pod no koord-scheduler para agendamento. Esse Pod é chamado de Reserve Pod. O Reserve Pod pode reutilizar os plug-ins de agendamento e os plug-ins de pontuação existentes para encontrar nós adequados . , e finalmente ocupam os recursos correspondentes no estado interno do escalonador. Quando uma reserva é criada, ela especifica em quais Pods os recursos reservados serão usados no futuro. Você pode especificar um Pod específico ou alguns objetos de carga de trabalho ou Pods com determinados rótulos. Quando esses Pods são agendados pelo koord-scheduler, o agendador encontrará o objeto Reservation que pode ser usado pelo Pod e usará os recursos da Reserva primeiro. E o Status da Reserva registrará qual Pod é usado, e as Anotações do Pod também registrarão qual Reserva é usada. Depois que a Reserva for usada, o estado interno será automaticamente limpo para garantir que outros Pods não sejam desagendáveis devido à Reserva.
No Koordinator v1.2, fizemos muitas otimizações. Em primeiro lugar, deixamos de lado a restrição de que somente os recursos detidos pela Reserva podem ser utilizados, permitindo que o limite de recursos da Reserva seja ultrapassado, podendo ser utilizados os recursos reservados pela Reserva, e os recursos remanescentes no nó também pode ser usado. Além disso, estendemos o Kubernetes Scheduler Framework de maneira não intrusiva para oferecer suporte à reserva de recursos refinados, ou seja, núcleos de CPU e dispositivos de GPU podem ser reservados. Também modificamos o comportamento padrão de que a Reserva pode ser reaproveitada para AllocateOnce, ou seja, assim que a Reserva for utilizada por um Pod, a Reserva será descartada. Essa alteração é baseada na consideração de que AllocateOnce pode cobrir melhor a maioria dos cenários, portanto, como comportamento padrão, será mais fácil para todos usarem.
Suporta Cache L3 e isolamento de largura de banda de memória em ambiente AMD
Na versão v0.3.0, o Koordiantor já suportava o Cache L3 e o isolamento da largura de banda de memória do ambiente Intel.Na última versão 1.2.0, adicionamos suporte para o ambiente AMD.
O cache L3 do kernel Linux e os recursos de isolamento de largura de banda de memória fornecem uma interface resctrl unificada que suporta ambientes Intel e AMD. está no formato de valor absoluto, detalhes a seguir.
# Intel Format
# resctrl schema
L3:0=3ff;1=3ff
MB:0=100;1=100
# AMD Format
# resctrl schema
L3:0=ffff;1=ffff;2=ffff;3=ffff;4=ffff;5=ffff;6=ffff;7=ffff;8=ffff;9=ffff;10=ffff;11=ffff;12=ffff;13=ffff;14=ffff;15=ffff
MB:0=2048;1=2048;2=2048;3=2048;4=2048;5=2048;6=2048;7=2048;8=2048;9=2048;10=2048;11=2048;12=2048;13=2048;14=2048;15=2048
O formato da interface consiste em duas partes, L3 representa o "caminho" disponível do soquete ou CCD correspondente, expresso em formato de dados hexadecimais, cada bit representa um caminho; MB representa a memória que o soquete ou CCD correspondente pode usar Faixa de largura de banda, Intel a faixa selecionável é de 0~100 formato de porcentagem, AMD corresponde ao formato de valor absoluto, a unidade é Gb/s, 2048 significa ilimitado. O Koordiantor fornece uniformemente uma interface em formato de porcentagem e detecta automaticamente se o ambiente do nó é AMD e determina o formato preenchido na interface resctrl.
apiVersion: v1
kind: ConfigMap
metadata:
name: slo-controller-config
namespace: koordinator-system
data:
resource-qos-config: |-
{
"clusterStrategy": {
"lsClass": {
"resctrlQOS": {
"enable": true,
"catRangeStartPercent": 0,
"catRangeEndPercent": 100,
"MBAPercent": 100
}
},
"beClass": {
"resctrlQOS": {
"enable": true,
"catRangeStartPercent": 0,
"catRangeEndPercent": 30,
"MBAPercent": 100
}
}
}
}
Outras funções
Através da página da versão v1.2 [ 1 ] , você pode ver as novidades incluídas em mais versões.
Plano futuro
Na próxima versão, o Koordiantor se concentra nas seguintes funções, incluindo:
- Agendamento com reconhecimento de topologia de hardware, que considera de forma abrangente o relacionamento topológico de várias dimensões de recursos, como CPU de nó, memória e GPU, e executa a otimização de agendamento dentro do cluster.
- Melhorias na observabilidade e rastreabilidade do reagendador.
- Aprimoramentos nos recursos de agendamento de recursos da GPU.
Koordinator é uma comunidade aberta. Os entusiastas nativos da nuvem são muito bem-vindos para participar da co-construção de várias maneiras. Seja você iniciante ou proficiente no campo da nuvem nativa, estamos ansiosos para ouvir sua voz! Você também pode usar o número do grupo de pesquisa DingTalk: 33383887 para ingressar no grupo DingTalk da comunidade Koordinator:
Links Relacionados:
[1] versão v1.2
https://github.com/koordinator-sh/koordinator/releases/tag/v1.2.0
Clique aqui para conhecer o projeto Koordinator agora!