CKA: 9 meses de Kubernetes que a minha prova não cobriu

Passei na CKA (Certified Kubernetes Administrator) em 23/12/2025. Contei como foi a preparação em Como foi minha jornada para a certificação CKA — este artigo é o capítulo seguinte: o que aconteceu com o Kubernetes depois que eu certifiquei.

A pergunta que me fiz foi simples: quanto do que eu estudei continua sendo o estado da arte? Fui atrás da resposta versão por versão, e o resultado é mais interessante do que eu esperava — porque o currículo do exame não mudou uma vírgula no período, mas o ecossistema em volta dele mudou bastante.

O que estava valendo no dia da prova

A CKA não segue o release do Kubernetes automaticamente. A CNCF publica uma versão nova do documento de currículo e só a partir dali o ambiente de prova migra. O commit que trocou v1.34 por v1.35 no repositório cncf/curriculum só aconteceu em 03/03/2026 — mais de dois meses depois da minha prova.

Ou seja: a v1.35 do Kubernetes saiu em 17/12/2025, seis dias antes de eu sentar para a prova, e ainda assim o exame inteiro rodou sobre o currículo v1.34. Não foi sorte de grace period, foi o funcionamento normal do processo.

Três releases depois: 1.35, 1.36 e 1.37

v1.35 "Timbernetes" — 17/12/2025

60 enhancements (17 stable, 19 beta, 22 alpha). O destaque prático:

• In-place Pod resource updates chega a GA — ajustar CPU e memória de um Pod sem recriá-lo. Quem já teve que reiniciar um StatefulSet inteiro para subir o limite de memória de um container sabe o tamanho disso.
• Job.spec.managedBy e supplemental groups de granularidade fina, ambos GA.
• Diretório drop-in para configuração modular do kubelet, GA.
• Em beta: certificados de identidade nativos por Pod, reconciliação de rotas via watch no Cloud Controller Manager, scheduling sensível à carga do workload, tolerations com operadores numéricos e node affinity mutável em PV.

v1.36 "Haru" — 22/04/2026

70 enhancements (18 stable, 25 beta, 25 alpha) — o maior salto do período.

• User Namespaces e Mutating Admission Policies chegam a GA.
• Também GA: autorização granular da API HTTPS do kubelet, SELinux labeling em mount-time, Declarative Validation e Volume Group Snapshots.
• Em beta: toda a família nova de DRA (Partitionable Devices, Consumable Capacity, Device Taints/Tolerations), Gang Scheduling API, Memory QoS via cgroup v2 e resize vertical in-place.
• Removidos de vez: o plugin de volume gitRepo (avisado desde a 1.11), o suporte a flex-volume no kubeadm e o driver in-tree do Portworx.

v1.37 "Garhwal" — 26/08/2026

67 enhancements (16 stable, 23 beta, 27 alpha, 1 remoção). Essa saiu depois de eu começar este levantamento, então vale o registro do que de fato entrou — e não do que o sneak peek prometia.

• KYAML estável na saída do kubectl: kubectl get -o kyaml sai do feature gate e passa a vir ligado por padrão em todo comando que aceita --output. Todo arquivo KYAML continua sendo YAML válido, então nada na pipeline precisa mudar — o ganho é não depender mais de indentação sensível.
• Device taints e tolerations do DRA chegam a stable, com o objeto DeviceTaintRule. Falo disso em detalhe mais abaixo.
• Também GA: Metrics API, Storage Version Migration (ligado por padrão) e Pod Certificates + ClusterTrustBundles.
• Em beta: pod-level resource managers (recursos compartilhados entre containers de um Pod — que o sneak peek anunciava como GA e acabou ficando em beta), Memory QoS, native histograms, kubelet rootless (KubeletInUserNamespace) e HPA com scale-to-zero.

Traduzindo: Mutating Admission Policies

Se você quer alterar um objeto automaticamente no momento em que ele é criado — injetar um sidecar, forçar um label, setar um default — a forma nativa até a v1.36 era escrever e hospedar um webhook: um serviço HTTP seu que o API server chama a cada request, com toda a complexidade de TLS, disponibilidade e latência que isso implica. Se o webhook cai, dependendo do failurePolicy, o cluster para de aceitar Pod.

A v1.36 transforma essa lógica de mutação em um objeto Kubernetes declarado em CEL, sem nenhum serviço próprio no ar:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: injeta-label-de-time
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: >-
          Object{ metadata: Object.metadata{ labels: {"time": "plataforma"} } }

É o mesmo raciocínio que a ValidatingAdmissionPolicy já tinha trazido para validação — isso é anterior à minha prova e cai no currículo — agora estendido para mutação. Na prática, onde hoje existe um webhook mutador em produção (injeção de sidecar de service mesh é o caso clássico), passa a existir uma alternativa nativa sem processo externo para manter no ar.

Traduzindo: a família DRA

A Dynamic Resource Allocation já era GA na minha própria versão, a v1.34 — o mecanismo por trás de scheduling de GPU e TPU deixou de ser experimental exatamente ali. O que chegou depois foram as peças que faltavam para ela ser útil em produção de verdade.

O problema do modelo antigo de device plugin: ele trata dispositivos como inteiros opacos. O nó diz "tenho 2 GPUs disponíveis" e acabou. Não dava para pedir metade de uma GPU, nem dizer quais GPUs precisam estar conectadas entre si por NVLink, nem reagir quando uma delas apresenta falha.

• Partitionable Devices (beta na 1.36) permite fatiar um acelerador em pedaços menores que "a placa inteira".
• Consumable Capacity (beta na 1.36) modela capacidade que se consome, em vez de um contador de unidades.
• Device Taints e Tolerations (beta na 1.36, stable na 1.37) aplica em dispositivos individuais o mesmo padrão de taint/toleration que hoje só existe para nós. Um driver DRA pode marcar um device como tainted para que ele seja pulado no scheduling, e o admin pode aplicar o mesmo taint no cluster inteiro via DeviceTaintRule, sem reconfigurar driver nenhum. Pods que já usam o device podem ser despejados automaticamente, a menos que o ResourceClaim tolere o taint explicitamente.

O ganho operacional é direto: uma GPU com falha de hardware pode ser marcada NoSchedule sem tirar o nó inteiro de circulação.

Networking: o fim do Ingress NGINX

De tudo que mudou no período, essa é a que mais pesa no domínio Services & Networking — 20% do peso do exame. E não porque o texto do currículo mudou, mas porque o controller que praticamente todo mundo usava para praticar Ingress deixou de existir como projeto ativo.

O que foi retirado — e o que não foi

O projeto retirado é o kubernetes/ingress-nginx, mantido pela comunidade sob a SIG Network, que a estimativa oficial aponta como presente em cerca de metade de todos os clusters Kubernetes do mundo.

Duas confusões que vale desfazer:

• Não é o mesmo projeto que o NGINX Ingress Controller da F5 (nginxinc/kubernetes-ingress). Código diferente, mantenedor diferente, não afetado pela decisão.
• A API Ingress continua existindo no Kubernetes, sem plano de remoção. O que não existe mais é o controller de referência que a implementava.

O currículo da CKA nunca citou "ingress-nginx" pelo nome. Ele sempre pediu, em paralelo, "usar Ingress controllers e recursos Ingress" e "usar a Gateway API para gerenciar tráfego de Ingress" — desde antes da minha prova. O que muda na prática é que, se você monta um cluster de estudo hoje, a rota mais óbvia deixou de existir, e a Gateway API virou a primeira opção, não mais a alternativa.

Gateway API na prática

Onde antes um único objeto Ingress concentrava regra de host, path e o nome da IngressClass, a Gateway API separa a coisa em papéis: quem administra a infraestrutura de entrada cria um Gateway (a porta de entrada, ligada a uma GatewayClass que aponta para o controller de fato); quem é dono da aplicação cria um HTTPRoute apontando para esse Gateway, sem precisar saber nada sobre o load balancer por trás.

# Antes: um Ingress só, misturando infraestrutura e regra de aplicação
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
spec:
  ingressClassName: nginx
  rules:
    - host: api.exemplo.com.br
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: api-v1
                port:
                  number: 80

# Depois: Gateway (time de infra) e HTTPRoute (time de aplicação), separados
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs:
    - name: gateway-publico
  hostnames:
    - "api.exemplo.com.br"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-v1
          port: 80

Essa migração eu já fiz na prática, com conversão automatizada e auditoria do que não dava para converter — está contada em De NGINX Ingress para Envoy Gateway. Aqui fica só o contexto de por que ela virou obrigatória.

O currículo da CKA não mudou uma linha

Baixei os dois PDFs oficiais do cncf/curriculum — o v1.34, vigente quando certifiquei, e o v1.35, vigente hoje — e comparei. São idênticos: mesmos cinco domínios, mesmos pesos, mesmas bullets, palavra por palavra. Só o número da versão no rodapé mudou.

Não era o que eu esperava encontrar, mas registrar "nada mudou" é mais útil do que inventar uma diferença que não existe.

A última revisão de conteúdo de fato — não só de número de versão — foi em fevereiro de 2025, quando Helm, Kustomize, Gateway API, NetworkPolicy, CRDs e as interfaces de extensão (CNI, CSI, CRI) entraram no currículo. Isso é anterior à minha prova: eu já fui testado sobre tudo isso.

A conclusão incômoda é que a lacuna real não está no texto do currículo. Está no que mudou por fora dele.

Comunidade e roadmap: o que ainda não virou currículo

Quatro movimentos do período que não caem em nenhuma bullet do exame, mas dizem para onde o Kubernetes está indo.

O que eu realmente vou praticar

A CKA vale até 23/12/2027 e nada aqui invalida o certificado — recertificar não é necessário por causa de nenhuma dessas mudanças. Se o objetivo é continuar afiado, o levantamento aponta dois pontos, e só dois:

• A família DRA. Device management para GPU e cargas de IA não tem linha própria no currículo, mas é onde o projeto está concentrando esforço de verdade. Vale montar um cenário com DeviceTaintRule e entender o ciclo de ResourceClaim.
• A migração definitiva de Ingress para Gateway API. O currículo já cobria os dois desde antes da prova. O que mudou foi qual dos dois ainda existe como implementação de referência.

Todo o resto — troubleshooting, kubeadm, RBAC, NetworkPolicy, storage — continua exatamente como estava. O que é, no fundo, uma boa notícia sobre a estabilidade do que a certificação cobra.

Referências

• Kubernetes v1.35: Timbernetes
• Kubernetes v1.36 released — InfoQ
• Kubernetes v1.37: Garhwal
• Kubernetes v1.37: DRA Updates
• Device Taints and Tolerations — documentação oficial
• Comunicado oficial de retirada do Ingress NGINX
• The end of an era: transitioning away from Ingress NGINX — Google Open Source Blog
• Spotlight do WG Device Management
• Anúncio do AI Gateway Working Group
• Anúncio do Checkpoint/Restore Working Group
• cncf/curriculum — PDFs oficiais do currículo da CKA