TL;DR: Primeira semana cheia de 2026, de menor volume, mas com um tema único: devolver controle fino ao operador. O Kubernetes v1.35 abriu o ano com operadores numéricos (Gt/Lt) em tolerations, nodeAffinity mutável em PVs, tokens de Service Account via campo secrets e allowlist de plugins de credencial no kuberc. Em paralelo, o OKE ganhou Generic VNIC Attachment para networking granular e a AWS estreou Graviton4 com Spot no ECS Managed Instances.
O calendário de janeiro engana. Depois do volume do re:Invent e do KubeCon de fim de ano, a primeira semana cheia de 2026 chega com poucas manchetes — e é justamente nessas semanas magras que dá para ler o tema sem ruído. Desta vez o fio condutor foi nítido: tanto o Kubernetes quanto os provedores começaram o ano devolvendo controle granular para quem opera a infraestrutura. Menos abstração opinativa, mais alavancas finas na mão do time de plataforma.
O grosso veio do Kubernetes v1.35, a primeira release do ano, que dominou a semana com quatro anúncios encaixados no mesmo eixo: scheduling mais inteligente (operadores numéricos em tolerations), storage stateful menos rígido (nodeAffinity mutável em PersistentVolumes), entrega de credenciais mais segura para CSI drivers e uma trava de segurança no client-side do kubectl. Do lado dos provedores, a Oracle anunciou o Generic VNIC Attachment para o OKE — controle fino de networking que antes exigia gambiarra — e a AWS abriu 2026 com Graviton4 e Spot no ECS gerenciado, ambos com cara de FinOps.
Para quem opera infra no Brasil, a leitura é a de sempre, com timing favorável: o início de ano é a janela para revisar guardrails antes do volume voltar. E o recado de janeiro foi que as ferramentas para fazer isso com precisão acabaram de ficar melhores.
Por que o Kubernetes v1.35 entregou granularidade fina em vez de features de vitrine?
A primeira release de 2026 não trouxe um recurso de palco — trouxe quatro ajustes cirúrgicos que tornam o cluster mais governável. O mais expressivo são os Extended Toleration Operators, em alpha: a v1.35 adiciona os operadores Gt (maior que) e Lt (menor que) ao spec.tolerations. Até aqui, taints e tolerations só sabiam comparar valor exato (Equal) ou existência (Exists), o que obrigava a inventar categorias discretas de taint ou plugar admission controllers externos para qualquer decisão baseada em número. Agora um Pod consegue dizer "tolero nós com failure-probability menor que 5" ou "só treino em nó com gpu-compute-score acima de 800". É scheduling consciente de SLA, FinOps e performance escrito direto no manifesto — preservando a vantagem de inverter o controle: o nó declara seu risco via taint, e só Pods com tolerância correspondente pousam ali. É alpha, atrás do feature gate TaintTolerationComparisonOperators, e o roadmap aponta para CEL e integração com o cluster-autoscaler.
A segunda alavanca é de storage. Desde a v1.10 o nodeAffinity de um PersistentVolume era imutável — para mudar a topologia de um volume com estado, era preciso recriá-lo, com downtime e risco. A v1.35 torna esse campo mutável, também em alpha (feature gate MutablePVNodeAffinity), destravando casos como migrar um disco de zonal para regional sem deletar o PV. O alerta vem no pacote: alterar o nodeAffinity no Kubernetes não altera a acessibilidade do volume no provedor — o storage subjacente precisa estar pronto antes —, e apertar a regra abre uma race condition que pode travar Pods em ContainerCreating com base em cache antigo. Recurso para administrador de cluster, não para PVC de aplicação — ainda.
As outras duas mudanças são puro SecOps. Na entrega de tokens de Service Account para CSI drivers (beta), o token deixa de viajar pelo volume_context — que nunca foi pensado para dado sensível e já causou vazamento em logs de gRPC, com direito a CVE-2023-2878 e CVE-2024-3744 — e passa, por opt-in, ao campo secrets do NodePublishVolumeRequest, onde as ferramentas de log já sabem o que ocultar. E no client-side, o kuberc ganhou allowlist de plugins de credencial (beta): o kubectl pode executar binários arbitrários via users[n].exec.command do kubeconfig, então um arquivo malicioso ou um pipeline comprometido viram execução de código na máquina do dev. Os campos credentialPluginPolicy e credentialPluginAllowlist permitem DenyAll, AllowAll ou uma lista explícita — com checksum sha256 já no roadmap do SIG CLI.
O OKE devolveu o controle do networking: o que muda com o Generic VNIC Attachment
Se a v1.35 mexeu no scheduling e na segurança, a Oracle foi atrás da camada que historicamente menos cede controle em Kubernetes gerenciado: a rede. O Generic VNIC Attachment (GVA) para o OCI Kubernetes Engine, anunciado em disponibilidade limitada, ataca uma limitação concreta do modelo opinativo. Hoje, com o Flannel CNI cada nó recebe uma única VNIC, e com o VCN Native CNI os nós ganham uma VNIC primária para o tráfego do nó e uma secundária para os pods — ambas com configuração idêntica e sem espaço para customização. Não dá para escolher quantas VNICs alocar, configurá-las de forma distinta ou decidir qual pod usa qual interface. Para quem tem requisito de conformidade ou performance específico, isso virava script customizado e workaround.
O GVA inverte a lógica e devolve as alavancas ao time de infraestrutura: dá para especificar a quantidade e quais VNICs anexar a worker nodes e pods, configurar cada VNIC individualmente — número de IPs, família IPv4/IPv6, subnet, Network Security Groups (NSGs) e tags — e agendar pods específicos para VNICs determinadas. Na prática, isso habilita três coisas que antes exigiam fricção: isolamento de rede real, em que múltiplas unidades de negócio compartilham o mesmo cluster mantendo separação a nível de rede; roteamento por workload, separando fisicamente tráfego de gerenciamento e de dados — útil para VNFs e gateways de segurança; e previsibilidade de performance, dedicando interfaces a cargas de alto throughput para evitar contenção no host.
O ângulo para o mercado brasileiro é direto: o GVA aproxima o OKE das arquiteturas de rede on-premises mais complexas, que costumavam ser o motivo para não migrar certos workloads. Vale o cuidado de sempre — é disponibilidade limitada, então convém validar a aderência ao caso de uso antes de desenhar a arquitetura em cima dele. Mas o movimento confirma a tendência da semana: o Kubernetes gerenciado está abrindo mão da rigidez para reconquistar quem precisa de controle granular.
A AWS abriu 2026 com Graviton4 e Spot no ECS: o ano começa por FinOps?
Do lado da AWS, o primeiro Weekly Roundup do ano teve menos fogos e mais substância de custo — coerente com o tom geral de janeiro. O destaque de eficiência são as novas instâncias EC2 M8gn e M8gb, com processadores Graviton4, que entregam até 30% mais performance de compute que a geração anterior e elevam o teto para cargas network-intensive: até 600 Gbps de banda de rede e 150 Gbps de EBS. Para quem tem alto tráfego de rede ou dependência pesada de EBS, é a chance de consolidar workloads e reduzir o sprawl de instâncias — fazer mais com menos máquinas.
A mudança de maior impacto em FinOps, porém, é em containers: o ECS Managed Instances passou a suportar EC2 Spot Instances, combinando a facilidade da infraestrutura gerenciada com economias de até 90% em workloads tolerantes a falha. Casa, aliás, com a novidade do Kubernetes da mesma semana — os operadores Gt/Lt em tolerations existem justamente para domar clusters que misturam nós sob demanda e spot. A mensagem dos dois lados é a mesma: capacidade preemptível deixou de ser truque e virou ferramenta de primeira classe, desde que a arquitetura esteja preparada para a interrupção.
O roundup ainda trouxe peças menores que valem o radar: o AWS Fault Injection Service (FIS) agora injeta falhas em sessões BGP do Direct Connect, o que permite testar de verdade o failover de conectividade híbrida antes do incidente; o AWS Control Tower ganhou suporte a 176 novos controles do Security Hub para governança multi-account; o AWS Transform for VMware passou a converter redes automaticamente, mapeando VLANs e faixas de IP on-premises para VPCs, subnets e security groups; e o NVIDIA Nemotron 3 Nano, modelo de 30B com janela de 256K tokens, chegou ao Amazon Bedrock. Nada disso muda o jogo sozinho, mas somado ao Graviton4 e ao Spot, desenha um começo de ano em que a AWS pediu para o cliente revisar resiliência e custo antes de acelerar.
O que levar desta semana
Foi uma semana enxuta, e o valor está no padrão e não no volume. Kubernetes: a v1.35 não veio com feature de vitrine — veio com quatro alavancas finas (toleration numérica, PV nodeAffinity mutável, token CSI via secrets, allowlist no kuberc) que tornam o cluster mais governável em scheduling, storage e segurança; vale colocar na fila de avaliação, lembrando que três das quatro são alpha/beta e pedem teste em staging. Networking gerenciado: o Generic VNIC Attachment do OKE é o sinal de que o Kubernetes gerenciado está devolvendo o controle de rede a quem precisa de isolamento e performance previsível — ainda em disponibilidade limitada, mas estratégico para migrar arquiteturas complexas. Custo: Graviton4 e Spot no ECS Managed Instances dizem que a AWS quer que 2026 comece por FinOps, e a coincidência com as tolerations numéricas do Kubernetes confirma que capacidade preemptível virou ferramenta padrão. Use a calmaria de janeiro para revisar guardrails: quem entrar no volume do ano com scheduling, storage e segurança afinados vai operar barato e estável quando a demanda voltar.
Perguntas Frequentes
O que os operadores Gt e Lt em tolerations resolvem na prática?
Até a v1.34, taints e tolerations só comparavam valores exatos (Equal) ou existência (Exists), o que forçava categorias discretas de taint ou admission controllers externos para qualquer decisão baseada em métrica. O Kubernetes v1.35 adiciona os operadores Gt (maior que) e Lt (menor que) em spec.tolerations, em estágio alpha. Com isso dá para expressar regras como "só escalone aqui se a probabilidade de falha for menor que 5" ou "só treine em GPU com score acima de 800", habilitando scheduling consciente de SLA, FinOps e performance. É alpha: depende do feature gate TaintTolerationComparisonOperators e exige testes em staging.
A entrega de tokens de Service Account para CSI drivers mudou? É seguro habilitar?
Mudou e é uma correção de segurança real. Antes, tokens solicitados por CSI drivers trafegavam pelo campo volume_context, que não foi projetado para dados sensíveis — o que já causou vazamento de tokens em logs de gRPC (CVE-2023-2878 e CVE-2024-3744). A v1.35 traz, em beta, a opção de entregar o token pelo campo secrets do NodePublishVolumeRequest, onde o ecossistema de logs já sabe expurgar o conteúdo. O padrão segue false por retrocompatibilidade; ative serviceAccountTokenInSecrets: true só depois de implantar drivers com lógica de fallback que leia primeiro de secrets e depois de volume_context.
Por que o nodeAffinity mutável em PersistentVolumes importa para quem opera storage?
Desde a v1.10 o nodeAffinity de um PersistentVolume era imutável: para mudar a topologia de um volume com estado era preciso recriá-lo, com risco e downtime. A v1.35 torna esse campo mutável, em alpha, atrás do feature gate MutablePVNodeAffinity. Isso destrava cenários como migrar um disco de zonal para regional sem deletar o PV. Atenção a dois pontos: alterar o nodeAffinity no Kubernetes não altera a acessibilidade do volume no provedor — o storage subjacente precisa estar atualizado antes; e apertar a regra abre uma race condition que pode deixar Pods em ContainerCreating, então monitore os Pods logo após a mudança.
O que é o Generic VNIC Attachment do OKE e que problema ele resolve?
O Generic VNIC Attachment (GVA) é um recurso do OCI Kubernetes Engine, anunciado em disponibilidade limitada, que devolve ao time de infraestrutura o controle sobre o networking do cluster. No modelo anterior, o Flannel CNI dava uma VNIC por nó e o VCN Native CNI dava VNICs primária e secundária com configurações idênticas, sem flexibilidade. Com o GVA dá para especificar quantas e quais VNICs anexar a worker nodes e pods, configurar cada uma individualmente (IPs, IPv4/IPv6, subnet, Network Security Groups, tags) e agendar pods específicos para VNICs determinadas. Habilita isolamento de rede real entre unidades de negócio, roteamento por workload e largura de banda dedicada para cargas de alto throughput.
Vale a pena olhar as instâncias Graviton4 e o Spot no ECS Managed Instances agora?
Vale, se o objetivo é eficiência de custo. As novas instâncias EC2 M8gn e M8gb, com Graviton4, entregam até 30% mais performance de compute que a geração anterior e elevam o teto de rede para cargas network-intensive, com até 600 Gbps de banda de rede e 150 Gbps de EBS — boas candidatas para consolidar workloads e reduzir o sprawl de instâncias. Para containers, o suporte a EC2 Spot Instances no ECS Managed Instances é a novidade de maior impacto em FinOps: combina a facilidade da infraestrutura gerenciada com economias de até 90% em workloads tolerantes a falha. Spot exige arquitetura preparada para interrupção; não é para estado crítico sem fallback.
Fontes:
- Kubernetes v1.35: operadores numéricos (Gt e Lt) em tolerations para scheduling por SLA — Kubernetes Blog
- Kubernetes v1.35: entrega de tokens de Service Account para CSI drivers via campo secrets (beta) — Kubernetes Blog
- Kubernetes v1.35: nodeAffinity em PersistentVolumes agora é mutável (alpha) — Kubernetes Blog
- Kubernetes v1.35: allowlist de plugins de credencial no kuberc (beta) — Kubernetes Blog
- Apresentando o Generic VNIC Attachment para o OKE — Oracle Cloud Infrastructure Blog
- AWS Weekly Roundup: Graviton4, Amazon ECS Managed Instances e mais (5 de janeiro de 2026) — AWS News Blog
