Kubernetes v1.35: Node Affinity em PersistentVolumes agora é mutável (Alpha)

Desde o Kubernetes v1.10, a API de nodeAffinity para PersistentVolume (PV) tem sido uma peça fundamental para garantir que volumes de dados sejam consumidos apenas por nós que possuem acesso físico ou lógico a eles. Historicamente, esse campo era imutável: uma vez definido, o vínculo entre o volume e a topologia do cluster estava selado.

No Kubernetes v1.35, essa barreira começa a cair com a introdução da mutabilidade de nodeAffinity para PVs (em estágio alpha). Para empresas que operam em escala no Brasil, essa mudança não é apenas um detalhe técnico, mas um passo importante para a eficiência operacional e a evolução de arquiteturas stateful.

Por que a mutabilidade da afinidade de nó é necessária?

Cargas de trabalho stateless, como Deployments, podem ser ajustadas e reiniciadas sem grandes fricções. No entanto, PersistentVolumes guardam o estado crítico do negócio. Recreá-los para ajustar uma regra de agendamento é um processo arriscado e que gera downtime.

À medida que os provedores de cloud (AWS, Azure, GCP) evoluem, surgem cenários onde o storage precisa acompanhar mudanças na infraestrutura sem que os dados precisem ser migrados ou o objeto PV deletado:

1. Migração de Zonal para Regional: Muitos provedores agora oferecem discos regionais e permitem a migração de discos zonais para regionais sem interrupção. Com o VolumeAttributesClass (GA na v1.34), você pode alterar a classe do volume, mas o Kubernetes ainda impediria o agendamento do Pod em outras zonas devido à nodeAffinity estática no PV. Com a mutabilidade, você pode atualizar o PV para refletir a nova disponibilidade geográfica.

   Exemplo de transição de zona para região:

   Copiar# Antes (Restrito a uma zona)
   spec:
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: topology.kubernetes.io/zone
             operator: In
             values:
             - us-east1-b
   
   # Depois (Expandido para toda a região)
   spec:
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: topology.kubernetes.io/region
             operator: In
             values:
             - us-east1
   

2. Ciclo de Vida de Hardware: Novos tipos de discos (ex: migração de GP2 para GP3 na AWS ou novas gerações de discos no Azure/GCP) podem exigir que o volume seja anexado apenas a nós de gerações mais recentes. Se você faz o upgrade do disco, precisa ter a capacidade de restringir ou expandir quais nós podem montá-lo.

Implementação Prática e Desafios

Este recurso é voltado para administradores de clusters que utilizam provedores de storage com suporte a atualizações online. É essencial entender que alterar a nodeAffinity no Kubernetes não altera a acessibilidade do volume no provedor de cloud; o administrador deve garantir que o storage subjacente foi atualizado antes de sincronizar o PV.

Como o recurso está em alpha, ele vem desabilitado por padrão. Para testar, é necessário ativar o feature gate MutablePVNodeAffinity no APIServer.

O risco da Race Condition

Um ponto de atenção crucial para times de engenharia é a condição de corrida (race condition) durante o agendamento. Ao afrouxar a afinidade (permitir mais nós), o impacto é baixo. Contudo, ao restringir a afinidade (apertar a regra), existe uma janela de tempo onde o Scheduler pode decidir colocar um Pod em um nó que acabou de perder o acesso ao volume, baseando-se em cache antigo. O resultado será um Pod travado em ContainerCreating.

A recomendação atual é monitorar de perto os Pods criados imediatamente após a alteração da afinidade no PV.

O Caminho para o Futuro: Integração com CSI

O objetivo final é que essa alteração não seja manual. A visão da comunidade Kubernetes é integrar essa mutabilidade diretamente com o VolumeAttributesClass e drivers CSI. Isso permitiria que desenvolvedores alterassem seus PersistentVolumeClaims (PVC) e o Kubernetes orquestrasse automaticamente tanto o update no provedor de storage quanto a atualização da nodeAffinity no PV, sem intervenção humana e sob uma ótica de FinOps (ajustando performance e custo dinamicamente).

Conclusão

Para empresas brasileiras que buscam alta disponibilidade e utilizam múltiplas zonas de disponibilidade para proteção contra desastres, a mutabilidade da nodeAffinity em PVs remove um gargalo histórico de gestão de infraestrutura. É uma funcionalidade que facilita a governança de dados e a modernização de ambientes legados em cloud de forma progressiva.

---

Artigo originalmente publicado por Weiwen Hu (Alibaba Cloud), YuanHui Qiu (Alibaba Cloud) em Kubernetes Blog.