Agendamento
5 minute read
Um agendador observa os Pods recém-criados que não têm Node atribuído. Para cada Pod que o agendador descobre, o agendador se torna responsável por encontrar o melhor Node para esse Pod ser executado, uma vez concluído esse processo o Kubelet do node escolhido então coloca o pod em execução.
O escalonador chega a esta decisão de posicionamento levando em consideração os princípios de escalonamento descritos abaixo.
Agendamento manual
Defina diretamente na especificação do Pods em qual Node ele será executado.
Link’s úteis:
Labels e Selectors
Labels:
- São pares de chave/valor anexados a objetos, como pods.
- Devem ser usados para especificar atributos de identificação de objetos que são significativos e relevantes para os usuários, mas não implicam diretamente na semântica do sistema central.
- Podem ser usados para organizar e selecionar subconjuntos de objetos.
- Podem ser anexados a objetos no momento da criação e posteriormente adicionados e modificados a qualquer momento.
- Cada chave deve ser exclusiva para um determinado objeto.
Ao contrário de nomes e UIDs , as labels não fornecem exclusividade. Em geral, espera-se que muitos objetos tenham a(s) mesma(s) label(s).
- Selectors
Através de um label selector, o cliente/usuário pode identificar um conjunto de objetos. O label selector é a primitiva de agrupamento principal no Kubernetes.
Link’s úteis:
Taints e Tolerations
Enquanto Node Affinity
é uma propriedade dos Pods que os atrai para um conjunto de nós (como uma preferência ou um requisito rígido), as Taints são o oposto, elas permitem a um nó repelir um conjunto de pods.
As Tolerations são aplicadas aos pods e permitem (mas não exigem) que os pods sejam agendados em nós com Taints correspondentes.
As Taints e as Tolerations trabalham juntas para garantir que os pods não sejam agendados em nós inadequados.
Uma ou mais Taints pode(m) ser aplicadas a um nó, isso marca que o nó não deve aceitar nenhum pod que não tolere essas Taints.
Link’s úteis:
Node Selectors
nodeSelector é a forma mais simples recomendada de restrição de seleção de nó.
Ao adicionar o campo nodeSelector à especificação do pod e definir as labels de nós
que deseja que o nó de destino tenha, o Kubernetes agenda o pod apenas em nós que tenham cada uma das labels especificadas.
Link’s úteis:
Node Affinity
A Node Affinity é conceitualmente semelhante a nodeSelector
, permitindo restringir em quais nós o pod pode ser agendado com base em labels de nós
.
Existem dois tipos de Node Affinity:
requiredDuringSchedulingIgnoredDuringExecution: o agendador não pode agendar o pod a menos que a regra seja atendida. Isso funciona como nodeSelector , mas com uma sintaxe mais expressiva.preferredDuringSchedulingIgnoredDuringExecution: o agendador tenta encontrar um nó que atenda à regra. Se um nó correspondente não estiver disponível, o agendador ainda agendará o pod.
Link’s úteis:
Taints e Tolerations X Node Affinity
Resources Requirements e Limits
Quando você define um Pod, você pode opcionalmente especificar quanto de cada recurso um Pod precisa, os recursos mais comuns a serem especificados são CPU e memória (RAM) ; existem outros tipos de recursos .
Quando você especifica o requests de um recurso para contêineres em um pod, o kube-scheduler
usa essas informações para decidir em qual nó colocar o pod.
Quando você especifica um limits de recurso para um contêiner, o kubelet
impõe esses limits para que o contêiner em execução não tenha permissão para usar mais desse recurso do que o limits definido.
O kubelet
também reserva pelo menos a quantidade de requests desse recurso do sistema especificamente para esse contêiner usar.
Link’s úteis:
DaemonSets
Um DaemonSet garante que todos (ou alguns) nós executem uma cópia em um pod.
À medida que os nós são adicionados ao cluster, os pods são adicionados a eles. À medida que os nós são removidos do cluster, esses pods são coletados como lixo.
A exclusão de um DaemonSet limpará os pods que ele criou.
Alguns usos típicos de um DaemonSet são:
- Executando um daemon de armazenamento de cluster em cada nó.
- Executando um daemon de coleta de logs em cada nó.
- Executando um daemon de monitoramento de nó em cada nó.
Link’s úteis:
Static Pods
Os Static Pods são gerenciados diretamente pelo daemon kubelet
em um nó específico, sem o API Server
observando-os.
Enquanto a maioria dos Pods é gerenciada pelo Control Plane
(por exemplo, um Deployments
), para Static Pods, o kubelet
supervisiona diretamente cada Static Pods (e o reinicia se falhar).
Link’s úteis:
Multiplos Kubernetes Schedulers
Se o agendador padrão não atender às suas necessidades, você pode implementar seu próprio agendador. Além disso, você pode até executar vários agendadores simultaneamente ao lado do agendador padrão e instruir o Kubernetes sobre qual agendador usar para cada um de seus pods.
Link’s úteis:
Feedback
Gostou desta página?
Que bom, que gostou! Por favor, tem algo que podemos melhorar?
Que pena! Por favor, me diga o que podemos fazer pra melhorar. Obrigado!