Kubernetes v1.36: A Virada do SELinux que Elimina o Gargalo dos Volumes Grandes

O Kubernetes está prestes a fazer uma mudança importante na forma como volumes são montados em ambientes com SELinux. A partir do ciclo que começa em v1.36, administradores já podem testar a nova abordagem, identificar incompatibilidades e preparar o cluster para a ativação padrão prevista para v1.37. Na prática, a discussão não é apenas sobre desempenho: é sobre uma troca de modelo que pode impactar o comportamento de workloads em produção.

Até hoje, o comportamento mais comum era o relabeling recursivo, em que o kubelet percorre o conteúdo do volume para ajustar o contexto SELinux de cada arquivo e diretório. Esse método funciona, mas pode ser lento em volumes grandes, em storage remoto ou em aplicações que iniciam com muitos arquivos. A novidade do SELinuxMount muda esse cenário ao permitir o uso de mount option com context=<label>, reduzindo a necessidade de travessia recursiva do volume.

Essa mudança parece pequena no papel, mas altera a semântica de um ponto sensível: o compartilhamento de volume entre Pods com perfis SELinux diferentes. Em cenários raros, porém reais, isso pode fazer um Pod ficar preso em ContainerCreating após a ativação do novo comportamento. Por isso, v1.36 é a release de auditoria obrigatória: é nela que o time de plataforma deve mapear riscos, testar opt-out e corrigir dependências antes do upgrade seguinte.

O que muda tecnicamente

• O kubelet pode usar mount option com context=<label>, evitando o relabeling recursivo tradicional.
• A compatibilidade passa a depender de SELinux ativo, feature gates habilitados, suporte do volume plugin ou CSI driver e presença de seLinuxOptions.level no Pod.
• Volumes ReadWriteOncePod já estão cobertos e em GA; a mudança amplia o mecanismo para outros modos de acesso quando SELinuxMount e SELinuxChangePolicy permitem.
• O campo spec.securityContext.seLinuxChangePolicy vira o principal controle para escolher entre Recursive e MountOption.
• Drivers CSI precisam declarar suporte com CSIDriver.seLinuxMount=true; sem isso, o cluster continua no relabeling recursivo.

Na prática, a regra de ouro é simples: se o nó não usa SELinux, essa mudança não afeta você. O impacto real aparece em clusters Linux com SELinux em modo enforcing, especialmente quando existe volume com grande volume de arquivos, inicialização frequente ou dependência de storage remoto. Nesses casos, a nova montagem pode reduzir tempo de startup e custo operacional de forma perceptível.

Por que isso importa para upgrades

O motivo principal para tratar esse assunto como prioridade de upgrade é que a mudança não afeta apenas performance, mas também disponibilidade. Se um workload depende de compartilhamento de volume entre Pods com labels SELinux distintos, o novo comportamento pode invalidar a suposição anterior de que o relabeling recursivo resolveria tudo automaticamente. Em outras palavras: o cluster pode funcionar perfeitamente hoje e falhar depois da ativação padrão, caso a compatibilidade não tenha sido revisada.

Isso torna a janela entre v1.36 e v1.37 especialmente importante para times de plataforma, segurança e SRE. É o período para detectar conflitos, revisar manifests, checar suporte de CSI drivers e definir políticas de exceção ou padronização.

Dois cenários que merecem atenção máxima

1. SubPaths com labels diferentes: quando diferentes partes de um mesmo volume são expostas a Pods com contextos SELinux distintos, o modelo de montagem pode não reproduzir o comportamento esperado.
2. Volume compartilhado entre Pod privilegiado e não privilegiado: esse caso já foi observado em aplicações reais e, embora raro, é exatamente o tipo de cenário que costuma explodir em produção após um upgrade de segurança.

Para ajudar nessa transição, o Kubernetes introduz sinais de observabilidade e mecanismos de controle. Um deles é o selinux-warning-controller, pensado para detectar conflitos antes da mudança efetiva. Outro é o metric da kubelet, que indica conflitos em runtime sem expor o nome exato do Pod, ajudando a manter o equilíbrio entre diagnóstico e segurança operacional.

Como preparar o cluster em v1.36

Se sua organização usa SELinux, o caminho mais seguro é tratar v1.36 como versão de validação obrigatória. O objetivo não é apenas ativar a novidade, mas sim simular o comportamento futuro e documentar onde ele quebra.

• Inventarie workloads com volumes persistentes e compartimentos de acesso diferentes.
• Verifique quais CSI drivers declaram seLinuxMount=true.
• Localize Pods com seLinuxOptions.level e compare com o padrão de uso do volume.
• Teste o seLinuxChangePolicy em modo Recursive e MountOption.
• Monitore alertas do selinux-warning-controller e os metrics de conflito da kubelet.
• Corrija aplicações que dependem de compartilhamento de volume com perfis SELinux distintos.

Há também um ponto de governança que não deve ser ignorado: ferramentas de observabilidade, automação de policy e auditoria ganham mais importância nesse contexto. A mudança aumenta a necessidade de visibilidade entre segurança e disponibilidade, porque o cluster passa a ter um novo ponto de decisão que pode afetar o ciclo de vida do Pod e o comportamento de armazenamento.

O que esperar na prática

Para workloads compatíveis, o benefício pode ser claro: inicialização mais rápida, menos trabalho do kubelet, menos custo com volumes grandes e menor atrito em storage remoto. Para workloads incompatíveis, o risco é igualmente claro: pods travados, falhas silenciosas de suposição e incidentes após upgrade.

Por isso, a mensagem central é direta: quem usa SELinux precisa auditar agora. Quem não usa, pode ignorar esta mudança sem alarme desnecessário. E quem administra clusters com múltiplos tenants, perfis de segurança distintos ou storage compartilhado deve olhar para isso como uma mudança de plataforma, não apenas como ajuste de feature gate.

Resumo executivo

• SELinuxMount deve se tornar padrão em uma versão futura, prevista para v1.37.
• v1.36 é a versão ideal para testes, auditoria e correção de compatibilidade.
• A montagem com context reduz o custo do relabeling recursivo e melhora desempenho.
• Alguns cenários de compartilhamento de volume podem quebrar após a mudança.
• seLinuxChangePolicy será o principal mecanismo de escolha entre Recursive e MountOption.
• O suporte real depende também dos CSI drivers e da configuração do sistema operacional.
• Se o cluster não usa SELinux, o impacto é nulo.

Em resumo, a chegada do SELinuxMount marca uma evolução importante no relacionamento entre segurança e armazenamento no Kubernetes. O ganho de performance é real, mas a mudança exige disciplina operacional. Se o seu cluster roda com SELinux, o momento de agir é agora: teste em v1.36, corrija conflitos e chegue à próxima versão com o comportamento já previsto.