Taints e Tolerations

Taints e Tolerations

No Kubernetes, taints e tolerations formam um mecanismo poderoso para controlar em quais nós (nodes) certos pods podem rodar. Com taints, você “marca” um nó para que, por padrão, nenhum pod (que não o tolere explicitamente) seja agendado ali. Já tolerations são inseridas no pod para permitir que ele seja agendado em nós que tenham essas “manchas”.

A seguir, explicaremos em detalhe como taints e tolerations funcionam e como podem ser usados em estratégias avançadas de agendamento e isolamento de workloads.

Visão Geral

Taints
- São “manchas” aplicadas ao node.
- Possuem uma chave (key), um valor (value) e um efeito (effect).
- Effect pode ser:
  - NoSchedule: impede a colocação de novos pods (sem toleration) naquele nó.
  - PreferNoSchedule: desestimula (mas não impede totalmente) a colocação de pods sem toleration naquele nó.
  - NoExecute: impede novos agendamentos e, além disso, expulsa (evicts) os pods já em execução que não tiverem a devida toleration.
Tolerations
- São “permissões” definidas no pod (normalmente no manifesto do Deployment ou PodSpec) que dizem “OK, eu posso ser executado em um nó que tenha determinada taint”.
- Se um nó tiver uma taint key=value:NoSchedule, só pods que tenham a toleration compatível poderão ser agendados ali.

Combinando taints e tolerations, você consegue criar “zonas” dentro do cluster para workloads específicos (por exemplo, separar nós de produção de nós de desenvolvimento ou reservar nós com GPU para workloads de Machine Learning).

Sintaxe e Exemplo

1. Aplicando uma Taint

Para adicionar uma taint a um nó, você pode fazer:

kubectl taint nodes <nome-do-node> key=value:NoSchedule

Por exemplo:

kubectl taint nodes worker-1 env=dev:NoSchedule

Aqui, o nó worker-1 passa a ter a taint env=dev com efeito NoSchedule.

Isso significa que nenhum pod poderá ser agendado ali, a não ser que o pod tenha a toleration correspondente.

2. Removendo uma Taint

Para remover, basta adicionar um - no final da taint:

kubectl taint nodes <nome-do-node> env=dev:NoSchedule-

3. Adicionando Tolerations no Pod

Para que um pod possa ser agendado em um nó que tenha env=dev:NoSchedule, você acrescenta algo como:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-app
  template:
    metadata:
      labels:
        app: minha-app
    spec:
      tolerations:
      - key: "env"
        operator: "Equal"
        value: "dev"
        effect: "NoSchedule"
      containers:
      - name: minha-app-container
        image: myimage:latest

key: "env" e value: "dev" combinam com a taint env=dev.
operator: "Equal" define que a chave e valor devem corresponder exatamente.
effect: "NoSchedule" deve corresponder ao efeito usado no nó.

Agora, esse Deployment aceita rodar em nós que tenham a taint env=dev:NoSchedule.

Efeitos Avançados

NoSchedule
- Impede que novos pods sejam agendados, a menos que tenham toleration compatível.
- Não afeta pods já em execução no nó (eles podem continuar rodando).
PreferNoSchedule
- Não é um bloqueio absoluto, mas o agendador tentará ao máximo evitar colocar pods sem a toleration ali.
- Às vezes é usado para cenários em que você “prefere” segregar pods, mas não quer um bloqueio rígido.
NoExecute
- Além de impedir agendamentos futuros, também expulsa (evicts) os pods que já estão rodando lá, se eles não tolerarem a taint.
- Muito usado em casos em que o nó deve ficar reservado para pods específicos ou quando há um problema que exige evacuação imediata.

Estratégias Comuns de Uso

Dedicando Nós para Workloads Específicos
- Por exemplo, você pode ter nós com GPUs e aplicar taints como gpu=true:NoSchedule. Qualquer pod que precise de GPU deve ter toleration correspondente, garantindo que só esses pods rodem ali.
Isolando Ambientes (dev, staging, prod)
- Você aplica taints a nós de produção (env=prod:NoSchedule) e dá tolerations apenas aos pods que de fato são de produção.
- Impede que workloads de desenvolvimento sejam acidentalmente agendados em nós críticos.
Gerenciando Escalonamento e Custos
- Em ambientes em nuvem, você pode ter grupos de nós (node pools) mais caros (por exemplo, máquinas maiores ou com recursos especiais) que devem rodar apenas certos aplicativos.
- Usando taints, você assegura que nenhum pod genérico seja colocado nesses nós caros.
Manutenção e Desativação de Nós
- Antes de retirar um nó para manutenção, você pode adicionar uma taint key=maintenance:NoExecute. Isso expulsa todos os pods que não toleram essa taint e impede que novos pods sejam agendados.
- Depois, é seguro drenar o nó ou realizar updates sem se preocupar em quebrar aplicativos.
Combinação com Node Affinity
- Taints/Tolerations e Node Affinity são recursos diferentes, mas complementares:
  - Node Affinity define “em quais nós esse pod quer (ou pode) rodar”, baseado em labels do nó.
  - Taints/Tolerations define “quais nós rejeitam (ou aceitam) esse pod”, a menos que haja toleration.
- Em conjunto, você consegue modelar cenários de agendamento bem complexos e precisos.

Considerações e Boas Práticas

Não Abuse de Taints
- É fácil exagerar e criar muitos “bloqueios” no cluster, dificultando o agendamento e causando pods em estado de Pending. Use taints apenas quando necessário.
Equilíbrio Entre Taint/Toleration e Node Affinity
- Se você quer apenas direcionar pods para certos nós, muitas vezes o Node Affinity (por label de nó) já basta.
- Taints são úteis quando você quer “isolar” o nó ou forçar toleration explícita.
Manter Coerência de Nomeação
- Use chaves (key) de taints que façam sentido com a arquitetura do seu cluster, por exemplo:
  - purpose=production
  - hardware=gpu
  - zone=high-memory
- Isso facilita a compreensão e a configuração de tolerations nos Pods.
Verificar Logs de Agendamento
- Se você notar que um pod não está sendo agendado, pode ser que falte a toleration ou haja um conflito de scheduling com outras políticas (Affinity, Pod Security, Resource Requests, etc.).
Automação
- Se você usa autoscaling ou node pools na nuvem, verifique se as taints são aplicadas automaticamente quando novos nós surgem ou se você precisa de um passo de configuração extra.
- Ferramentas como o Cluster Autoscaler suportam “node labels” e “taints” em algumas configurações.

Conclusão

Taints e tolerations são fundamentais para garantir que certos pods só rodem em nós específicos (ou para expulsar pods indesejados de certos nós). Isso é crucial em cenários como:

Isolamento de workloads críticos ou sensíveis;
Reserva de nós especializados (GPU, memória grande, etc.);
Manutenção e orquestração (evacuar nós, controlar upgrades);
Gerenciamento de custo (impedir que workloads não autorizados usem nós caros).

Ao usar taints/tolerations em conjunto com Node Affinity e outras políticas de agendamento (Resource Requests, Pod Security, etc.), você obtém um nível avançado de controle sobre onde (e como) os pods rodam no cluster. Desse modo, sua arquitetura de Kubernetes fica mais organizada, segura e alinhada aos requisitos específicos de cada aplicação.