Volcano scheduler
Introdução
Volcano é uma plataforma de processamento em lote baseada em Kubernetes. Ele fornece uma série de recursos necessários para aprendizado de máquina, aprendizado profundo, bioinformática, genômica e outras aplicações de Big data, como um poderoso complemento aos recursos do Kubernetes.
O Volcano fornece recursos de computação gerais, como agendamento de tarefas de alto desempenho, gerenciamento de chips heterogêneos e gerenciamento de execução de tarefas. Ele acessa as estruturas de computação para vários setores, como IA, Big data, gene e renderização, e agenda até 1000 pods por segundo para usuários finais, melhorando significativamente a eficiência de agendamento e a utilização de recursos.
O Volcano fornece agendamento de tarefas, gerenciamento de tarefas e gerenciamento de filas para aplicações de computação. Suas principais características são as seguintes:
- Diversas estruturas de computação, como TensorFlow e Spark, podem ser executadas no Kubernetes em contêineres. APIs comuns para tarefas de computação em lotes por meio de CRD, vários plug-ins e gerenciamento avançado do ciclo de vida da tarefa são fornecidos.
- Os recursos avançados de agendamento são fornecidos para computação em lote e cenários de computação de alto desempenho, incluindo agendamento de grupo, agendamento de prioridade preemptiva, embalagem, reserva de recursos e topologia de tarefas.
- As filas podem ser gerenciadas com eficiência para agendar tarefas. Recursos complexos de agendamento de tarefas, como prioridade de fila e filas de vários níveis, são suportados.
Volcano foi disponibilizado no GitHub em https://github.com/volcano-sh/volcano.
Instale e configure o complemento de Volcano em clusters do CCE. Para mais detalhes, consulte Agendamento de Volcano.
Ao usar o Volcano como um agendador, use-o para agendar todas as cargas de trabalho no cluster. Isso evita conflitos de agendamento de recursos causados pelo trabalho simultâneo de vários agendadores.
Instalar o complemento
- Efetue logon no console do CCE e clique no nome do cluster para acessar o console do cluster. Escolha Add-ons no painel de navegação, localize Volcano Scheduler à direita e clique em Install.
- Na página Install Add-on, configure as especificações.
Tabela 1 Configuração do Volcano Parâmetro
Descrição
Add-on Specifications
Selecione Single, Custom ou HA para Add-on Specifications.
Instances
Número de pods que serão criados para corresponder às especificações do complemento selecionado.
Se você selecionar Custom, poderá ajustar o número de pods conforme necessário.
Containers
As cotas de CPU e memória do contêiner permitidas para as especificações adicionais selecionadas.
Se você selecionar Custom, os valores recomendados para volcano-controller e volcano-scheduler serão os seguintes:
- Se o número de nós for menor que 100, mantenha a configuração padrão. As vCPUs solicitadas são 500m e o limite é 2000m. A memória solicitada é de 500 MiB e o limite é de 2000 MiB.
- Se o número de nós for maior que 100, aumente as vCPUs solicitadas em 500m e a memória solicitada em 1000 MiB cada vez que 100 nós (10.000 pods) forem adicionados. Aumente o limite de vCPU em 1500m e o limite de memória em 1000 MiB.
NOTA:
Fórmula recomendada para calcular o valor solicitado:
- VCPUs solicitadas: calcule o número de nós de destino multiplicado pelo número de pods de destino, execute a pesquisa de interpolação com base no número de nós no cluster multiplicado pelo número de pods de destino em Tabela 2 e arredonde o valor da solicitação e o valor limite mais próximo das especificações.
Por exemplo, para 2000 nós e 20.000 pods, número de nós de destino x número de pods de destino = 40 milhões, o que é próximo da especificação de 700/70.000 (número de nós do cluster x número de pods = 49 milhões). De acordo com a tabela a seguir, defina as vCPUs solicitadas como 4000m e o valor limite como 5500m.
- Memória solicitada: recomenda-se que 2,4 GiB de memória seja alocada a cada 1000 nós e 1 GiB de memória seja alocada a cada 10.000 pods. A memória solicitada é a soma desses dois valores. (O valor obtido pode ser diferente do valor recomendado em Tabela 2. Você pode usar qualquer um deles.)
Memória solicitada = número de nós de destino/1000 x 2,4 GiB + número de pods de destino/10.000 x 1 GiB
Por exemplo, para 2000 nós e 20 000 pods, a memória solicitada é de 6,8 GiB (2000/1000 x 2,4 GiB + 20.000/10.000 x 1 GiB).
- VCPUs solicitadas: calcule o número de nós de destino multiplicado pelo número de pods de destino, execute a pesquisa de interpolação com base no número de nós no cluster multiplicado pelo número de pods de destino em Tabela 2 e arredonde o valor da solicitação e o valor limite mais próximo das especificações.
Tabela 2 Valores recomendados para volcano-controller e volcano-scheduler Nós/pods em um cluster
vCPUs solicitadas (m)
Limite da vCPU (m)
Memória solicitada (MiB)
Limite de memória (MiB)
50/5000
500
2000
500
2000
100/10.000
1000
2500
1500
2500
200/20.000
1500
3000
2500
3500
300/30.000
2000
3500
3500
4500
400/40.000
2500
4000
4500
5500
500/50.000
3000
4500
5500
6500
600/60.000
3500
5000
6500
7500
700/70.000
4000
5500
7500
8500
- Configure parâmetros avançados de complemento.
Configure os parâmetros do Volcano scheduler padrão. Para mais detalhes, consulte Tabela 4.
colocation_enable: '' default_scheduler_conf: actions: 'allocate, backfill' tiers: - plugins: - name: 'priority' - name: 'gang' - name: 'conformance' - name: 'lifecycle' arguments: lifecycle.MaxGrade: 10 lifecycle.MaxScore: 200.0 lifecycle.SaturatedTresh: 1.0 lifecycle.WindowSize: 10 - plugins: - name: 'drf' - name: 'predicates' - name: 'nodeorder' - plugins: - name: 'cce-gpu-topology-predicate' - name: 'cce-gpu-topology-priority' - name: 'cce-gpu' - plugins: - name: 'nodelocalvolume' - name: 'nodeemptydirvolume' - name: 'nodeCSIscheduling' - name: 'networkresource' tolerations: - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 60 - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 60Tabela 3 Parâmetros avançados de configuração de Volcano Plug-in
Função
Descrição
Demonstração
colocation_enable
Se habilitar a implementação híbrida.
Valor:
- true: híbrida ativada
- false: híbrida desativada
Nenhuma
default_scheduler_conf
Usado para agendar pods. Consiste em uma série de ações e plug-ins e apresenta alta escalabilidade. Você pode especificar e implementar ações e plug-ins com base em seus requisitos.
Consiste em actions e tiers.
- actions: define os tipos e a sequência de ações a serem executadas pelo agendador.
- tiers: configura a lista de plugins.
Nenhuma
actions
Ações a serem executadas em cada fase de programação. A sequência de ação configurada é a sequência de execução do agendador. Para obter detalhes, consulte Ações.
O agendador percorre todas as tarefas a serem programadas e executa ações como enqueue, allocate, preempt, e backfill na sequência configurada para encontrar o nó mais apropriado para cada tarefa.
As seguintes opções são compatíveis:
- enqueue usa uma série de algoritmos de filtragem para filtrar as tarefas a serem agendadas e as envia para a fila para aguardar o agendamento. Após essa ação, o status da tarefa muda de pending para inqueue.
- allocate: seleciona o nó mais adequado com base em uma série de algoritmos de pré-seleção e seleção.
- preempt: executa o agendamento de preempção para tarefas com prioridades mais altas na mesma fila com base em regras de prioridade.
- backfill: agenda as tarefas pendentes o máximo possível para maximizar a utilização dos recursos do nó.
actions: 'allocate, backfill'
NOTA:Ao configurar actions, use preempt ou enqueue.
plugins
Detalhes de implementação de algoritmos em ações com base em diferentes cenários. Para detalhes, veja Plug-ins.
Para mais detalhes, consulte Tabela 4.
Nenhuma
tolerations
Tolerância do complemento a manchas de nós.
Por padrão, o complemento pode ser executado em nós com o node.kubernetes.io/not-ready ou node.kubernetes.io/unreachable e o valor do efeito de mancha é NoExecute, mas será despejado em 60 segundos.
tolerations: - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 60 - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 60Tabela 4 Plug-ins suportados Plug-in
Função
Descrição
Demonstração
binpack
Programe pods para nós com alto uso de recursos (não alocando pods para nós carregados de luz) para reduzir fragmentos de recursos.
arguments:
- binpack.weight: peso do plug-in binpack.
- binpack.cpu: proporção de CPUs para todos os recursos. O valor padrão do parâmetro é 1.
- binpack.memory: proporção de recursos de memória para todos os recursos. O valor padrão do parâmetro é 1.
- binpack.resources: outros tipos de recursos personalizados solicitados pelo pod, por exemplo, nvidia.com/gpu. Vários tipos podem ser configurados e separados por vírgulas (,).
- binpack.resources.<your_resource>: peso do seu recurso personalizado em todos os recursos. Vários tipos de recursos podem ser adicionados. <your_resource> indica o tipo de recurso definido em binpack.resources, por exemplo, binpack.resources.nvidia.com/gpu.
- plugins: - name: binpack arguments: binpack.weight: 10 binpack.cpu: 1 binpack.memory: 1 binpack.resources: nvidia.com/gpu, example.com/foo binpack.resources.nvidia.com/gpu: 2 binpack.resources.example.com/foo: 3conformance
Evite que pods principais, como os pods no namespace kube-system sejam antecipados.
Nenhuma
- plugins: - name: 'priority' - name: 'gang' enablePreemptable: false - name: 'conformance'lifecycle
Ao coletar estatísticas sobre regras de escala de serviço, os pods com ciclos de vida semelhantes são preferencialmente programados para o mesmo nó. Com a capacidade de dimensionamento horizontal do Autoscaler, os recursos podem ser rapidamente dimensionados e liberados, reduzindo custos e melhorando a utilização de recursos.
1. Coleta estatísticas sobre o ciclo de vida dos pods na carga de serviço e programa pods com ciclos de vida semelhantes para o mesmo nó.
2. Para um cluster configurado com uma política de dimensionamento automático, ajuste a anotação de reduzir do nó para reduzir preferencialmente no nó com baixo uso.
arguments:- lifecycle.WindowSize: o valor é um inteiro maior ou igual a 1 e o padrão é 10.
Registre o número de vezes que o número de réplicas é alterado. Se a carga mudar regularmente e periodicamente, diminua o valor. Se a carga for alterada de forma irregular e o número de réplicas for alterado com frequência, aumente o valor. Se o valor for muito grande, o período de aprendizado é prolongado e muitos eventos são registrados.
- lifecycle.MaxGrade: o valor é um inteiro maior ou igual a 3 e o padrão é 3.
Ele indica níveis de réplicas. Por exemplo, se o valor for definido como 3, as réplicas serão classificadas em três níveis. Se a carga mudar regularmente e periodicamente, diminua o valor. Se a carga mudar de forma irregular, aumente o valor. Definir um valor excessivamente pequeno pode resultar em previsões de ciclo de vida imprecisas.
- lifecycle.MaxScore: número de ponto flutuante float64. O valor deve ser superior ou igual a 50.0. O valor padrão é 200.0.
Pontuação máxima (equivalente ao peso) do plug-in do ciclo de vida.
- lifecycle.SaturatedTresh: número de ponto flutuante float64. Se o valor for menor que 0,5, use 0.5. Se o valor for maior que 1, use 1. O valor padrão é 0.8.
Limite para determinar se o uso do nó é muito alto. Se o uso do nó exceder o limite, o agendador preferencialmente agendará tarefas para outros nós.
- plugins: - name: priority - name: gang enablePreemptable: false - name: conformance - name: lifecycle arguments: lifecycle.MaxGrade: 10 lifecycle.MaxScore: 200.0 lifecycle.SaturatedTresh: 1.0 lifecycle.WindowSize: 10NOTA:- Para nós que não desejam ser reduzidos, marque-os manualmente como nós de período longo e adicione a anotação volcano.sh/long-lifecycle-node: true para eles. Para um nó não marcado, o plug-in de ciclo de vida marca automaticamente o nó com base no ciclo de vida da carga no nó.
- O valor padrão de MaxScore é 200.0, que é o dobro do peso de outros plug-ins. Quando o plug-in do ciclo de vida não tem efeito óbvio ou conflitos com outros plug-ins, desabilite outros plug-ins ou aumente o valor do MaxScore.
- Depois que o agendador é reiniciado, o plug-in do ciclo de vida precisa gravar novamente a alteração de carga. O efeito de agendamento ideal pode ser alcançado somente após vários períodos de estatísticas serem coletados.
Gang
Considere um grupo de pods como um todo para alocação de recursos. Este plug-in verifica se o número de pods agendados em uma tarefa atende aos requisitos mínimos para a execução da tarefa. Se sim, todos os pods na tarefa serão agendados. Se não, os pods não serão agendados.
NOTA:Se uma política de agendamento de grupo for usada, se os recursos restantes no cluster forem maiores ou iguais à metade do número mínimo de recursos para a execução de uma tarefa, mas menores do que o mínimo de recursos para a execução da tarefa, as expansões do Autoscaler não serão acionadas.
- enablePreemptable:
- true: preempção ativada
- false: preempção desativada
- enableJobStarving:
- true: os recursos são antecipados com base na configuração minAvailable das tarefas.
- false: os recursos são antecipados com base em réplicas de tarefa.
NOTA:- O valor padrão de minAvailable para cargas de trabalho nativas do Kubernetes (como Implementações) é 1. É uma boa prática definir enableJobStarving como false.
- Em cenários de IA e Big data, você pode especificar o valor de minAvailable ao criar um vcjob. É uma boa prática definir enableJobStarving como true.
- Nas versões do Volcano anteriores à v1.11.5, enableJobStarving é definido como true por padrão. Em versões do Volcano posteriores à v1.11.5, enableJobStarving é definido como false por padrão.
- plugins: - name: priority - name: gang enablePreemptable: false enableJobStarving: false - name: conformancepriority
Agendamento baseado em prioridades de carregamento personalizadas.
Nenhuma
- plugins: - name: priority - name: gang enablePreemptable: false - name: conformanceovercommit
Os recursos em um cluster são programados após serem acumulados em um determinado múltiplo para melhorar a eficiência do enfileiramento da carga de trabalho. Se todas as cargas de trabalho forem Implementações, remova este plug-in ou defina o fator de aumento para 2.0.
NOTA:Este plug-in é suportado no Volcano 1.6.5 e versões posteriores.
arguments:
- overcommit-factor: fator de inflação, cujo valor padrão é 1.2.
- plugins: - name: overcommit arguments: overcommit-factor: 2.0drf
O algoritmo de agendamento Dominant Resource Fairness (DRF), que agenda tarefas com base em seu compartilhamento de recursos dominante. Tarefas com uma parcela de recursos menor serão agendadas com uma prioridade mais alta.
Nenhuma
- plugins: - name: 'drf' - name: 'predicates' - name: 'nodeorder'
predicates
Determine se uma tarefa está vinculada a um nó usando uma série de algoritmos de avaliação, como afinidade nó/pod, tolerância a manchas, repetição de nó, limites de volume e correspondência de zona de volume.
Nenhuma
- plugins: - name: 'drf' - name: 'predicates' - name: 'nodeorder'
nodeorder
Um algoritmo comum para selecionar nós. Os nós são pontuados na alocação de recursos simulada para encontrar o nó mais adequado para a tarefa atual.
Parâmetros de pontuação:
- nodeaffinity.weight: os pods são agendados com base na afinidade do nó. O padrão deste parâmetro é 2.
- podaffinity.weight: os pods são agendados com base na afinidade do pod. O padrão deste parâmetro é 2.
- leastrequested.weight: os pods são programados para o nó com os recursos menos solicitados. O padrão deste parâmetro é 1.
- balancedresource.weight: os pods são agendados para o nó com alocação de recursos balanceada. O padrão deste parâmetro é 1.
- mostrequested.weight: os pods são agendados para o nó com os recursos mais solicitados. O padrão deste parâmetro é 0.
- tainttoleration.weight: os pods são programados para o nó com uma alta tolerância a manchas. O padrão deste parâmetro é 3.
- imagelocality.weight: os pods são agendados para o nó onde existem as imagens necessárias. O padrão deste parâmetro é 1.
- selectorspread.weight: os pods são agendados uniformemente para diferentes nós. O padrão deste parâmetro é 0.
- podtopologyspread.weight: os pods são programados com base na topologia do pod. O padrão deste parâmetro é 2.
- plugins: - name: nodeorder arguments: leastrequested.weight: 1 mostrequested.weight: 0 nodeaffinity.weight: 2 podaffinity.weight: 2 balancedresource.weight: 1 tainttoleration.weight: 3 imagelocality.weight: 1 podtopologyspread.weight: 2cce-gpu-topology-predicate
Algoritmo de pré-seleção de agendamento de topologia de GPU
Nenhuma
- plugins: - name: 'cce-gpu-topology-predicate' - name: 'cce-gpu-topology-priority' - name: 'cce-gpu'
cce-gpu-topology-priority
Algoritmo de prioridade de agendamento de topologia de GPU
Nenhuma
- plugins: - name: 'cce-gpu-topology-predicate' - name: 'cce-gpu-topology-priority' - name: 'cce-gpu'
cce-gpu
Alocação de recursos de GPU que suporta configurações de GPU decimais trabalhando com o complemento gpu.
NOTA:- O plug-in da versão 1.10.5 ou posterior não suporta este complemento. Use xGPU em vez disso.
- O pré-requisito para configurar GPUs decimais é que os nós da GPU no cluster estejam no modo compartilhado. Para obter detalhes sobre como verificar se o compartilhamento de GPU está desabilitado no cluster, consulte o parâmetro enable-gpu-share em Gerenciamento de configuração de cluster.
Nenhuma
- plugins: - name: 'cce-gpu-topology-predicate' - name: 'cce-gpu-topology-priority' - name: 'cce-gpu'
numa-aware
Agendamento de afinidade NUMA. Para obter detalhes, consulte Agendamento de afinidade NUMA.
arguments:
- weight: peso do plug-in numa-aware
- plugins: - name: 'nodelocalvolume' - name: 'nodeemptydirvolume' - name: 'nodeCSIscheduling' - name: 'networkresource' arguments: NetworkType: vpc-router - name: numa-aware arguments: weight: 10networkresource
O nó de requisito da ENI pode ser pré-selecionado e filtrado. Os parâmetros são transferidos pelo CCE e não precisam ser configurados manualmente.
arguments:
- NetworkType: tipo de rede (eni ou vpc-router)
- plugins: - name: 'nodelocalvolume' - name: 'nodeemptydirvolume' - name: 'nodeCSIscheduling' - name: 'networkresource' arguments: NetworkType: vpc-routernodelocalvolume
Filtrar nós que não atendem aos requisitos de volume local.
Nenhuma
- plugins: - name: 'nodelocalvolume' - name: 'nodeemptydirvolume' - name: 'nodeCSIscheduling' - name: 'networkresource'
nodeemptydirvolume
Filtrar nós que não atendam aos requisitos de vazioDir.
Nenhuma
- plugins: - name: 'nodelocalvolume' - name: 'nodeemptydirvolume' - name: 'nodeCSIscheduling' - name: 'networkresource'
nodeCSIscheduling
Filtrar nós com mau funcionamento do Everest.
Nenhuma
- plugins: - name: 'nodelocalvolume' - name: 'nodeemptydirvolume' - name: 'nodeCSIscheduling' - name: 'networkresource'
- Configure as políticas de agendamento para o complemento.
- As políticas de agendamento não entram em vigor em instâncias complementares do tipo DaemonSet.
- Ao configurar a implementação de várias AZs ou a afinidade de nó, verifique se há nós que atendem à política de agendamento e se os recursos são suficientes no cluster. Caso contrário, o complemento não pode ser executado.
Tabela 5 Configurações para programação de complementos Parâmetro
Descrição
Implementação de várias AZs
- Preferred: os pods de implantação do complemento serão agendados preferencialmente para nós em diferentes AZs. Se todos os nós no cluster forem implementados na mesma AZ, os pods serão agendados para essa AZ.
- Forcible: os pods de implementação do complemento serão forçosamente agendados para nós em diferentes AZs. Se houver menos AZs do que pods, os pods extras não funcionarão.
Node Affinity
- Incompatibility: a afinidade de nó está desabilitada para o complemento.
- Node Affinity: especifique os nós em que o complemento é implementado. Se você não especificar os nós, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão.
- Specified Node Pool Scheduling: especifique o pool de nós em que o complemento é implementado. Se você não especificar o pool de nós, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão.
- Custom Policies: insira os rótulos dos nós em que o complemento será implementado para políticas de agendamento mais flexíveis. Se você não especificar rótulos de nó, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão.
Se várias políticas de afinidade personalizadas estiverem configuradas, certifique-se de que existem nós que atendam a todas as políticas de afinidade no cluster. Caso contrário, o complemento não pode ser executado.
Taints and Tolerations
O uso de manchas e tolerâncias permite (não forçosamente) que a Implementação do complemento seja agendada para um nó com as manchas correspondentes e controla as políticas de despejo de Implementação depois que o nó onde a Implementação está localizada é contaminado.
O complemento adiciona a política de tolerância padrão para as manchas node.kubernetes.io/not-ready e node.kubernetes.io/unreachable, respectivamente. A janela de tempo de tolerância é 60s.
Para mais detalhes, consulte Manchas e tolerâncias.
- Clique em Install.
Componentes
|
Componente |
Descrição |
Tipo de recurso |
|---|---|---|
|
volcano-scheduler |
Agendar pods. |
Implementação |
|
volcano-controller |
Sincronizar CRDs. |
Implementação |
|
volcano-admission |
Servidor Webhook, que verifica e modifica recursos como pods e tarefas |
Implementação |
|
volcano-agent |
Agente híbrido nativo da nuvem, que é usado para garantia de QoS de nó, intermitência de CPU e superassinatura de recursos dinâmicos |
DaemonSet |
|
resource-exporter |
Relatar as informações de topologia NUMA dos nós. |
DaemonSet |
Modificar as configurações do volcano-scheduler usando o console
volcano-scheduler é o componente responsável pelo agendamento do pod. Consiste em uma série de ações e plug-ins. As ações devem ser executadas em todas as etapas. Plug-ins fornecem os detalhes do algoritmo de ação em diferentes cenários. volcano-scheduler é altamente escalável. Você pode especificar e implementar ações e plug-ins com base em seus requisitos.
Volcano permite que você configure o agendador durante a instalação, atualização e edição. A configuração será sincronizada com o volcano-scheduler-configmap.
Esta seção descreve como configurar o volcano-scheduler.
Somente o Volcano da v1.7.1 e posteriores suportam essa função. Na nova página do plug-in, opções como plugins.eas_service e resource_exporter_enable são substituídas por default_scheduler_conf.
Efetue logon no console do CCE e clique no nome do cluster para acessar o console do cluster. Escolha Add-ons no painel de navegação. À direita da página, localize Volcano Scheduler e clique em Install ou Upgrade. Na área Parameters, configure os parâmetros do Volcano.
- Usar resource_exporter:
{ "ca_cert": "", "default_scheduler_conf": { "actions": "allocate, backfill", "tiers": [ { "plugins": [ { "name": "priority" }, { "name": "gang" }, { "name": "conformance" } ] }, { "plugins": [ { "name": "drf" }, { "name": "predicates" }, { "name": "nodeorder" } ] }, { "plugins": [ { "name": "cce-gpu-topology-predicate" }, { "name": "cce-gpu-topology-priority" }, { "name": "cce-gpu" }, { "name": "numa-aware" # add this also enable resource_exporter } ] }, { "plugins": [ { "name": "nodelocalvolume" }, { "name": "nodeemptydirvolume" }, { "name": "nodeCSIscheduling" }, { "name": "networkresource" } ] } ] }, "server_cert": "", "server_key": "" }depois que esta função estiver ativada, você pode usar as funções de numa-aware e resource_exporter.
- Usar eas_service:
{ "ca_cert": "", "default_scheduler_conf": { "actions": "allocate, backfill", "tiers": [ { "plugins": [ { "name": "priority" }, { "name": "gang" }, { "name": "conformance" } ] }, { "plugins": [ { "name": "drf" }, { "name": "predicates" }, { "name": "nodeorder" } ] }, { "plugins": [ { "name": "cce-gpu-topology-predicate" }, { "name": "cce-gpu-topology-priority" }, { "name": "cce-gpu" }, { "name": "eas", "custom": { "availability_zone_id": "", "driver_id": "", "endpoint": "", "flavor_id": "", "network_type": "", "network_virtual_subnet_id": "", "pool_id": "", "project_id": "", "secret_name": "eas-service-secret" } } ] }, { "plugins": [ { "name": "nodelocalvolume" }, { "name": "nodeemptydirvolume" }, { "name": "nodeCSIscheduling" }, { "name": "networkresource" } ] } ] }, "server_cert": "", "server_key": "" } - Usar ief:
{ "ca_cert": "", "default_scheduler_conf": { "actions": "allocate, backfill", "tiers": [ { "plugins": [ { "name": "priority" }, { "name": "gang" }, { "name": "conformance" } ] }, { "plugins": [ { "name": "drf" }, { "name": "predicates" }, { "name": "nodeorder" } ] }, { "plugins": [ { "name": "cce-gpu-topology-predicate" }, { "name": "cce-gpu-topology-priority" }, { "name": "cce-gpu" }, { "name": "ief", "enableBestNode": true } ] }, { "plugins": [ { "name": "nodelocalvolume" }, { "name": "nodeemptydirvolume" }, { "name": "nodeCSIscheduling" }, { "name": "networkresource" } ] } ] }, "server_cert": "", "server_key": "" }
Reter as configurações originais de volcano-scheduler-configmap
Se você quiser usar a configuração original depois que o plug-in for atualizado, execute as seguintes etapas:
- Verifique e faça backup da configuração original do volcano-scheduler-configmap.
Exemplo:
# kubectl edit cm volcano-scheduler-configmap -n kube-system apiVersion: v1 data: default-scheduler.conf: |- actions: "enqueue, allocate, backfill" tiers: - plugins: - name: priority - name: gang - name: conformance - plugins: - name: drf - name: predicates - name: nodeorder - name: binpack arguments: binpack.cpu: 100 binpack.weight: 10 binpack.resources: nvidia.com/gpu binpack.resources.nvidia.com/gpu: 10000 - plugins: - name: cce-gpu-topology-predicate - name: cce-gpu-topology-priority - name: cce-gpu - plugins: - name: nodelocalvolume - name: nodeemptydirvolume - name: nodeCSIscheduling - name: networkresource - Insira o conteúdo personalizado na área Parameters no console.
{ "ca_cert": "", "default_scheduler_conf": { "actions": "enqueue, allocate, backfill", "tiers": [ { "plugins": [ { "name": "priority" }, { "name": "gang" }, { "name": "conformance" } ] }, { "plugins": [ { "name": "drf" }, { "name": "predicates" }, { "name": "nodeorder" }, { "name": "binpack", "arguments": { "binpack.cpu": 100, "binpack.weight": 10, "binpack.resources": "nvidia.com/gpu", "binpack.resources.nvidia.com/gpu": 10000 } } ] }, { "plugins": [ { "name": "cce-gpu-topology-predicate" }, { "name": "cce-gpu-topology-priority" }, { "name": "cce-gpu" } ] }, { "plugins": [ { "name": "nodelocalvolume" }, { "name": "nodeemptydirvolume" }, { "name": "nodeCSIscheduling" }, { "name": "networkresource" } ] } ] }, "server_cert": "", "server_key": "" }
Quando esta função for usada, o conteúdo original em volcano-scheduler-configmap será sobrescrito. Portanto, você deve verificar se o volcano-scheduler-configmap foi modificado durante a atualização. Se sim, sincronize a modificação com a página de atualização.
Desinstalar o complemento de Volcano
Depois que o complemento for desinstalado, todos os recursos personalizados do Volcano (Tabela 7) serão excluídos, incluindo os recursos criados. Reinstalar o complemento não herdará nem restaurará as tarefas antes da desinstalação. É uma boa prática desinstalar o complemento do Volcano somente quando nenhum recurso personalizado do Volcano estiver sendo usado no cluster.
|
Item |
Grupo de API |
Versão da API |
Nível de recurso |
|---|---|---|---|
|
Comando |
bus.volcano.sh |
v1alpha1 |
Namespaced |
|
Job |
batch.volcano.sh |
v1alpha1 |
Namespaced |
|
Numatopology |
nodeinfo.volcano.sh |
v1alpha1 |
Cluster |
|
PodGroup |
scheduling.volcano.sh |
v1beta1 |
Namespaced |
|
Queue |
scheduling.volcano.sh |
v1beta1 |
Cluster |
