Aperfeiçoando o Bootstrap de Nodes: Conheça o novo Node Readiness Controller

No modelo padrão do Kubernetes, a viabilidade de um node para receber workloads depende de uma condição binária simplificada: "Ready". No entanto, em ambientes modernos e complexos de infraestrutura cloud, um node precisa de muito mais do que o status do Kubelet para estar verdadeiramente operacional. Dependências críticas — como agentes de rede, drivers de storage, firmware de GPU ou verificações customizadas de saúde — precisam estar totalmente funcionais antes que o node possa hospedar pods com segurança.

Para resolver essa lacuna, o projeto Kubernetes anunciou oficialmente o Node Readiness Controller. Este projeto introduz um sistema declarativo para gerenciar taints de nodes, estendendo as proteções de prontidão durante o bootstrap e indo muito além das condições padrão.

Por que o Node Readiness Controller é estratégico?

Para empresas que escalam operações no Brasil, a gestão de clusters heterogêneos em provedores como AWS, Azure ou GCP traz um desafio: garantir que DaemonSets específicos ou serviços locais estejam saudáveis antes do node entrar no pool de agendamento (scheduling). Sem isso, é comum enfrentar erros de runtime logo após o provisionamento de novas instâncias.

O Node Readiness Controller preenche esse gap permitindo que times de SRE e DevOps definam scheduling gates personalizados para grupos específicos de nodes. Isso garante, por exemplo, que nodes configurados com GPUs só aceitem pods após a validação dos drivers especializados, enquanto nodes de propósito geral seguem o fluxo padrão.

Os três principais pilares de valor são:

• Definições de Prontidão Customizadas: O time define o que ready significa para a sua plataforma específica.
• Gestão Automatizada de Taints: O controller aplica ou remove taints dinamicamente com base no status das condições, impedindo que workloads falhem ao serem alocados em infraestrutura incompleta.
• Bootstrap Declarativo: Governança clara sobre o processo de inicialização de múltiplos passos, com observabilidade total sobre o progresso.

Conceitos estruturais e funcionalidades

O funcionamento central do controller baseia-se na API NodeReadinessRule (NRR), que permite definir as "portas de entrada" de forma declarativa.

Modos de aplicação flexíveis

O controller opera em dois modos principais, adaptando-se a diferentes necessidades operacionais:

1. Continuous enforcement: Mantém a garantia de prontidão durante todo o ciclo de vida do node. Se uma dependência crítica (como um driver de dispositivo) falhar posteriormente, o node recebe uma taint imediata para evitar novos agendamentos.
2. Bootstrap-only enforcement: Ideal para etapas de inicialização única, como o pre-pulling de imagens pesadas ou provisionamento de hardware. Uma vez que as condições são atingidas, o controller finaliza o processo e interrompe o monitoramento daquela regra específica para o node.

Reporte de condições e ecossistema

O design do controller é desacoplado: ele reage a Node Conditions em vez de realizar os health checks por conta própria. Isso facilita a integração com ferramentas já consolidadas:

• Node Problem Detector (NPD): Aproveite scripts e setups existentes para reportar a saúde do node.
• Readiness Condition Reporter: Um agente leve fornecido pelo projeto que pode ser implantado para verificar endpoints HTTP locais e atualizar as condições do node.

Segurança operacional com Dry Run

Alterar regras de prontidão em uma frota de nodes em produção envolve riscos. O modo dry run permite que os operadores simulem o impacto no cluster antes da aplicação real. O controller loga as ações pretendidas e atualiza o status da regra, mostrando quais nodes seriam afetados sem aplicar as taints de fato.

Exemplo prático: Provisionamento de CNI

O exemplo abaixo de NodeReadinessRule assegura que um node permaneça não agendável até que seu agente de CNI esteja funcional. O controller monitora a condição customizada cniplugin.example.net/NetworkReady e só remove a taint readiness.k8s.io/acme.com/network-unavailable quando o status for True.

CopiarapiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
  name: network-readiness-rule
spec:
  conditions:
  - type: "cniplugin.example.net/NetworkReady"
    requiredStatus: "True"
  taint:
    key: "readiness.k8s.io/acme.com/network-unavailable"
    effect: "NoSchedule"
    value: "pending"
  enforcementMode: "bootstrap-only"
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker: ""

Demo:

Próximos passos

O Node Readiness Controller está em suas fases iniciais (v0.1.1), mas já aponta para uma maturidade necessária em operações Kubernetes que prezam por estabilidade extrema. Para empresas brasileiras que utilizam arquiteturas multi-cloud ou híbridas, esta ferramenta representa uma camada adicional de governança sobre a infraestrutura elástica.

Você pode acompanhar o progresso e contribuir com a comunidade através dos canais oficiais:

• GitHub: https://sigs.k8s.io/node-readiness-controller
• Slack: Canal #sig-node-readiness-controller
• Documentação: Guia de Início Rápido

---

Artigo originalmente publicado em Kubernetes Blog.