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
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.
Estender o UDC com lógica de failover foi descartado: o controller está no caminho crítico do ciclo de vida dos serviços, e uma regressão no failover poderia afetar implantações normais em toda a frota.
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
