Uber apresentou o ServiceScale, controller que permite a vários orquestradores escalar as mesmas cargas de trabalho Kubernetes com segurança, eliminando mais de 1 milhão de núcleos de CPU em capacidade ociosa.
A Uber detalhou o ServiceScale, controller que separa a intenção de escala da execução no Kubernetes v1.36: staleness mitigation for controllers (kubernetes.io) e permitiu eliminar mais de 1 milhão de núcleos de CPU em capacidade ociosa reservada para failovers regionais.
O que aconteceu
A Uber detalhou o ServiceScale, um novo controller que permite a múltiplos orquestradores gerenciar com segurança a escala das mesmas cargas de trabalho no Kubernetes, separando intenção de escala da execução.
A equipe de Container Platform gerencia mais de 100 clusters em data centers e provedores como Oracle e Google, com 4 mil serviços, 3 milhões de núcleos e 1,5 milhão de pods iniciados por dia. A plataforma interna Up atua como camada de federação, e o Uber Deployment Controller (UDC) reconcilia a intenção em primitivas Kubernetes.
Leia também · há 3 semanas
Form3: como uma fintech roda o mesmo código em três nuvens e sobreviveu a apagão do Google cloud
Por que separar intenção de execução
A Uber opera data centers ativo-ativo e historicamente mantinha capacidade ociosa reservada em todos eles para absorver tráfego em failover. A meta passou a ser reutilizar a capacidade de cargas de baixa prioridade durante uma falha regional.
Como o servicescale funciona
A solução foi uma custom resource definition chamada ServiceScale e um novo Service Scale Controller (SSC). Cada orquestrador expressa seu desejo de escala, e o SSC reconcilia a intenção combinada em objetos Kubernetes.
Materializar a intenção no próprio Kubernetes facilitou inspeção e failback, pois o estado normal e o temporário de failover ficam salvos no spec da CRD, sem reconstrução a partir de logs.
Três lições de produção
Caches defasados de informers foram o primeiro problema. A resposta foi uma proteção read-your-own-write: o controller anexa sua geração como annotation e só reporta status quando o cache reflete essa geração. O Kubernetes v1.36, de abril de 2026, introduziu mitigação semelhante.
Sistemas multi-escritor causaram inconsistência de ReplicaSets quando UDC e SSC atualizavam o mesmo recurso. A equipe adicionou observabilidade em toda a frota, um reparador automático no UDC e uma correção de longo prazo no caminho de escala.
Resultados e rollout
Segundo artigo no arXiv de janeiro de 2026, a Unified Failover Architecture reduziu o provisionamento em estado normal de 2x para 1,3x e eliminou mais de 1 milhão de núcleos de CPU.
| Recurso | Papel na arquitetura |
|---|---|
| Up | Camada de federação da frota Kubernetes; donos de serviço definem builds e expectativas de escala |
| UDC (Uber Deployment Controller) | Reconcilia a intenção do Up em primitivas Kubernetes; caminho crítico do ciclo de vida |
| ServiceScale (CRD) | Recurso onde cada orquestrador expressa seu desejo de escala |
| SSC (Service Scale Controller) | Reconcilia a intenção combinada dos orquestradores em objetos Kubernetes |
Arraste para o lado para ver toda a tabela.
O rollout levou um ano, com staging, canary e testes de integração com kind, suportando Deployments nativos e CloneSets do OpenKruise, sem interrupções com impacto aos clientes.
Leia também:
Fonte: Infoq
Quem escreveu
Dagmar Cirino · Editor-chefe
Especialista em tecnologia, criador de conteúdo e fundador do portal Mercado de TI e Casa do Dev. Analiso tendências de mercado, Inteligência Artificial e carreira, entregando informações precisas, transparentes e acessí...
