Kubernetes Tolerations: Exemplos, Casos de Uso e Boas Práticas

Efeitos de Taint no Kubernetes

Vamos analisar os efeitos de taint oferecidos pelo Kubernetes, que as tolerations podem contornar.

NoSchedule

O efeito NoSchedule impede que novos pods sejam agendados em um nó, a menos que tenham uma toleration correspondente. Pods que já estão em execução no nó quando o taint é adicionado não são despejados. Isso torna o NoSchedule útil para reservar nós para workloads específicos sem interromper pods existentes.

Por exemplo, adicionar um taint hardware=gpu:NoSchedule impede que pods sem uma toleration correspondente sejam agendados no nó com GPU a partir daquele momento. Pods que já estão rodando ali podem continuar em execução.

PreferNoSchedule

O efeito PreferNoSchedule é uma restrição flexível de agendamento. O Kubernetes tenta evitar colocar pods sem uma toleration correspondente no nó com taint, mas ainda pode agendá-los ali quando necessário. Diferente do NoSchedule, ele não bloqueia o agendamento de forma estrita.

Esse efeito é útil quando os administradores preferem reservar nós para certos workloads, mas ainda querem que o scheduler use esses nós quando as outras opções de alocação forem limitadas. Pods existentes não são despejados quando um taint PreferNoSchedule é adicionado.

NoExecute

O efeito NoExecute afeta tanto o agendamento quanto os pods que já estão rodando em um nó. Novos pods sem uma toleration correspondente não podem ser agendados ali, enquanto pods existentes que não toleram o taint são despejados.

Uma toleration pode incluir tolerationSeconds para permitir que um pod permaneça temporariamente no nó depois que um taint NoExecute correspondente surgir. Após esse período expirar, o pod é despejado se o taint persistir. Se tolerationSeconds for omitido, uma toleration correspondente permite que o pod permaneça enquanto o taint estiver presente.

Exemplos de Tolerations no Kubernetes

Exemplo 1: Toleration NoSchedule Básica

Suponha que um nó tenha o taint workload=analytics:NoSchedule. Um pod precisa de uma toleration correspondente para se tornar elegível ao agendamento nesse nó. O pod a seguir tolera esse taint específico:

apiVersion: v1
kind: Pod
metadata:
  name: analytics-pod
spec:
  containers:
    - name: web
      image: nginx:latest
  tolerations:
    - key: "workload"
      operator: "Equal"
      value: "analytics"
      effect: "NoSchedule"

O operador Equal exige que tanto a key quanto o value correspondam ao taint. Essa toleration permite que o pod seja agendado em nós com o taint especificado, mas não exige que o scheduler coloque o pod em um desses nós.

Exemplo 2: Tolerando Qualquer Value de um Taint

O operador Exists pode ser usado quando um pod deve tolerar uma key de taint independentemente do seu value. Por exemplo, a configuração a seguir tolera qualquer taint NoSchedule cuja key seja workload:

apiVersion: v1
kind: Pod
metadata:
  name: compute-pod
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "workload"
      operator: "Exists"
      effect: "NoSchedule"

Nenhum value é especificado ao usar Exists. Como resultado, esse pod pode tolerar taints como workload=database:NoSchedule e workload=batch:NoSchedule. Outras keys ou effects de taint ainda exigem tolerations correspondentes separadas.

Exemplo 3: NoExecute com tolerationSeconds

Uma toleration NoExecute pode incluir tolerationSeconds para controlar por quanto tempo um pod permanece em um nó após a aplicação de um taint correspondente. O pod a seguir tolera um taint maintenance-window=active:NoExecute por 100 segundos:

apiVersion: v1
kind: Pod
metadata:
  name: maintenance-worker
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "maintenance-window"
      operator: "Equal"
      value: "active"
      effect: "NoExecute"
      tolerationSeconds: 100

Se o taint for adicionado enquanto o pod estiver em execução, o pod pode permanecer no nó por até 100 segundos. Se o taint ainda existir após esse período, o Kubernetes despeja o pod. Se o taint for removido antes de o período expirar, o pod pode continuar em execução.

Boas Práticas de Tolerations no Kubernetes

Use Tolerations Apenas em Workloads que Precisam Delas

Adicione tolerations apenas quando um workload tiver um motivo claro para rodar em nós com taint. Tolerations amplas ou desnecessárias enfraquecem o isolamento que os taints devem proporcionar e podem permitir workloads em nós reservados para outros fins. Isso pode gerar disputa por recursos e tornar a alocação de nós menos previsível.

Revise as tolerations conforme os requisitos dos workloads mudarem. Evite tolerations genéricas com Exists, a menos que o pod realmente precise tolerar uma ampla variedade de taints. Prefira keys, values e effects com escopo restrito, para que cada workload receba apenas as permissões de agendamento de que precisa.

Também é útil gerenciar as tolerations no nível do controlador de workload, como em um Deployment, StatefulSet ou DaemonSet. Isso mantém o comportamento de agendamento consistente quando os pods são recriados ou escalados.

Combine Tolerations com Afinidade de Nós

Uma toleration torna um pod elegível para rodar em um nó com taint, mas não direciona o pod para esse nó. Se um workload deve rodar especificamente em um determinado pool de nós, combine tolerations com afinidade de nós ou node selectors.

Por exemplo, um workload de GPU pode tolerar um taint de nó de GPU e, ao mesmo tempo, usar afinidade de nós para exigir nós rotulados com o tipo de GPU apropriado. O taint mantém workloads comuns afastados, enquanto a afinidade direciona o workload de GPU para nós compatíveis.

Escolha entre afinidade de nós obrigatória (required) ou preferencial (preferred) com base em quão rígida a alocação precisa ser. A afinidade obrigatória impede o agendamento em nós que não correspondem, enquanto a preferencial dá ao scheduler mais flexibilidade quando não há nós adequados disponíveis.

Mantenha Taints e Tolerations Consistentes entre os Pools de Nós

Use um esquema de nomenclatura consistente para keys e values de taints em todos os pools de nós. Valores inconsistentes, como workload=gpu, type=gpu e node=gpu para a mesma finalidade, dificultam a manutenção das configurações dos pods e aumentam o risco de erros de agendamento.

Defina taints padrão para as funções de nó mais comuns e aplique-os por meio de automação de cluster ou de infraestrutura. Os manifestos dos workloads podem então usar tolerations previsíveis em desenvolvimento, staging e produção, sem diferenças de configuração desnecessárias.

A consistência é especialmente importante quando os nós são criados ou substituídos automaticamente por sistemas de autoescalonamento de cluster. Os novos nós devem receber os taints e rótulos esperados durante o provisionamento, para que os workloads se comportem da mesma forma, independentemente de qual instância de nó estiver em execução.

Proteja Nós Especializados e Caros

Use taints para impedir que pods de uso geral consumam recursos especializados, como GPUs, instâncias com muita memória ou outros hardwares caros. Apenas workloads projetados para usar esses recursos devem receber as tolerations correspondentes.

Tolerations sozinhas não garantem que um pod de fato solicite o recurso especializado. Para workloads de GPU, por exemplo, configure as solicitações ou limites de recursos apropriados, além da toleration. A afinidade de nós pode oferecer controle adicional de alocação quando há vários tipos de hardware disponíveis.

Essa abordagem ajuda a evitar que workloads de baixa prioridade ocupem a capacidade necessária para aplicações especializadas. Também pode reduzir custos de infraestrutura, mantendo nós caros disponíveis para workloads que podem se beneficiar do seu hardware.

Monitore os Resultados do Agendamento, Não Apenas a Configuração

Uma toleration válida não garante que um pod será agendado com sucesso. Disponibilidade de recursos, afinidade de nós, restrições de topologia, afinidade e antiafinidade de pods e outras regras do scheduler ainda podem impedir a alocação.

Monitore pods pendentes, eventos do scheduler, taints dos nós e a alocação real dos pods para verificar se as políticas de agendamento se comportam como esperado. Comandos como kubectl describe pod e kubectl describe node podem ajudar a identificar incompatibilidades de taint e outras restrições de agendamento.

O monitoramento também deve detectar alocações inesperadas, e não apenas pods que permanecem pendentes. Um workload rodando com sucesso no pool de nós errado pode indicar tolerations amplas demais ou regras de afinidade ausentes. Verificações periódicas ajudam a garantir que as políticas de agendamento continuem funcionando à medida que o cluster e seus workloads mudam.

FAQ

O que é uma toleration no Kubernetes? Uma toleration é uma configuração na spec de um pod que permite que ele seja agendado em nós com taints correspondentes. Ela apenas permite o agendamento. Não garante que o pod seja alocado em um nó com taint, porque as solicitações de recursos e a afinidade de nós ainda se aplicam.

Qual é a diferença entre um taint e uma toleration? Taints são aplicados aos nós e repelem pods que não têm uma toleration correspondente. Tolerations são aplicadas aos pods e permitem, mas não exigem, o agendamento em nós com taints correspondentes.

Qual é a diferença entre os operadores Equal e Exists? O Equal exige que a key, o value e o effect da toleration correspondam ao taint, e é o padrão quando nenhum operador é definido. O Exists corresponde apenas pela key, então o value deve ser omitido, e ele tolera qualquer value para essa key.

O que fazem os efeitos NoSchedule, PreferNoSchedule e NoExecute? O NoSchedule bloqueia novos pods sem uma toleration correspondente, mas não mexe nos pods em execução. O PreferNoSchedule é uma versão flexível em que o scheduler tenta evitar o nó. O NoExecute também despeja pods em execução que não toleram o taint.

O que faz o tolerationSeconds? Em uma toleration NoExecute, o tolerationSeconds define por quanto tempo um pod pode permanecer em um nó depois que um taint correspondente surge. Quando esse tempo passa e o taint ainda está lá, o Kubernetes despeja o pod. Se for omitido, o pod permanece enquanto o taint estiver presente.

Uma toleration faz um pod rodar em um nó com taint? Não. Uma toleration apenas torna o pod elegível. Para direcionar um pod a um pool de nós específico, combine a toleration com afinidade de nós ou um node selector.

Tornando o Agendamento Baseado em Tolerations Mais Eficiente com o PerfectScale

Taints e tolerations decidem onde os pods podem rodar, mas não dizem nada sobre se esses nós estão dimensionados corretamente ou se os workloads alocados neles estão solicitando a quantidade certa de CPU e memória. O PerfectScale é uma plataforma de otimização e governança de Kubernetes que é implantada com um único comando Helm e, a partir daí, entrega insights acionáveis e otimização autônoma em toda a stack K8s — workloads, nós e autoscalers —, para que pools de nós reservados, especializados e caros sejam de fato usados com eficiência.

Principais recursos do PerfectScale:

• Right-sizing autônomo de workloads: o Podfit oferece uma visão granular da saúde e do custo do cluster, destaca recursos desperdiçados e problemas de resiliência e otimiza workloads de forma autônoma, com recomendações de right-sizing baseadas em dados que você pode automatizar.
• Insights de utilização no nível dos nós: o Infrafit revela capacidade ociosa de nós e recomenda os tipos de nó certos para seus workloads, para que pools de nós dedicados, de GPU e outros com taint entreguem desempenho máximo sem que você pague por capacidade não utilizada.
• Otimização de autoscalers: o PerfectScale se integra a HPA, KEDA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning e Google Autopilot, maximizando a eficácia dos sistemas que provisionam e substituem seus nós com taint.
• Alertas em tempo real com priorização automática: riscos de resiliência e anomalias de custo são destacados com priorização orientada por impacto e entregues diretamente no Slack, Datadog, MS Teams ou PagerDuty, antes de chegarem aos seus usuários ou à sua conta de nuvem.
• Tendências, governança e previsão: o relatório Trends oferece visibilidade aprofundada das métricas de custo, desperdício e risco ao longo do tempo, em clusters, grupos de nós, namespaces e workloads, apoiando a análise de causa raiz e um planejamento de orçamento preciso.
• Qualquer ambiente Kubernetes: o PerfectScale roda em clusters on-premise e na nuvem, incluindo OpenShift, EKS, GKE, AKS e ambientes híbridos, com suporte a contêineres Windows e a workloads efêmeros ou de ML, como jobs do Airflow e do Spark.

Saiba mais sobre a plataforma PerfectScale