TL;DR — A semana foi do provedor assumindo o trabalho braçal da operação. A Oracle colocou em preview o Karpenter gerenciado no OKE e passou a reparar hosts GPU pelo próprio Kubernetes; o Google levou blue-green gerenciado ao Cloud SQL para MySQL e os spend caps à GA. Em todos os casos, o controller é do provedor, mas a política — limites, guardrails, orçamento — continua sendo sua. Sem ela, o gerenciado só automatiza o erro.
A semana passada foi sobre a conta da telemetria. Esta foi sobre outra coisa que pesa em time enxuto: o trabalho operacional repetitivo — manter o autoscaler, consertar node doente, atualizar banco de madrugada, lembrar de desligar o sandbox antes que a fatura chegue.
Três anúncios, de dois provedores, apontaram para o mesmo desenho. O provedor opera o mecanismo; o cliente escreve a regra. Vale entender onde passa essa linha, porque é ali que mora a responsabilidade quando algo dá errado.
O que exatamente o provedor passou a operar por você?
| Anúncio | O provedor assume | Continua com você | Status |
|---|---|---|---|
| Karpenter gerenciado no OKE | Deploy, credenciais, CRDs, versão, monitoramento, upgrade e rollback do controller | NodePool, OCINodeClass, shapes permitidas, limites e o custo do que for provisionado |
Preview (via time de conta) |
| OKE GPU Host Repair | Detecção de falha de GPU/RDMA, cordon, drain, reboot ou terminate e reposição no node pool | NodeRepairConfig: quais nodes, quantos reparos em paralelo, se pausa para aprovação |
Anunciado |
| Blue-green gerenciado no Cloud SQL para MySQL | Clone, replicação contínua, switchover e troca de IP/nome/backups | Quando testar, o que validar e quando virar | Preview |
| Spend caps no Google Cloud | Bloqueio do serviço elegível ao estourar o orçamento, reset mensal, API | Valor do cap, em quais projetos aplicar, quem recebe o alerta | GA |
Karpenter gerenciado. O Karpenter Provider for OCI já estava em GA desde o início do ano, mas quem o adotava instalava e mantinha o controller. Agora o OKE roda o controller em infraestrutura própria, fora dos worker nodes do cliente. O ganho é real para quem sofre com node pool sprawl — um pool por shape para contornar falta de capacidade num availability domain. O ponto de atenção também: o OKE não cria política padrão, e um NodePool frouxo provisiona shapes caras sem pedir licença. A mesma lógica de autoscaling por sinal que defendemos no guia de KEDA e HPA do laboratório à produção vale aqui: escalar por demanda só é economia quando os limites estão escritos.
Reparo de host GPU. Em vez de o operador descobrir pelo dashboard que uma GPU degradou e orquestrar o reparo com script, o Kubernetes vira a fonte de verdade: a saúde do host aparece como node condition e num recurso NodeHealthReport, e um controller gerenciado executa cordon, drain e a ação no Compute. O detalhe que importa está nos guardrails: dryRun, pauseBeforeRepair, maximumParallelNodeRepairs e maxUnhealthyNodeThreshold. Job de treinamento longo com checkpoint caro não pode ser interrompido porque um sinal ficou amarelo.
Upgrade de banco precisa mesmo ser na madrugada de sábado?
Para quem está no Cloud SQL para MySQL, cada vez menos. O preview de blue-green gerenciado cria um clone (green) já na versão-alvo — o exemplo do anúncio é MySQL 8.0 para 8.4 —, mantém em sincronia por replicação contínua e deixa o time testar com dados reais de produção antes de virar. No switchover, a instância antiga fica read-only, a sincronização fecha e a nova assume com o mesmo IP, nome e backups. Em Enterprise Plus, o Google fala em downtime abaixo de um segundo; se o teste falhar, apaga-se o deployment sem tocar no banco que está no ar.
Para a realidade brasileira, o impacto é menos técnico do que organizacional: upgrade adiado por medo de janela é a origem de muito banco em versão sem suporte. Quando o upgrade cabe no horário comercial, ele deixa de ser projeto e vira rotina. PostgreSQL ficou para "os próximos passos", sem data.
Um teto de gastos resolve o problema da conta surpresa?
Resolve a pior parte — o sandbox esquecido ou o experimento de IA que roda o fim de semana inteiro —, desde que se entenda o que ele corta. Os spend caps chegaram à GA com três mudanças: API para aplicar o limite automaticamente em todo projeto novo, live cost reports com custo estimado quase em tempo real (em vez de esperar horas pelo pipeline de billing) e reset mensal automático, que libera os serviços bloqueados na virada do mês.
O que ele não faz: proteger produção sem efeito colateral. Ao estourar o cap, requisições pay-as-you-go e cobertas por CUD dos serviços elegíveis param; só Provisioned Throughput continua. Por isso o lugar natural do cap é o projeto de desenvolvimento e o playground de agentes, não o checkout. Para empresas que pagam a nuvem em dólar e orçam em real, um freio automático em ambiente não produtivo é dos controles de FinOps com melhor relação esforço/resultado — e cabe numa linha do provisionamento de projeto.
Gerenciado significa que o incidente não é mais seu?
Não, e o Google publicou na mesma semana o melhor argumento contra essa ilusão. Um post-mortem detalhado conta como clusters GKE na europe-west passaram semanas com pods perdendo acesso intermitente ao kube-apiserver. Não era uma falha, eram três, em camadas diferentes: reordenação de pacotes na rede, um half-close do Envoy e um bug no kernel Linux 6.1. A correção exigiu patch no kernel upstream e mudanças no Private Service Connect. Pelo relato, cerca de 800 desenvolvedores ficaram semanas sem conseguir fazer deploy em produção.
O control plane era gerenciado. O impacto, não. Quem descartou rápido o próprio operator e o External Secrets Operator — com logs mostrando que os erros começaram antes deles — encurtou o caminho até o provedor. Terceirizar o mecanismo não terceiriza a capacidade de diagnosticar: timeline de mudanças, logs com contexto e um caminho claro de escalonamento continuam sendo trabalho do time.
Outros destaques da semana
- Volcano v1.16. O scheduler de lote para IA/ML no Kubernetes ganhou
NamespaceQueue(hierarquia de filas por namespace), fairshare inspirado no Slurm, cache de jobs não agendáveis para escalar melhor e o HyperNode utilizável por outros schedulers. Interessa a quem divide cluster de GPU entre times. - US$ 250 mil por "Root-in-Cloud". O Google criou uma nova faixa no seu programa de recompensas para falhas que permitam controle total de organização ou projeto sem acesso prévio — isolamento de tenant, o risco que todo cliente de nuvem pública herda.
- AWS Continuum em GA. Gestão de vulnerabilidades de código que reproduz achados exploráveis em sandbox e abre a correção como pull request, com remediação sujeita a aprovação humana. A AWS justificou o lançamento com evidência de exploração antes da divulgação — o mesmo padrão que vimos no caso PHP2Shell. No mesmo roundup, o Amazon Polly ganhou duas vozes generativas em português brasileiro.
- KubeCon NA 2026 se aproxima. O End User TAB da CNCF publicou sua seleção de sessões para Salt Lake City (9 a 12 de novembro), com peso em infraestrutura de IA, multi-cluster, segurança de agentes e custo em escala.
Perguntas Frequentes
Karpenter gerenciado no OKE substitui os managed node pools?
Não de imediato. No preview, a Oracle opera o controller (deploy, credenciais, CRDs, upgrades, rollback), mas não cria NodePool nem OCINodeClass padrão: a política de provisionamento é do cliente. O caminho sugerido é incremental — cargas bursty ou sensíveis a custo vão para o Karpenter, workloads estáveis seguem em managed node pools. A entrada no preview é via time de conta da Oracle, sem self-service.
Deixar o provedor reiniciar ou terminar nodes GPU sozinho não é arriscado?
É, se ligado sem guardrails. O OKE GPU Host Repair expõe isso como política no NodeRepairConfig: dryRun para registrar o que faria sem agir, pauseBeforeRepair para exigir aprovação antes de qualquer ação disruptiva, limite de reparos paralelos, teto de nodes unhealthy e respeito a pod disruption budgets. Comece em dryRun num node de teste e só depois habilite a execução real.
Spend cap do Google Cloud pode derrubar produção?
Pode, se aplicado sem critério. Quando o limite é atingido, o cap interrompe requisições pay-as-you-go e cobertas por CUD dos serviços elegíveis; só o Provisioned Throughput segue rodando. Por isso a recomendação do próprio Google é começar por sandboxes, ambientes de teste e playgrounds de IA, com alertas em 50%, 80% e 100% indo para as pessoas certas.
O blue-green gerenciado do Cloud SQL já serve para PostgreSQL?
Ainda não. O preview cobre Cloud SQL for MySQL em instâncias primárias standalone, incluindo alta disponibilidade, com suporte a PostgreSQL anunciado como próximo passo. Na troca, o Cloud SQL move IP, nome e backups para a nova instância, então a aplicação não muda connection string; em Enterprise Plus, o downtime do switchover pode ficar abaixo de um segundo.