Kubernetes 1.37 cria condições de ciclo de vida do Node — mas elas ainda não drenam nada

Desenvolvimento Web · "Loop"

O Kubernetes 1.37 passou a reservar cinco condições para descrever o ciclo de vida de um Node: drain em andamento, drain concluído, manutenção planejada, manutenção em andamento e desligamento gracioso em andamento. O anúncio oficial, publicado em 9 de setembro de 2026, resolve um problema de vocabulário: até então cada operador precisava inferir ou inventar um sinal para dizer por que um Node estava saindo de serviço.

A parte mais importante da novidade é também a mais fácil de perder: na versão 1.37, essas condições apenas comunicam estado. Nenhum controller central muda scheduling, eviction ou rollout por causa delas. Publicar DrainInProgress=True não executa kubectl drain.

Quais estados ganharam nome comum

  • DrainInProgress: o processo de drain está ativo segundo o critério escolhido pelo administrador.
  • Drained: o Node atingiu esse critério de drain.
  • MaintenancePlanned: existe uma mudança futura prevista.
  • MaintenanceInProgress: a manutenção está acontecendo.
  • GracefulNodeShutdownInProgress: um desligamento gracioso foi observado.

Cada condição usa True, False ou Unknown, além de reason estável, mensagem legível e instante da transição. A padronização permite que dashboards, alertas e automações autorizadas consumam o mesmo sinal sem tentar adivinhar intenção a partir de Pods terminando ou de um Node NotReady.

status:
  conditions:
    - type: MaintenancePlanned
      status: "True"
      reason: MaintenanceWindow
      lastTransitionTime: "2026-09-15T02:00:00Z"
      message: "Atualização de firmware agendada"

Esse trecho representa o status que um controller autorizado publicaria. Não é um manifesto comum para aplicar de qualquer jeito: status é um subresource, e a escrita precisa de RBAC e propriedade bem definidos.

Condição não é comando

As operações continuam nos mecanismos existentes. cordon impede novos agendamentos; drain conduz evictions; taints alteram scheduling ou expulsão conforme seus efeitos; PodDisruptionBudgets limitam indisponibilidade voluntária. A condição relata o que está ocorrendo, mas não substitui nenhum deles.

Tratar o sinal como comando cria uma automação circular: um controller escreve “drain em andamento” esperando que outro inicie o drain, enquanto o consumidor espera que a condição prove que a operação já começou. O contrato local precisa indicar quem executa, quem observa e em que momento publica cada transição.

O feature gate Alpha é praticamente um marcador nesta versão

O 1.37 inclui o feature gate Alpha NodeLifecycleConditions, desligado por padrão. Segundo o projeto, ele é efetivamente um no-op nesta entrega: não limita quem escreve as condições e não habilita um consumidor central. Também não é necessário ativá-lo para começar a publicar os novos tipos.

Isso pede cuidado com linguagem de rollout. Habilitar o gate não deixa o cluster “lifecycle-aware”. A utilidade imediata está em uma convenção observável; comportamentos automáticos planejados para controllers futuros ainda precisam ser desenhados e entregues.

Readiness e condição de manutenção respondem perguntas diferentes

Um Node pode estar saudável e, mesmo assim, entrar em manutenção planejada. Também pode ficar NotReady por uma falha inesperada sem que exista qualquer drain administrado. Misturar os sinais faz alerta operacional virar explicação causal sem evidência.

O mesmo princípio vale dentro da aplicação: liveness, readiness e health checks devem responder perguntas específicas, em vez de transformar todo problema numa única luz vermelha. Condições de Node acrescentam contexto de ciclo de vida; não são prova de que cada workload está saudável.

Como adotar sem criar dois donos para o mesmo estado

  1. Escolha um único controller autorizado para cada condição.
  2. Defina o critério verificável de Drained: Pods comuns removidos, exceções de DaemonSet, volumes e workloads estáticos.
  3. Use valores de reason estáveis; deixe detalhes variáveis para message.
  4. Limpe ou marque como False a condição quando a fase terminar.
  5. Crie alertas para condição presa e transições impossíveis, como Drained=True antes do início registrado.
  6. Mantenha cordon, drain, taints e budgets como controles operacionais explícitos.

O ganho do Kubernetes 1.37 é dar nome comum a uma intenção que antes aparecia espalhada em labels, annotations e inferências. Por enquanto, esse nome melhora visibilidade e integração entre ferramentas. A automação segura começa justamente por não atribuir a ele um efeito que o release ainda não entrega.

Fontes

Leia também