No último post da série de Kubernetes, vimos como configurar NodeAffinity, PodAffinity e PodAntiAffinity. Nesse post, vamos ver como fazer o “NodeAntiAffinity”, ou seja, como configurar taint nos nodes e toleration nos pods.

Como você já deve ter percebido ao ler o post sobre Affinity e AntiAffinity, assim como o parágrafo anterior, não existe NodeAntiAffinity no Kubernetes. No entanto, caso um node precise ser configurado para repelir pods, o conceito de taint pode ser aplicado.

Embora possa parecer estranho ter um node dentro do cluster que repele pods, essa é uma prática comum ao configurar nodes com hardware específico, por exemplo que tenha GPU, assim como nodes dedicados a certas aplicações.

Taint

Como dito antes, ao contrário do affinity, cuja função é atrair os pods com determinadas labels, a função do taint é repelir pods com base em determinadas propriedades do node.

Para adicionar um taint em um node específico, utilizamos um comando com a seguinte estrutura:

kubectl taint node node-name key=value:effect

Já para remover um taint, basta executar o mesmo comando com um “-” no fim.

kubectl taint node node-name key=value:effect-

Na estrutura apresentada acima, o que se espera em cada um placeholders é:

• node-name: Nome do node onde o taint será adicionado;
• key: Nome da chave para o taint que está sendo criado (você decide);
• value: Valor para a chave do taint (você decide);
• effect: Pode conter os valores NoSchedule, PrefererNoSchedule e NoExecute (explicamos melhor abaixo).

Sendo assim, podemos adicionar um taint em um node que tenha GPU com o seguinte comando:

kubectl taint node node1 gpu=true:NoSchedule

Com isso, exceto os pods que tenham um toleration que atenda os requisitos, o Kubernetes não deixará nenhum pod ser adicionado ao node1.

Effects

Quando estamos falando de taints, o effect que configuramos diz ao Kubernetes qual é a ação que esperamos caso um pod não tenha toleration ao taint.

• NoSchedule: A menos que o pod tenha um toleration compatível, o Kubernetes não irá colocar nenhum pod no node. Pods que já estejam sendo executados, continuarão sendo executados;
• PrefererNoSchedule: É a versão “soft” do NoSchedule, ou seja, o Kubernetes tentará não alocar nenhum pod no node.
• NoExecute: Diferente dos dois primeiros, ao adicionar esse um taint com esse effect, caso um pod que não tenha tolerations compatíveis já esteja sendo executado no node, o pod será “despejado” imediatamente. Esse effect tem a propriedade tolerationSeconds como opcional, onde podemos configurar por quanto tempo esses pods continuarão sendo executados antes de serem “despejados”.

Toleration

Para que um pod possa ser criado em um node com taint, precisamos adicionar toleration as suas configurações. Em outras palavras, precisamos dizer ao Kubernetes que aquele pod “tem o que se precisa ter” para ser executado naquele node.

Seguindo o exemplo anterior, para que um pod possa ser criado no node1, precisamos adicionar a seção tolerations ao manifesto de deploy.

apiVersion: v1
kind: Pod
...
spec:
	containers:
	...
	tolerations:
	- key: "gpu"
	  operator: "Equal"
	  value: "true"
	  effect: "NoSchedule"

Além do operador Equal, onde é preciso ter tanto key quanto value configurados, também temos o operado Exists, onde precisamos configurar somente o valor da key.

Conclusão

Assim como affinity e anti-affinity, taint e toleration nos dá maior controle sobre onde o Kubernetes irá alocar os pods dentro de um cluster.

Embora para clusters pequenos ou com poucas aplicações utilizar essa funcionalidades pode acabar sendo over-engineering, em muitos casos, essa é a melhor forma para se ter um melhor aproveitamento ou isolar os recursos dentro do cluster.

Para não perder os próximos posts, se inscreva na nossa newsletter! É, e sempre será gratuita!

Até a próxima!

Se inscreva na nossa newsletter