Flux 2.9.6 resolve o HelmRelease que travava pra sempre — e fecha um vazamento de secret no postBuild

Em 1º de outubro de 2026, o time do Flux lançou a v2.9.6 — um patch que, à primeira vista, parece rotina: três controllers com fixes pontuais. Mas dois desses fixes resolvem problemas que quem roda Flux em escala provavelmente já sentiu na pele, mesmo sem saber o nome técnico do bug. O terceiro fecha uma brecha de vazamento de dado sensível que é fácil de nunca notar, porque o dado vaza num lugar que ninguém monitora: o campo de mensagem de um evento do Kubernetes.

O que de fato mudou

A v2.9.6 empacota helm-controller v1.6.5, kustomize-controller v1.9.6 e ajustes no source-controller v1.9.6. Os três fixes que importam pra operação:

HelmRelease que fica preso em Ready=Unknown pra sempre

Esse é o bug mais incômodo dos três. Quando o helm-controller detecta drift — alguém (ou algo) alterou recursos que o Helm gerencia fora do ciclo de reconciliação — ele tenta corrigir. Se essa correção falhar de um jeito específico, o HelmRelease ficava com a condição Ready em Unknown e, antes desse patch, não tinha caminho de volta: nem reconciliação automática, nem retry, resolvia. Só saía dali com intervenção manual — geralmente forçando um suspend/resume ou deletando e recriando o objeto.

Isso é ruim por um motivo específico: Ready=Unknown não dispara os mesmos alertas que Ready=False. Muita gente configura alerta pra falha explícita, não pra “estado desconhecido” — então o HelmRelease trava silenciosamente, às vezes por dias, antes de alguém notar que aquele serviço parou de receber atualizações.

A correção (helm-controller#1580) faz o controller se recuperar sozinho desse estado de condição Ready/Released arrastada. Na prática: depois do upgrade, reconciliações que antes ficavam presas em loop de drift voltam a convergir sem você precisar tocar no objeto.

CRD sendo reaplicada sem necessidade a cada upgrade

Se você usa server-side apply com a política padrão (Create) pra CRDs de chart, o helm-controller estava reaplicando essas CRDs em todo upgrade de release — mesmo quando nada nelas tinha mudado. Isso não é catastrófico, mas tem custo real: mais chamadas à API do cluster, mais chance de conflito de field manager em ambientes com múltiplos controllers tocando a mesma CRD, e reconciliações mais lentas em releases com CRDs grandes (pense em qualquer operator complexo — cert-manager, Prometheus Operator, Crossplane). O fix (helm-controller#1580) para essa reaplicação redundante quando a política é Create e nada mudou de fato.

Secret vazando em evento de erro do postBuild substitution

Esse é o que mais merece atenção de quem trata segurança como prioridade. O postBuild.substituteFrom do Flux deixa você injetar valores de ConfigMap ou Secret em manifests via substituição de variável (${VAR}) depois do kustomize build. O Flux já mascarava segredos vindos de referência SOPS em alguns pontos de erro — mas não nesse caminho específico. Se a substituição falhasse (por exemplo, um valor de secret que violava validação do schema da API do Kubernetes), o valor completo do secret podia aparecer na mensagem de erro, que vai pra status.conditions do objeto e pra um Event do Kubernetes — ambos legíveis por qualquer um com get/list nesses recursos, sem precisar de permissão pra ler o Secret original.

Isso é o mesmo padrão de falha que vimos no cert-manager em setembro: a camada de autorização do Secret continua correta, mas o valor escapa por um canal lateral que ninguém pensa em proteger. O fix (kustomize-controller#1741) estende a redação que já existia pra SOPS também pra esse caminho de substituição.

Outras melhorias

source-controller: listagem de Azure Blob agora normaliza ETags, evitando re-download de containers que não mudaram — reduz custo de egress e tempo de reconciliação em fontes hospedadas em Azure Blob Storage.
source-controller: cache de índice de repositório Helm agora expira entradas obsoletas, evitando erros de “cache is full” em repositórios com índice que muda com frequência.
kustomize-controller ganhou o feature gate opcional DisableCommitStatusEvent (kustomize-controller#1755), pra quem quer parar de mandar commit status pro provedor Git (GitHub/GitLab) — útil se você já tem outro mecanismo de notificação e quer reduzir chamada de API.

O que fazer

Atualizar pra v2.9.6 (ou, se você instala os controllers separado, helm-controller v1.6.5 + kustomize-controller v1.9.6) resolve os três pontos acima sem exigir mudança de configuração — nenhum dos fixes depende de flag nova pra ativar o comportamento corrigido.

Antes de atualizar, vale checar duas coisas:

Se você já tem HelmRelease travado em Ready=Unknown hoje, não espere o patch resolver objetos que já estão presos sem reconciliação nova disparar. Depois do upgrade, force uma reconciliação (flux reconcile helmrelease <nome> -n <namespace>) pra confirmar que ele converge.
Se você usa postBuild.substituteFrom com valores de Secret, audita rapidamente se algum Event ou condição de Kustomization no seu cluster hoje já expõe valor de secret em texto claro — isso teria vindo de uma falha de substituição anterior ao patch. kubectl get events --field-selector involvedObject.kind=Kustomization -A é o ponto de partida. Eventos antigos com o valor exposto continuam visíveis até expirarem (TTL padrão do Kubernetes pra Events é 1h, mas pode ter sido retido por ferramenta de log externa).

Quando isso te afeta mais

Se seu Flux gerencia HelmReleases com drift detection habilitado (comum em clusters onde outras equipes ou operators tocam recursos fora do Git), o fix de recuperação de Ready=Unknown é o que vale upgrade prioritário — é o tipo de bug que te custa tempo de debug sem motivo aparente. Se você usa postBuild.substituteFrom pra injetar segredo em manifest, trate o fix de redação como correção de segurança, não como nice-to-have, e audita os Events existentes antes de assumir que está limpo.