Escala no Kubernetes não é um número só: o control plane pode estourar de três formas

A tese de Joe Betz, do Google, é que escala no control plane do Kubernetes não se mede só em nós. Há três eixos independentes: node-bound (frotas de treino e RL, onde cada kubelet reporta presença), churn-bound (plataformas de agentes, com CRDs de vida curta gerando escrita constante) e state-bound (clusters de plataforma com muitos tipos e objetos parados, cujo custo é memória residente multiplicada por cada apiserver). Dá para estourar um eixo com os outros dois no chão.

Os números da fonte: com 100.000 nós e heartbeat de 10 segundos, só a liveness gera cerca de 10.000 escritas por segundo, e as renovações de lease foram aproximadamente 70% do QPS de escrita nas medições. Adicionar apiservers, resposta comum e opção documentada no kOps, piora o caso state-bound, porque cada réplica carrega todo o watch cache.

O texto propõe quatro seams, pontos substituíveis sem patch no upstream. Storage contract: separar o que precisa de durabilidade Raft (Deployments) do que é efêmero (events, leases). O KEP-4743 define a fronteira e o --etcd-servers-overrides já roteia tipos, mas só para recursos nativos, então CRDs ficam de fora. Node liveness: absorver renovações numa camada na frente do control plane ou usar o refresh de lease em memória do etcd, sem commit Raft completo. Shard axis: o KEP-5866 traz filtragem por hash-range no tráfego de API, mas coordenação, resharding e sharding do controller manager ficam de fora. Cache residency: o que o apiserver mantém em memória. Um protótipo de dois shards corta o heap em cerca de metade por shard, com piso de cerca de 0,9 KB por objeto RBAC. Isso ainda não existe upstream, só branches de protótipo e um rascunho de atualização de KEP.

As recipes são configurações testadas em escala, rodando em CI, com binários upstream padrão. Ainda não há recipe publicada para clusters churn-bound ou state-bound.

Para quem opera plataforma, a leitura é: antes de escalar o control plane, descubra qual eixo está apertando. Se o gargalo é memória do apiserver ou escrita de CRDs, mais réplicas ou mais nós de etcd podem custar caro e não resolver. Como a recipe ladder só tem medição por contagem de nós, quem está em churn ou state ainda vai precisar medir por conta própria.