Please enable JavaScript.
Coggle requires JavaScript to display documents.
Deep Dive Kubernetes Architeture (Scheduler Part. 2) - Coggle Diagram
Deep Dive Kubernetes Architeture (Scheduler Part. 2)
Multiple Schedulers
No Kubernetes, um scheduler funciona de forma semelhante a um operador ou controlador. Ele observa todos os pods e nós, encontra os nós mais adequados para os pods recém-criados e vincula as informações do nó ao pod spec.nodeName.
Podemos executar vários desses schedullers simultaneamente.
Instruímos o Kubernetes sobre qual scheduler usar para um pod com base em spec.schedulerName na especificação do pod.
O nome padrão do scheduler do Kubernetes é default-scheduler
Podemos usar o Kind KubeSchedulerConfiguration para cadastrar o novo scheduler
Problemas
Podemos ter problemas quando os pods são agendados no mesmo nó por vários schedulers. Cada scheduler em execução tem uma visão global separada de todo o cluster, incluindo nós e utilizações de recursos. Quando vários pods são agendados ao mesmo tempo, os schedulers podem atribuir o mesmo nó para esses pods. Como resultado, esse nó fica sem recursos. O que é pior, o nó pode ser marcado como não pronto e os contêineres em execução nesse nó podem ser removidos.
Além disso, manter um scheduler customizado não é trivial, sem falar no alto desempenho e na baixa latência.
Scheduler Extender
Estende o Scheduler padrão do Kubernetes com recursos ou implementações mais personalizadas
O extensor do Scheduler Extender funciona como um webhook.
No extender é configurado qual recurso será redirecionado para ele, além do seu endereço externo
Limitações
Grande custo de comunicação e desempenho reduzido
: O extensor é chamado por HTTP(S). Todos os dados são transferidos entre eles. Se o cluster obtiver muitos nós, a carga útil da solicitação também terá um tamanho grande. Além disso, todos os dados precisam ser serializados e desserializados, o que consome muito tempo. Isso afetará bastante o desempenho do scheduler padrão.
Pontos de extensão limitados
: Somente alguns recursos podem ser esendidos
Compartilhamento de cache
: No scheduler padrão, mantém um cache local para armazenar o status de todo o cluster. Além disso, o cache não pode ser compartilhado com extensores externos. Isso traz problemas para os resultados do agendamento, especialmente para o concurrent scheduling.
Quando usar?
Estender o scheduler padrão com extensores é uma boa opção para clusters pequenos com baixos requisitos de eficiência de agendamento.
Scheduler Framework
Scheduler framework define uma variedade de APIs de plug-in para pontos de extensão no processo de scheduling.
Este design permite que recursos sejam implementados como plug-ins independentes, ao mesmo tempo que mantém o processo de scheduling leve, extenso e fácil de manter.
Os desenvolvedores podem implementar seus próprios plugins implementando as APIs definidas em cada ponto de extensão. Para cada plugin, pode implementar uma ou múltiplas interfaces de pontos de extensão, como Filter e Score.
um plugin pode ser invocado uma ou várias vezes durante um processo de scheduling
Os plug-ins podem ser informativos ou ajudar a tomar uma decisão de scheduling, como filtrar nós.
Durante o processo de scheduling, a estrutura do scheduler chamará os plugins registrados um por um em cada ponto de extensão. Dessa forma, plug-ins externos são integrados à estrutura do scheduler.
É importante notar que a scheduler framework é escrita em Go, diferente do Extender
Framework workflow
scheduling cycle
Sua principal tarefa é tomar uma decisão de scheduling ideal e selecionar o nó que melhor se adapta.
Todos os nós viáveis serão classificados com base em pontuações normalizadas. O nó escolhido obtém a pontuação mais alta.
binding cycle
Sua tarefa é vincular esse nó ao pod definindo spec.nodeName
Quando o pod for vinculado, o kubelet nesse nó será notificado para iniciar o pod.
Nesse fluxo existem vários pontos de extensão onde podem ser adicionados plugins e eles executam de forma sequencial.
Os scheduling cycles são executados em série para evitar problemas de competição de recursos, enquanto os binding cycles para diferentes pods são executados simultaneamente.
Forma oficial de estender o scheduler, Extender não é indicado.