Esta semana em cloud (02–08/fev): o ano começa pelo node, não pelo modelo

TL;DR: Semana de pouca atividade, mas com tema único: arrumar a base antes de escalar IA. O Kubernetes ganhou o Node Readiness Controller (v0.1.1) para evitar pods agendados em node sem driver pronto, e o Oracle Linux 7 entrou em Extended Support — o cgroup v2 do Kubernetes 1.35 vai barrar o kubelet sobre OL7. Em resiliência, AWS liberou o IAM Identity Center multi-Region e a OCI lançou o BYOCA para PKI híbrida.

Foi uma das semanas mais quietas do calendário de cloud — começo de ano, poucos anúncios, nenhum keynote para puxar manchete. Mas justamente por isso o que apareceu vale ser lido com atenção: sem o ruído de lançamento de IA, o que sobrou foi a engenharia de base, aquela camada que ninguém anuncia em palco mas que decide se o resto fica de pé.

O fio condutor da semana é esse: antes de escalar modelo, os provedores estão arrumando o chão. Três frentes resumem o recado. No Kubernetes, o novo Node Readiness Controller ataca um bug operacional clássico — pod agendado num node que ainda não terminou de subir — enquanto o Oracle Linux 7 entra em Extended Support e acende o alerta de migração antes do Kubernetes 1.35. Em resiliência e confiança, a AWS liberou a replicação multi-Region do IAM Identity Center e a Oracle lançou o BYOCA para estender PKI on-premises à nuvem. E na camada de substrato, novas instâncias EC2 com NVMe massivo e o detalhamento de storage e segurança de GPU na OCI mostram que a fatura da IA é, no fim, compute, disco e cadeia de confiança bem operados.

A leitura para quem opera infra no Brasil é confortável e exigente ao mesmo tempo: nada aqui é hype, tudo é dever de casa. E dever de casa tem prazo — o do OL7 já está correndo.

Por que o Kubernetes está gastando energia no momento mais chato do node?

O ciclo de vida do node sempre foi o ponto cego do Kubernetes. O status Ready que o scheduler enxerga é uma condição binária que olha basicamente o kubelet — mas, num node moderno, estar pronto significa muito mais: agente de rede no ar, driver de storage carregado, firmware de GPU inicializado, checagens customizadas de saúde aprovadas. O resultado dessa lacuna é um erro que todo time de plataforma já viu: pod agendado em instância recém-provisionada que ainda não terminou o bootstrap, falhando logo na largada.

É exatamente esse vão que o Node Readiness Controller, anunciado nesta semana pelo projeto Kubernetes, se propõe a fechar. A ideia é um sistema declarativo para gerenciar taints de node durante o bootstrap, estendendo a noção de prontidão para além das condições padrão. O coração é a API NodeReadinessRule (NRR): o operador declara quais condições precisam estar True — por exemplo, cniplugin.example.net/NetworkReady — e o controller só remove a taint que bloqueia o agendamento quando elas forem satisfeitas. Há dois modos: bootstrap-only, que solta o node assim que as condições iniciais são atingidas (ideal para pre-pulling de imagem pesada ou provisionamento de hardware), e continuous enforcement, que volta a aplicar a taint se uma dependência crítica cair durante a vida do node.

Dois detalhes de design merecem nota de quem opera em escala. Primeiro, o controller é desacoplado: ele reage a Node Conditions, não roda os health checks por conta própria — o que permite reaproveitar o Node Problem Detector já consolidado ou o leve Readiness Condition Reporter do próprio projeto. Segundo, há um modo dry run que loga as ações pretendidas e mostra quais nodes seriam afetados sem aplicar nenhuma taint de fato — um respiro de segurança antes de mexer numa frota de produção.

O contrapeso honesto: o projeto está em v0.1.1, fase claríssimamente inicial. Não é para colocar no caminho crítico de cluster de produção amanhã. Mas o sinal importa, e ele conversa diretamente com a era da IA — porque é em node de GPU, com driver especializado que precisa estar de pé antes de qualquer carga de inferência, que o agendamento prematuro mais dói. Vale acompanhar e testar em staging.

Quer estruturar o bootstrap dos seus nodes de GPU ou blindar o provisionamento de cluster contra agendamento prematuro? Fale com os especialistas em Kubernetes da Nuvem Online.

Oracle Linux 7 no relógio: o cgroup v2 que vai barrar seu upgrade para o Kubernetes 1.35

Se a seção anterior é sobre evitar dor futura, esta é sobre uma dor com data marcada. O Oracle Linux 7 (x86_64) entrou oficialmente em Extended Support, e quem roda containers sobre ele no OKE precisa olhar o calendário agora. A linha do tempo é direta: as imagens oficiais de OL7 deixaram de ser atualizadas em dezembro de 2024; o Extended Support começou em janeiro de 2025, com término previsto para junho de 2028. A partir do ES, correções de segurança ainda chegam — mas só via RPMs de suporte estendido, o que muda a dinâmica: em vez de simplesmente puxar uma imagem nova, o time passa a ter de garantir que esses RPMs sejam aplicados no build ou no boot do node. As imagens estão, na prática, "congeladas".

O detalhe que transforma isso de dívida técnica gerenciável em pré-requisito de migração é o cgroup v2. O Kubernetes 1.35, lançado em dezembro de 2025, padronizou o cgroup v2 — e o OL7 não o suporta nativamente. A consequência é severa e não-negociável: o kubelet não inicializa em sistema sem suporte a cgroup v2. Traduzindo para a operação do OKE: a partir do 1.35, o engine exigirá imagens Oracle Linux 8 ou superiores, e as Platform Images padrão (tanto OL7 quanto OL8) deixam de ser suportadas. O OL7 simplesmente não estará nas versões 1.35 e posteriores.

Como não existe upgrade de OS in-place para node, o caminho recomendado é Blue/Green em nível de pool: provisione um node pool novo e pequeno com OL8, migre serviços menos críticos para validar containerd, systemd, flags de kubelet e compatibilidade de CNI/CSI, e só então escale o pool OL8 fazendo cordon e drain nos nodes OL7. O OKE, vale notar, só libera o upgrade para 1.35 quando todos os node pools estiverem em conformidade — uma salvaguarda que evita o cluster ficar pela metade. Para quem precisa segurar nas versões 1.33 ou 1.34 mais um tempo, a recomendação é fixar as imagens OL7 de dezembro de 2024, habilitar os repositórios de ES para que os scanners enxerguem as correções e fazer deploy via digest para garantir paridade entre o que foi escaneado e o que roda. A mensagem prática para o Brasil é simples: se o 1.35 está no seu roadmap de 2026, o piloto com OL8 começa agora, não no mês do upgrade.

Identidade e confiança saem da caixa de uma região: o que muda com IAM Identity Center multi-Region e o BYOCA

A terceira frente da semana junta dois anúncios de provedores diferentes sob a mesma lógica: estender o controle de quem entra e em quem se confia para além de uma única fronteira — seja uma região de nuvem, seja o datacenter on-premises. São peças de resiliência e governança, não de produto novo brilhante, e é por isso que importam para quem opera produção.

Do lado da AWS, a novidade é a replicação multi-Region do IAM Identity Center, agora em disponibilidade geral. O recurso replica identidades de força de trabalho, permission sets e metadados da região primária para regiões adicionais, conectado a um IdP externo como Microsoft Entra ID ou Okta. O ganho concreto é um endpoint de portal de acesso ativo na região secundária: num cenário de instabilidade da primária — o clássico fantasma do us-east-1 — a força de trabalho continua entrando nas contas AWS pelo portal da secundária, com as permissões já provisionadas. Está disponível em 17 regiões ativadas por padrão, sem custo adicional além das taxas de AWS KMS. Mas o asterisco é importante e a Nuvem Online não vai escondê-lo: a gestão permanece centralizada na região primária, a console da secundária opera majoritariamente em read-only (gestão de aplicações e revogação de sessão), o recurso exige instância organizacional com IdP externo, e — o ponto mais subestimado — convém manter acessos break-glass, porque se o próprio IdP cair, a redundância de região não te salva.

Do lado da Oracle, o lançamento é o Bring Your Own Certificate Authority (BYOCA) para o OCI Certificates. O problema que ele resolve é antigo em empresa madura: a PKI on-premises tem anos de cadeias de confiança enraizadas, e reconstruir essa hierarquia do zero na nuvem é caro, arriscado e, em setor regulado, muitas vezes proibido por política — o root of trust tem de ficar em casa. Com o BYOCA, você importa a root CA externa para o OCI fornecendo apenas o certificado em PEM, sem nunca carregar a chave privada; depois cria subordinate CAs gerenciadas pelo OCI a partir de CSRs assinados pela raiz externa, com as chaves protegidas por HSM no OCI KMS. O resultado é o equilíbrio que o mercado regulado brasileiro persegue: soberania sobre a raiz da confiança no on-premises, agilidade da nuvem para a emissão diária de certificados. Dois movimentos, dois provedores, a mesma maturidade — a de tratar identidade e confiança como infraestrutura crítica que precisa de plano de continuidade, não como configuração feita uma vez e esquecida.

O que levar desta semana

Foi uma semana enxuta, e tudo bem — nem todo começo de ano vem com fogos. O que ela entregou foi disciplina de base, e é nela que mora a diferença entre escalar IA e quebrar tentando. Ciclo de vida de node: o Node Readiness Controller (ainda v0.1.1, então teste em staging) ataca o agendamento prematuro que mais machuca justamente em node de GPU — vale acompanhar. Migração com prazo: o Oracle Linux 7 em Extended Support não é aviso distante; o cgroup v2 do Kubernetes 1.35 impede o kubelet de subir sobre OL7, então o piloto OL8 em Blue/Green começa em 2026, não na véspera do upgrade. Resiliência de identidade e confiança: o IAM Identity Center multi-Region da AWS e o BYOCA da OCI estendem failover e PKI para fora de uma fronteira só — mas leia as letras miúdas (console secundária read-only, mantenha break-glass; root CA fica on-prem, chave privada nunca sobe). No substrato, instâncias EC2 com NVMe efêmero de até 22.8 TB e o cuidado com storage e segurança de GPU na OCI reforçam o mesmo princípio: a conta da inteligência se paga em compute, disco e governança bem operados. Quem usar uma semana quieta para fazer o dever de casa chega no próximo ciclo de anúncios pronto para consumir, em vez de correndo atrás.

Perguntas Frequentes

O que o Node Readiness Controller resolve que o status 'Ready' do node não cobre?
O status Ready do Kubernetes é binário e olha basicamente o kubelet, mas um node moderno só está realmente operacional quando agente de rede, driver de storage, firmware de GPU e checagens customizadas estão de pé. O Node Readiness Controller, anunciado nesta semana em versão inicial (v0.1.1), gerencia taints de forma declarativa pela API NodeReadinessRule: o node fica não-agendável até que as condições definidas pela plataforma estejam True. Isso evita o erro clássico de pods caírem em node recém-provisionado cujo CNI ou driver de GPU ainda não subiu.

Por que o Oracle Linux 7 entrar em Extended Support é urgente para quem usa OKE?
Porque trava o caminho para o Kubernetes 1.35. O OL7 x86_64 entrou em Extended Support em janeiro de 2025 (término previsto para junho de 2028) e as imagens oficiais deixaram de ser atualizadas em dezembro de 2024 — patches só via RPMs de ES. O ponto crítico é o cgroup v2, padronizado no Kubernetes 1.35 (lançado em dezembro de 2025): o OL7 não o suporta nativamente e o kubelet não inicializa sem ele. A partir do 1.35 o OKE exigirá Oracle Linux 8 ou superior. Como não há upgrade de OS in-place, o caminho é Blue/Green em nível de node pool.

O AWS IAM Identity Center multi-Region substitui meu plano de DR de identidade?
Ajuda, mas com ressalvas. A replicação multi-Region (GA, em 17 regiões habilitadas por padrão, sem custo adicional além do AWS KMS) replica identidades, permission sets e metadados da região primária para regiões adicionais, dando um endpoint de portal de acesso ativo na secundária caso a primária caia. Mas a gestão continua centralizada na primária e a console da secundária opera majoritariamente em read-only. O recurso exige instância organizacional ligada a um IdP externo (Entra ID ou Okta) — e o relatório recomenda manter acessos break-glass para o caso de o próprio IdP cair.

Para que serve o BYOCA da OCI e quando ele faz diferença?
O Bring Your Own Certificate Authority (BYOCA) do OCI Certificates permite importar sua root CA externa para a nuvem fornecendo só o certificado em PEM, sem nunca carregar a chave privada. A partir daí você cria subordinate CAs gerenciadas pelo OCI via CSR assinado pela raiz externa, com as chaves protegidas por HSM no OCI KMS. Faz diferença em setores regulados onde a política exige que o root of trust permaneça on-premises: você mantém a soberania sobre a raiz e delega à nuvem só a emissão diária de certificados.

Vale migrar para as instâncias EC2 C8id/M8id/R8id agora?
Depende do workload e da região. As C8id, M8id e R8id (oitava geração, Intel Xeon 6 a 3.9 GHz turbo sustentado) trazem armazenamento local NVMe de até 22.8 TB e escalam até 96xlarge (384 vCPUs, 3 TiB de memória), com ganho de até 43% em compute e até 46% em bancos de I/O intensivo frente à sexta geração. O detalhe operacional: o NVMe local é efêmero, com tempo de vida da instância e criptografia XTS-AES-256 cujas chaves são destruídas no stop — replicação e backup são obrigatórios. Na largada estão só em US East/West (e R8id em Frankfurt), então confira disponibilidade antes de planejar.

Fontes: