Kyverno v1.19.2: roteiro para avaliar e aplicar a atualização em clusters

Atualizar o mecanismo que decide quais recursos podem entrar no Kubernetes exige mais do que verificar se os novos Pods ficaram prontos. A aprovação precisa demonstrar duas coisas: workloads legítimos continuam funcionando e recursos proibidos continuam sendo rejeitados.

O Kyverno v1.19.2 foi publicado em 20 de outubro de 2026. Na consulta realizada para este artigo, em 24 de outubro de 2026, era a versão estável mais recente. A release informa correções para 24 avisos de segurança: nove críticos, 14 altos e um moderado. A exposição de cada ambiente depende das versões afetadas e das funcionalidades utilizadas; a contagem não significa que todos os clusters sejam exploráveis por todos os problemas. (github.com)

Este roteiro propõe uma atualização por etapas, com evidências de segurança, compatibilidade e recuperação. Os exemplos pressupõem uma instalação existente via Helm, com release e namespace chamados kyverno. Adapte esses nomes e execute primeiro em homologação.

1. Entenda o componente que será atualizado

Kyverno é um mecanismo de políticas para Kubernetes. Ele permite validar e modificar recursos, automatizar geração de objetos e verificar imagens. Parte desse processamento participa da admissão: o API server consulta webhooks antes de persistir uma operação. Não é um proxy no caminho das requisições HTTP da aplicação. (kyverno.io)

O fluxo simplificado é:

CI/CD ou kubectl → API server → admissão e políticas → persistência → controllers da aplicação

CI/CD significa integração e entrega contínuas. O impacto operacional do upgrade concentra-se nas operações da API Kubernetes e nas reconciliações, não no tráfego entre um usuário e uma API já em execução. (kubernetes.io)

A instalação separa responsabilidades:

• Admission controller: atende webhooks e executa verificações na admissão.
• Background controller: processa geração e mutação de recursos existentes.
• Reports controller: produz e reconcilia relatórios de políticas.
• Cleanup controller: executa funcionalidades de limpeza.
• CRDs: Custom Resource Definitions, que registram tipos de recursos personalizados.
• ServiceAccounts e RBAC: identidades e controle de acesso baseado em papéis, separados por controller. (kyverno.io)

A recomendação deste roteiro é tratar esses componentes como infraestrutura crítica da plataforma, com responsáveis, testes e critérios de disponibilidade próprios.

2. Separe o patch de segurança da migração da linha 1.19

O chart correspondente à aplicação v1.19.2 é `3.9.2`. Versão do chart e versão da aplicação são identificadores diferentes; não use --version 1.19.2 esperando selecionar esse chart. A relação está no Chart.yaml da tag oficial. (raw.githubusercontent.com)

Para quem já executa 1.19.1, o foco é o patch e seus efeitos sobre políticas existentes. Para quem chega de uma versão anterior, existe também uma migração funcional: na linha 1.19, ClusterPolicy, Policy, políticas legadas de cleanup e a PolicyException legada estão deprecated, com remoção anunciada para 1.20. Os tipos baseados em CEL, Common Expression Language, são o caminho de evolução. Não confunda depreciação com remoção imediata em 1.19.2. (kyverno.io)

Matriz de regressão orientada aos riscos

Monte testes a partir das funcionalidades realmente utilizadas:

Esses testes foram escolhidos porque os avisos oficiais descrevem problemas nessas áreas, e não porque uma atualização de patch deva ser presumida transparente. Execute testes negativos em ambiente isolado, sem reproduzir cargas abusivas em produção. (github.com)

3. Gate de compatibilidade: quando não avançar

Na documentação consultada em 24 de outubro de 2026, a linha Kyverno 1.19 declara suporte ao Kubernetes 1.33–1.35. Outras versões podem funcionar, mas não recebem a mesma garantia de compatibilidade testada. O mínimo kubeVersion declarado pelo chart não substitui essa matriz. A documentação também estima o fim do suporte comunitário dessa linha na chegada da 1.20, prevista para novembro de 2026; essa previsão não é uma data garantida. (kyverno.io)

Minha proposta de gate é bloquear a promoção se houver:

• versão Kubernetes fora da matriz sem validação e aceite explícitos;
• caminho de atualização intermediário não revisado;
• ownership de CRDs indefinido;
• testes negativos ausentes;
• ausência de recuperação ensaiada;
• saturação ou indisponibilidade preexistentes sem diagnóstico.

Não atualize apenas tags de imagens: recursos auxiliares e CRDs também podem mudar. Para instalações antigas, revise as notas de todas as versões intermediárias. Este procedimento Helm não deve ser aplicado automaticamente a instalações gerenciadas por manifestos YAML. (kyverno.io)

4. Inventário e backup antes da alteração

Primeiro, confirme contexto, versão e estado do cluster. Os comandos abaixo apenas consultam recursos:

kubectl config current-context
kubectl version
helm version
helm list -n kyverno
helm history kyverno -n kyverno
kubectl get deployments,pods,services -n kyverno -o wide
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
kubectl api-resources --api-group=kyverno.io
kubectl api-resources --api-group=policies.kyverno.io

Use a descoberta de APIs para identificar os tipos realmente instalados e empregue nomes qualificados por grupo quando houver ambiguidade. (kubernetes.io)

Registre os valores fornecidos pelo operador separadamente dos valores efetivos, que incluem defaults:

umask 077
mkdir -p backup-kyverno
helm get values kyverno -n kyverno -o yaml > backup-kyverno/values-user.yaml
helm get values kyverno -n kyverno --all -o yaml > backup-kyverno/values-effective.yaml
helm get manifest kyverno -n kyverno > backup-kyverno/release.yaml
kubectl get crd -o yaml > backup-kyverno/crds.yaml

--all permite registrar os valores computados. Use essa saída para comparação, não como arquivo de upgrade automaticamente: defaults antigos não devem ser preservados sem revisão. (helm.sh)

Como plano de recuperação, proponho guardar também políticas, exceções, configurações, objetos gerados relevantes, revisão Git e artefatos da release anterior. Faça exportações dos tipos identificados no inventário; os comandos acima não constituem um backup completo.

Proteja os arquivos com criptografia e acesso restrito. Não envie Secrets ou manifests sensíveis para um repositório público. Defina RTO, objetivo de tempo de recuperação, e RPO, objetivo de ponto de recuperação, e ensaie a restauração em cluster descartável.

CRDs precisam de um responsável explícito

A linha 1.19 introduz a dependência kyverno-api para gerenciamento de CRDs, controlada por crds.install. Se os CRDs são mantidos separadamente, revise esse fluxo. A documentação distingue ainda API servida de versão de armazenamento: em 1.19, os tipos policies.kyverno.io mantêm v1beta1 como storage version, apesar do uso de v1 nos manifests. (kyverno.io)

Inspecione spec.versions e status.storedVersions das CRDs relevantes. Minha recomendação é não editar storedVersions manualmente para silenciar erros e não misturar migração de armazenamento, conversão de políticas e patch de segurança sem necessidade.

5. Prepare valores revisados e alta disponibilidade

O arquivo abaixo é um overlay ilustrativo, não uma configuração completa de produção. Ele utiliza chaves presentes no chart 3.9.2:

admissionController:
  replicas: 3
  podDisruptionBudget:
    enabled: true
    minAvailable: 2
  container:
    resources:
      requests:
        cpu: 250m
        memory: 256Mi
      limits:
        memory: 768Mi
backgroundController:
  replicas: 2
cleanupController:
  replicas: 2
reportsController:
  replicas: 2

replicas define redundância por controller; container.resources dimensiona o admission controller; podDisruptionBudget configura o orçamento de interrupções. Os números são exemplos para teste, não recomendações universais. Integre esse overlay aos valores existentes revisados e salve o resultado como values-reviewed.yaml. Preserve configurações necessárias de rede, certificados e registries. (raw.githubusercontent.com)

Alta disponibilidade não significa escalabilidade linear: controllers podem ter comportamentos distintos de liderança e distribuição de trabalho. Distribua as réplicas entre nós e zonas e teste a perda de um domínio de falha. (kyverno.io)

Um PodDisruptionBudget limita determinadas interrupções voluntárias; não protege contra toda falha e não substitui a estratégia de rolling update do Deployment. Verifique também capacidade para réplicas adicionais durante o rollout. (kubernetes.io)

Para dimensionamento, reproduza picos de admissão, quantidade de políticas correspondentes e dependências externas. A documentação recomenda medições locais e alerta para o impacto de seletores amplos; também recomenda evitar limites de CPU. Se a organização exigir esses limites, teste throttling explicitamente. (kyverno.io)

Em desenvolvimento, uma réplica pode ser aceitável para experimentação. Para produção, proponho exigir redundância, probes verificadas, recursos dimensionados, distribuição entre falhas, alertas e recuperação. Não habilite autoscaling apenas para cumprir um checklist: valide primeiro a capacidade mínima e a resposta aos picos.

6. Faça um smoke test de política em escopo isolado

O exemplo completo abaixo cria um namespace de teste e uma ValidatingPolicy que exige a label owner em ConfigMaps desse namespace. Começa em Audit:

apiVersion: v1
kind: Namespace
metadata:
  name: policy-upgrade-test
---
apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: upgrade-require-configmap-owner
spec:
  validationActions:
    - Audit
  matchConstraints:
    namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: policy-upgrade-test
    resourceRules:
      - apiGroups: [""]
        apiVersions: [v1]
        operations: [CREATE, UPDATE]
        resources: [configmaps]
  validations:
    - expression: "has(object.metadata.labels) && 'owner' in object.metadata.labels"
      message: "ConfigMaps must declare an owner label."
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: upgrade-valid
  namespace: policy-upgrade-test
  labels:
    owner: platform-engineering
data:
  purpose: upgrade-smoke-test

matchConstraints limita o alcance; a expressão CEL verifica a presença da label. Audit não bloqueia a violação; Deny permite testar rejeição. Adapte o namespace e a regra. Essa política é um teste didático, não uma política corporativa completa. (kyverno.io)

Procedimento proposto:

1. Aplique o arquivo no cluster de homologação atualizado.
2. Aguarde a política e suas configurações de admissão estarem reconciliadas.
3. Confirme a aceitação do ConfigMap válido.
4. Crie uma cópia chamada upgrade-invalid, sem metadata.labels.
5. Altere somente essa política de teste para Deny.
6. Confirme que o objeto válido continua aceito e o inválido é rejeitado pela regra esperada.

Não coloque todas as políticas de produção em auditoria para facilitar o upgrade. O teste isolado deve complementar, não enfraquecer, os controles existentes.

Execute também a suíte existente com a CLI, interface de linha de comando, na versão alvo:

kyverno version
kyverno test ./tests

./tests precisa conter testes Kyverno válidos, com recursos e resultados esperados. Testes locais não substituem a validação integrada de webhooks, permissões e dependências no cluster. (kyverno.io)

7. Renderize, revise e atualize por ondas

Os exemplos seguintes usam a sintaxe do Helm 3. Se o ambiente utiliza Helm 4, valide os comandos e a semântica de espera e recuperação da versão instalada antes de executar. (helm.sh)

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm show chart kyverno/kyverno --version 3.9.2
helm show values kyverno/kyverno --version 3.9.2 > values-target-defaults.yaml
helm template kyverno kyverno/kyverno \
  --namespace kyverno \
  --version 3.9.2 \
  --is-upgrade \
  --include-crds \
  -f values-reviewed.yaml > rendered-kyverno.yaml

Compare o resultado com a release atual: imagens, CRDs, RBAC, hooks, Services, webhooks e scheduling. helm template renderiza localmente, mas não comprova compatibilidade com o API server nem executa os hooks. (helm.sh)

Após aprovação, execute em um único cluster de homologação:

helm upgrade kyverno kyverno/kyverno \
  --namespace kyverno \
  --version 3.9.2 \
  -f values-reviewed.yaml \
  --wait \
  --wait-for-jobs \
  --timeout 10m

O timeout de dez minutos é ilustrativo. --wait e --wait-for-jobs não validam a semântica das políticas. O exemplo não usa --atomic: rollback automático só deve ser habilitado depois de comprovar a segurança do caminho de retorno, especialmente envolvendo CRDs. (helm.sh)

Minha sequência recomendada é: homologação → cluster piloto de produção → grupos pequenos → restante da frota. Não instale uma segunda release independente no mesmo cluster como canário sem um desenho explícito para ownership e escopo.

Em GitOps, faça a mudança pelo repositório e pelo reconciliador. Use os comandos imperativos como referência de laboratório ou procedimento autorizado, evitando disputa entre estado manual e declarado.

8. Observabilidade e critérios de promoção

Proponho registrar uma baseline e acompanhar:

• latência de admissão nos percentis 95 e 99;
• volume de operações e erros de webhook;
• rejeições esperadas versus rejeições inesperadas;
• CPU, memória, reinicializações e disponibilidade por controller;
• atraso de reconciliação e atualização dos relatórios.

Kyverno oferece integração de monitoramento; use Prometheus e Grafana conforme a arquitetura existente. Confirme os nomes e labels das métricas realmente expostas antes de criar consultas e alertas. (kyverno.io)

Centralize logs e correlacione a janela do upgrade com erros do API server. Quando habilitado, tracing ajuda a investigar o caminho de processamento; mantenha amostragem e retenção controladas. Não suponha que traces estejam ativos por padrão. (kyverno.io)

Relatórios são evidências complementares de avaliação, não substitutos do teste de bloqueio na admissão. Verifique sua atualização e evite interpretar ausência de novos resultados como sucesso automático. (kyverno.io)

Como critérios de promoção, proponho exigir aprovação de todos os casos críticos, ausência de bypass, dependências saudáveis e atendimento ao SLO, objetivo de nível de serviço, definido pela equipe. Defina previamente o tempo de observação; não invente uma tolerância de latência durante o incidente.

9. Segurança e operação econômica

Revise quem pode criar políticas, conceder exceções e modificar configurações do Kyverno. Preserve ServiceAccounts separadas, RBAC mínimo e comunicação TLS, Transport Layer Security. Restrinja permissões adicionais aos recursos efetivamente necessários; não corrija um erro Forbidden concedendo cluster-admin. (kyverno.io)

Para produção, minha proposta inclui validar conectividade do control plane aos webhooks antes de endurecer NetworkPolicies, manter endpoints internos e testar indisponibilidade de registries e serviços externos. Exceções devem ter responsável, justificativa, escopo e processo de expiração.

No planejamento FinOps, use um orçamento explícito para redundância, armazenamento de logs e retenção de métricas. Priorize capacidade estável para o mínimo operacional; avalie Spot somente com testes de interrupção e reposição. Revise custos de tráfego entre zonas e de dependências externas sem sacrificar disponibilidade apenas para reduzir a fatura.

Evite superdimensionar todos os controllers da mesma forma. Faça right sizing com medições representativas, mantendo margem para rollout e recuperação, e reduza cardinalidade e retenção desnecessárias na observabilidade.

10. Troubleshooting e recuperação

Use esta sequência inicial, adaptando o nome do Pod:

kubectl get pods -n kyverno -o wide
kubectl get deployments -n kyverno
kubectl get services,endpointslices -n kyverno
kubectl describe pod <pod> -n kyverno
kubectl logs <pod> -n kyverno --all-containers=true --tail=200
kubectl logs <pod> -n kyverno --all-containers=true --previous
kubectl get events -n kyverno --sort-by=.metadata.creationTimestamp

Para containers que nunca reiniciaram, --previous não terá logs anteriores. A documentação de troubleshooting recomenda examinar estado dos componentes, logs e comunicação dos webhooks. (kyverno.io)

A tabela é um roteiro de hipóteses, não um diagnóstico automático. Diferencie negação de política de falha de transporte. No webhook, failurePolicy: Ignore trata determinados erros de chamada; não significa ignorar toda negação explícita. Sua adoção pode permitir operações sem avaliação durante falhas. (kubernetes.io)

Rollback não é apenas voltar a imagem

Se o caminho tiver sido ensaiado, selecione uma revisão conhecida:

helm history kyverno -n kyverno
REVISION=7
helm rollback kyverno "$REVISION" \
  --namespace kyverno \
  --wait \
  --wait-for-jobs \
  --timeout 10m

7 é um exemplo; substitua pela revisão aprovada. O comando restaura uma revisão Helm, não oferece garantia de desfazer todas as migrações ou efeitos externos. (helm.sh)

Minha recomendação é verificar separadamente compatibilidade das CRDs, objetos persistidos, recursos gerados e políticas nativas eventualmente criadas. Se o downgrade não for seguro, prefira uma correção direcionada ou recuperação ensaiada. Voltar a uma versão afetada exige aceite de risco de segurança.

Nunca remova indiscriminadamente CRDs ou todos os webhooks como procedimento padrão. O acesso emergencial deve ser limitado, auditável e acompanhado de restauração dos controles.

11. Quando utilizar e quais alternativas considerar

Kyverno é adequado quando a plataforma precisa de políticas reutilizáveis, verificações de imagens, automação de recursos e avaliação integrada ao ciclo de entrega. Para um ambiente pequeno com poucas validações, recomendo avaliar uma solução mais simples antes de adicionar controllers.

ValidatingAdmissionPolicy, do próprio Kubernetes, executa validações CEL no API server, sem webhook externo para essa avaliação. Pode reduzir componentes operacionais quando seus recursos atendem ao caso de uso. (kubernetes.io)

OPA Gatekeeper é outra opção, especialmente para equipes que já mantêm políticas com Open Policy Agent e Rego. Sua arquitetura utiliza constraints e templates; a decisão deve considerar competências, biblioteca existente e custo de operação, não apenas preferência de sintaxe. (open-policy-agent.github.io)

A recomendação é evitar controles sobrepostos sem ownership claro. Portabilidade entre clouds não elimina o custo de migrar políticas específicas de um mecanismo.

Resumo prático

• Confirme a relação entre aplicação v1.19.2 e chart 3.9.2.
• Trate compatibilidade, CRDs e retorno como gates explícitos.
• Valide comportamento permitido e proibido.
• Faça rollout por clusters, com observação entre ondas.
• Preserve controles de segurança durante a mudança.
• Documente recuperação, evidências e responsáveis.

Conclusão

A atualização deve ser aprovada pela manutenção das garantias da plataforma, não apenas pelo estado Ready dos Pods. O resultado esperado é um conjunto verificável de políticas, caminhos de recuperação e sinais operacionais que permita atualizar novamente com menos incerteza.

Essa disciplina conecta DevSecOps, SRE e Platform Engineering: segurança define o que não pode ser violado, confiabilidade define como operar sob falha e a plataforma transforma ambos em um processo repetível de entrega.