O Kubernetes 1.36 chega em 22 de abril com 18 melhorias graduating to stable — mas o que já aconteceu antes do release pode ter impacto maior no seu cluster.

Em 24 de março de 2026, o Ingress-Nginx foi oficialmente aposentado. Sem patches de segurança, sem suporte. O projeto encerrou após mais de uma década como a solução mais usada de ingress no Kubernetes. Se o seu cluster depende do ingress-nginx, você precisa de um plano de migração agora.

O substituto recomendado é a Gateway API, que chega madura neste ciclo com adoção crescente pelos principais ingress controllers do mercado. E no lado do hardware, quatro enhancements do Dynamic Resource Allocation (DRA) chegam à stable no 1.36. O DRA atingiu GA no Kubernetes 1.34; os novos enhancements cobrem particionamento de GPUs, taints de devices e observabilidade.

O que muda no Kubernetes 1.36

O release 1.36, previsto para 22 de abril de 2026, tem 18 enhancements graduating to stable. É um ciclo com pesos diferentes: menos features experimentais novas, mais estabilização de trabalho que vinha acontecendo nos últimos dois anos.

Os destaques que afetam a maioria dos clusters:

  • DRA (Dynamic Resource Allocation): quatro enhancements chegando ao stable (Device Taints and Tolerations, Partitionable Devices, Pod Resources API for DRA, DRAAdminAccess)
  • Linux User Namespaces: suporte estável para pods rodarem com UIDs isolados, sem privilégio root no host
  • Structured Authentication Config: nova API para configurar webhook authenticators de forma declarativa, substituindo flags de linha de comando

Para times que usam aceleradores de hardware (GPUs, TPUs, FPGAs) no Kubernetes, o DRA é a mudança mais material. Para quem opera clusters multitenanted com políticas de segurança rígidas, os User Namespaces em GA são relevantes.

Ingress-Nginx aposentado: o que acontece agora

O repositório kubernetes/ingress-nginx entrou em modo de manutenção em novembro de 2025, com anúncio de que as atualizações de segurança encerrariam em março de 2026. Em 24 de março, a retirada foi efetivada.

O que isso significa na prática: qualquer CVE descoberto no ingress-nginx a partir dessa data não vai receber patch. O projeto já tinha um histórico pesado de vulnerabilidades críticas. O CVE-2025-1974, que permitia RCE não autenticado no pod do ingress (CVSS 9.8), foi o gatilho final para acelerar a decisão de retirada.

Se o seu cluster roda kubernetes/ingress-nginx, verifique qual versão está instalada:

kubectl get pods -n ingress-nginx -o jsonpath='{.items[*].spec.containers[*].image}'

Versões antes do 1.11.5 (branch 1.11) ou antes do 1.12.1 (branch 1.12) estão expostas ao CVE-2025-1974. Versões mais recentes nessas branches receberam o patch, mas não receberão mais nenhum.

As alternativas para quem precisa migrar:

  • Gateway API: o caminho oficial do projeto Kubernetes, com suporte crescente dos principais provedores
  • F5 NGINX Ingress Controller: fork mantido pela F5, baseado no NGINX, mas sem relação com o kubernetes/ingress-nginx
  • Traefik: popular em ambientes onde a configuração dinâmica importa
  • HAProxy Ingress: boa opção para clusters que já usam HAProxy
  • Kong: para times que precisam de API gateway junto com ingress

A recomendação do projeto Kubernetes é a Gateway API. É o único standard desenvolvido nativamente pelo projeto Kubernetes, com todos os principais ingress controllers adicionando suporte a ela.

Gateway API: arquitetura e diferenças em relação ao Ingress

O Ingress do Kubernetes existe desde 2015 com um modelo simples: um objeto Ingress configurava roteamento HTTP para serviços. Funcionou por anos, mas tinha limitações estruturais que geravam extensões via annotations, onde cada ingress controller tinha suas próprias annotations incompatíveis.

A Gateway API resolve isso com uma hierarquia de três objetos.

GatewayClass define a implementação (quem vai processar os objetos Gateway e HTTPRoute). É configurado pelo operador do cluster:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx-gateway
spec:
  controllerName: gateway.nginx.org/nginx-gateway-controller

Gateway define um ponto de entrada com porta, protocolo e certificado TLS. O time de plataforma normalmente cria e gerencia:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: api-gateway
  namespace: infra
spec:
  gatewayClassName: nginx-gateway
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: api-tls-cert

HTTPRoute define as regras de roteamento para um ou mais serviços. Times de aplicação gerenciam o próprio, sem acesso ao Gateway:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders-route
  namespace: orders
spec:
  parentRefs:
  - name: api-gateway
    namespace: infra
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /orders
    backendRefs:
    - name: orders-service
      port: 8080

A separação de responsabilidades é o ganho real. No modelo Ingress, o time de aplicação precisa modificar um recurso que geralmente fica na mesma namespace do ingress controller, ou criar objetos que o operador do cluster também precisa modificar. Com a Gateway API, cada camada tem seu objeto próprio.

Na prática: migrando de Ingress para HTTPRoute

A migração não é uma substituição one-to-one de YAML, mas é mais direta do que parece.

Passo 1: escolher e instalar uma implementação da Gateway API. A maioria dos ingress controllers já tem suporte: NGINX Gateway Fabric, Traefik, Istio, Kong. Para clusters sem ingress controller atual:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.1/standard-install.yaml

Passo 2: criar o GatewayClass e o Gateway (responsabilidade da equipe de plataforma).

Passo 3: converter cada objeto Ingress em HTTPRoute. Um Ingress típico:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

Se torna:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs:
  - name: api-gateway
    namespace: infra
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: api-service
      port: 8080

O rewrite-target que estava em annotation vira um filtro explícito no HTTPRoute. Funcionalidades que você resolvia com annotations no ingress-nginx agora têm campos explícitos na Gateway API. O resultado é YAML mais verboso, mas sem a dependência de annotations específicas do controller.

Quatro enhancements DRA chegam ao stable

O Dynamic Resource Allocation foi introduzido como alpha no Kubernetes 1.26 para resolver um problema concreto: o mecanismo de device plugins que gerenciava GPUs e outros aceleradores não era flexível o suficiente para cenários de compartilhamento de hardware. O DRA atingiu GA no Kubernetes 1.34; o 1.36 adiciona quatro enhancements ao stable.

Com device plugins clássicos, uma GPU estava disponível inteira para um pod ou não estava disponível. Não havia como dois pods compartilharem a mesma GPU, ou como um pod requisitar um subconjunto das capacidades de um acelerador.

O DRA resolve isso com um modelo de ResourceClaim, onde o pod descreve o que precisa e o scheduler aloca o recurso com base na disponibilidade:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-claim
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: gpu.example.com
      count: 1

No pod:

spec:
  resourceClaims:
  - name: gpu-claim
    resourceClaimName: gpu-claim
  containers:
  - name: training
    image: training-job:latest
    resources:
      claims:
      - name: gpu-claim

No Kubernetes 1.36, os quatro enhancements que chegam ao stable são: Device Taints and Tolerations (drivers podem marcar devices como indisponíveis para scheduling, sem removê-los), Partitionable Devices (divide um acelerador como GPU em unidades lógicas compartilháveis entre pods), Pod Resources API for DRA (acesso a métricas por pod para billing e monitoring de hardware), e DRAAdminAccess (path privilegiado para operadores monitorarem devices alocados). Com esses quatro no stable, o ecossistema DRA tem as peças que faltavam para adoção ampla em produção.

Para times que hoje usam device plugins para GPUs em workloads de inferência ou treinamento, vale olhar o DRA antes do próximo ciclo de planejamento de infraestrutura.

Conclusão

O Kubernetes 1.36 não é o ciclo mais espetacular de features novas — é o ciclo que consolida trabalho de longo prazo. Os quatro enhancements DRA chegando ao stable completam o ecossistema para hardware especializado: particionamento de GPUs, taints de devices e observabilidade granular por pod. Os User Namespaces em GA resolvem um problema de segurança que estava pendente há muito tempo.

O que demanda atenção imediata é o Ingress-Nginx. A retirada aconteceu, e o projeto não vai receber mais patches. Clusters em produção dependentes do kubernetes/ingress-nginx têm um prazo real para migração, não hipotético. A Gateway API é o caminho mais alinhado com a direção do projeto Kubernetes, mas qualquer um dos controllers listados acima resolve o problema de segurança no curto prazo.

O K8s 1.36 será lançado em 22 de abril. Para acompanhar o ciclo de releases atual e os enhancements individuais, o repositório kubernetes/enhancements no GitHub tem o rastreamento completo.

Referências pesquisadas nesta publicação