 |
| Bellacosa Mainframe e o kubernetes autoscaling |
☕ Um Café no Bellacosa Mainframe
Kubernetes Autoscaling Muito Além do HPA
O Que Todo Programador COBOL Padawan Precisa Saber Sobre HPA, VPA, Cluster Autoscaler e Como os Grandes Bancos Escalam Milhões de Transações Sem Desperdiçar Recursos
"No Mainframe aprendemos que desempenho nunca foi apenas velocidade. Sempre foi equilíbrio entre capacidade, disponibilidade, custo e confiabilidade. Kubernetes apenas reinventou esse conceito para a era da nuvem."
Introdução
Existe uma pergunta que praticamente todo desenvolvedor faz quando começa a estudar Kubernetes:
"Se meu sistema receber mais acessos, o Kubernetes cria novos Pods automaticamente?"
A resposta é:
Depende.
E é justamente esse "depende" que confunde milhares de profissionais todos os anos.
Quando um Programador COBOL começa a estudar Kubernetes, normalmente imagina que existe apenas um mecanismo responsável por aumentar a capacidade da aplicação.
Na prática, isso está longe da realidade.
Na verdade, Kubernetes possui diversos mecanismos diferentes de escalabilidade, cada um resolvendo um problema específico.
Alguns aumentam a quantidade de Pods.
Outros aumentam CPU e memória.
Outros adicionam novos servidores inteiros ao cluster.
Cada um trabalha em uma camada diferente da infraestrutura.
É exatamente como acontece em um grande banco.
Quando o Internet Banking começa a ficar lento, ninguém simplesmente compra um novo servidor.
Antes disso existem diversas decisões:
aumentar regiões CICS?
criar novos servidores WebSphere?
ajustar WLM?
aumentar memória?
ativar Capacity on Demand?
adicionar uma nova LPAR?
No Kubernetes acontece exatamente a mesma filosofia.
Neste artigo vamos entender profundamente como funcionam:
Horizontal Pod Autoscaler (HPA)
Vertical Pod Autoscaler (VPA)
Cluster Autoscaler (CA)
Sempre fazendo paralelos com IBM Z, COBOL, CICS, Batch, WLM e arquitetura corporativa.
Antes de falar sobre Autoscaling...
Precisamos entender um conceito fundamental.
O verdadeiro objetivo não é aumentar recursos.
É utilizar exatamente os recursos necessários.
Essa diferença parece pequena.
Mas muda completamente a forma de projetar sistemas.
Imagine um supermercado.
Às 3 horas da manhã existem apenas cinco clientes.
Às 18 horas existem dois mil clientes.
Você contrataria:
200 caixas funcionando o dia inteiro?
Claro que não.
Também não deixaria apenas dois caixas funcionando às 18 horas.
A solução inteligente é adaptar a quantidade de caixas conforme o movimento.
É exatamente isso que Kubernetes faz.
O grande problema dos sistemas tradicionais
Durante décadas o modelo foi simples.
Comprar servidores suficientes para suportar o pior cenário.
Imagine uma aplicação bancária.
Segunda-feira:
CPU: 12%
Terça-feira:
CPU: 18%
Quarta-feira:
CPU: 22%
Na Black Friday:
CPU: 98%
O servidor foi comprado pensando apenas nesse último dia.
Resultado:
Durante praticamente todo o ano:
CPU parada
memória parada
discos subutilizados
energia desperdiçada
dinheiro desperdiçado
Cloud Computing mudou completamente essa lógica.
Agora infraestrutura pode crescer e diminuir automaticamente.
Elasticidade x Escalabilidade
Esses conceitos costumam ser confundidos.
Escalabilidade
É a capacidade do sistema suportar mais carga.
Exemplo:
Um servidor suporta:
500 usuários
Depois de melhorias:
5.000 usuários
Ele ficou mais escalável.
Elasticidade
É a capacidade de crescer e diminuir automaticamente.
Hoje:
2 Pods
Daqui cinco minutos:
20 Pods
Mais tarde:
4 Pods
Tudo sem intervenção humana.
Isso é elasticidade.
É justamente o coração do Kubernetes.
Os três tipos de escalabilidade
A maioria das pessoas acredita que existe apenas um tipo.
Na realidade existem três.
Escalabilidade Horizontal
Adicionar mais instâncias.
Exemplo:
Antes
2 Pods
Depois
8 Pods
Cada Pod continua igual.
Apenas existem mais deles.
Escalabilidade Vertical
Não aumenta quantidade.
Aumenta potência.
Antes
CPU 500m
Memória 512Mi
Depois
CPU 2
Memória 4Gi
Mesmo Pod.
Mais poderoso.
Escalabilidade da Infraestrutura
Agora nem estamos falando da aplicação.
Estamos falando do próprio cluster.
Antes
3 Workers
Depois
10 Workers
Agora existe espaço para muito mais Pods.
HPA — Horizontal Pod Autoscaler
Este é o autoscaler mais famoso.
Seu trabalho é extremamente simples.
Responder uma única pergunta.
Existem Pods suficientes?
Observe o que ele NÃO pergunta.
Existe CPU suficiente?
Existe memória suficiente?
Existem servidores suficientes?
Nada disso.
Ele pensa apenas em quantidade de Pods.
Como o HPA funciona?
Imagine uma API.
Ela começou o dia assim.
2 Pods
CPU média:
20%
Tudo funcionando.
Então começa uma campanha de marketing.
A CPU sobe para:
92%
O HPA verifica que sua meta era:
70%
Então ele faz um cálculo.
Simplificando:
Novos Pods =
Pods atuais ×
(CPU Atual / CPU Desejada)
Se havia:
4 Pods
CPU:
84%
Meta:
70%
Resultado:
4 × 84 ÷ 70
≈ 4,8
O Kubernetes arredonda.
Agora teremos:
5 Pods
Se a carga continuar aumentando:
6
8
12
20 Pods
Tudo automático.
Mas o HPA não olha apenas CPU
Esse é um erro muito comum.
Na realidade ele pode observar praticamente qualquer métrica.
Exemplos.
CPU
Memória
Requests por segundo
Tempo médio de resposta
Fila Kafka
RabbitMQ
Prometheus
Número de usuários
Sessões abertas
Mensagens pendentes
Quantidade de pedidos
Pix aguardando processamento
Fila de cartões
Custom Metrics
Isso significa que o HPA pode crescer baseado na necessidade real do negócio.
Imagine um banco.
Talvez CPU nem seja importante.
O importante pode ser:
Fila PIX > 2000
Nesse momento:
Criar novos Pods.
Muito mais inteligente.
Como o HPA conversa com Kubernetes?
O fluxo é relativamente simples.
Usuário
↓
Ingress
↓
Service
↓
Pods
↓
Kubelet mede CPU
↓
Metrics Server coleta
↓
API Server publica
↓
HPA consulta
↓
ReplicaSet aumenta Pods
↓
Deployment cria novas réplicas
Tudo acontece continuamente.
Sem intervenção humana.
HPA não fica escalando o tempo todo
Imagine esta situação.
CPU:
69%
71%
69%
70%
71%
69%
Sem mecanismos de estabilização.
Teríamos:
8 Pods
9 Pods
8 Pods
9 Pods
8 Pods
Isso seria um desastre.
Por isso existem diversos mecanismos internos.
Cooldown.
Stabilization Window.
Tolerance.
Scale Policies.
Esses mecanismos evitam oscilações desnecessárias.
HPA possui limitações
Ele não faz milagres.
Imagine.
Seu cluster possui apenas:
2 Workers
Cada Worker possui:
8 CPUs
Todos estão completamente ocupados.
O HPA decide criar:
30 Pods
Mas onde eles serão executados?
Resposta.
Em lugar nenhum.
Eles ficam:
Pending
É aqui que entra outro personagem.
VPA — Vertical Pod Autoscaler
Agora o problema mudou completamente.
Não queremos mais criar novos Pods.
Queremos melhorar os Pods existentes.
Imagine.
Seu Deployment foi criado assim.
requests:
cpu: 100m
memory: 128Mi
Na prática ele utiliza:
CPU
850m
Memória
950Mi
Resultado.
CPU Throttling.
OOMKilled.
Baixo desempenho.
O VPA observa isso.
Como o VPA aprende?
Ao contrário do HPA.
Ele analisa histórico.
Dias.
Semanas.
Meses.
Depois calcula recomendações.
Exemplo.
Atual.
CPU
100m
Recomendado.
900m
Atual.
256Mi
Recomendado.
1Gi
Isso reduz desperdício.
E melhora desempenho.
Os modos do VPA
Off
Apenas recomenda.
Muito usado em produção.
Você recebe um relatório.
Mas nenhuma alteração acontece.
Auto
Atualiza automaticamente.
Se necessário reinicia Pods.
É extremamente poderoso.
Initial
Aplica apenas durante a criação.
Excelente para aplicações críticas.
Por que o VPA reinicia Pods?
Muitos iniciantes estranham isso.
O motivo é simples.
CPU e memória fazem parte da especificação do Pod.
Depois que o container está em execução.
Esses parâmetros normalmente não podem ser alterados.
Então o Kubernetes cria um novo Pod.
Com os novos valores.
O que o VPA não faz?
Não cria novos Pods.
Não cria servidores.
Não aumenta Workers.
Não substitui HPA.
São ferramentas complementares.
Cluster Autoscaler
Agora chegamos à infraestrutura.
Imagine.
Seu HPA criou:
50 Pods
Mas existem apenas:
3 Workers
Todos lotados.
Resultado.
Pods Pending
O Scheduler tenta.
Não consegue.
Agora entra o Cluster Autoscaler.
O trabalho do Cluster Autoscaler
Ele pergunta.
Existe algum Pod que não consegue ser agendado?
Se existir.
Ele conversa com o provedor de nuvem.
AWS.
Azure.
Google.
OpenShift.
VMware.
E solicita novos Workers.
Depois que os novos servidores entram no cluster.
O Scheduler distribui os Pods.
Fluxo completo
Usuários aumentam.
↓
CPU aumenta.
↓
HPA cria Pods.
↓
Pods ficam Pending.
↓
Cluster Autoscaler detecta.
↓
Cloud cria Workers.
↓
Workers entram.
↓
Scheduler agenda Pods.
↓
Aplicação volta ao normal.
Tudo automático.
Como o Cluster Autoscaler decide remover servidores?
Ele também reduz custos.
Imagine.
Domingo.
Pouquíssimos acessos.
Existem:
15 Workers
Mas apenas:
3
são necessários.
O Cluster Autoscaler verifica.
Os Pods podem ser movidos?
Se sim.
Executa.
Drain.
Eviction.
Delete Node.
Resultado.
Economia de infraestrutura.
Comparando HPA, VPA e Cluster Autoscaler
Imagine um supermercado.
HPA
Contrata mais caixas.
Mais pessoas atendendo clientes.
VPA
Entrega computadores mais rápidos para cada caixa.
Cada funcionário trabalha melhor.
Cluster Autoscaler
Constrói uma nova loja.
Agora existe espaço para muito mais caixas.
São três problemas diferentes.
Um exemplo real de um grande banco
Imagine um aplicativo bancário.
Às 8h da manhã.
Começam os acessos.
Primeiro.
O HPA aumenta.
6 Pods
↓
20 Pods
Depois percebe-se que cada Pod está consumindo muito mais memória.
O VPA recomenda.
512Mi
↓
2Gi
Agora não existe mais capacidade física.
O Cluster Autoscaler adiciona.
8 Workers
↓
16 Workers
O usuário final nem percebe.
Essa é a magia da elasticidade.
Analogia com IBM Mainframe
Quem trabalha com IBM Z perceberá rapidamente várias semelhanças.
HPA
Lembra aumentar regiões CICS.
Ou criar mais servidores Liberty.
Mais instâncias.
Mesmo programa COBOL.
VPA
Lembra ajustar REGION.
Heap Java.
Parâmetros WLM.
Mais recursos para uma região existente.
Cluster Autoscaler
Lembra.
Adicionar novas LPARs.
Capacity on Demand.
Expandir Parallel Sysplex.
Mais infraestrutura.
A filosofia é praticamente idêntica.
Quando utilizar cada um?
Use HPA.
Quando existem picos de acesso.
APIs REST.
Microsserviços.
Front-end.
Aplicações stateless.
Use VPA.
Quando deseja otimizar CPU e memória.
Eliminar desperdício.
Evitar OOMKilled.
Melhorar desempenho.
Use Cluster Autoscaler.
Quando a infraestrutura precisa crescer automaticamente.
Principalmente em Cloud.
AWS.
Azure.
Google Cloud.
OpenShift.
O futuro: KEDA e Event-Driven Autoscaling
Os mecanismos que estudamos são apenas a base. Em arquiteturas modernas, surge um quarto componente importante: o KEDA (Kubernetes Event-Driven Autoscaling).
Enquanto o HPA reage principalmente a métricas como CPU e memória, o KEDA reage a eventos.
Imagine um sistema de processamento de boletos. Não importa a CPU; o importante é saber quantos boletos aguardam processamento em uma fila do IBM MQ ou do Kafka.
Se houver 10 mensagens, um Pod é suficiente.
Se houver 10.000 mensagens, o KEDA pode solicitar ao HPA dezenas de Pods para processar a fila rapidamente.
Esse modelo aproxima o Kubernetes dos conceitos de processamento orientado a filas, muito conhecidos por profissionais de Mainframe que trabalham com IBM MQ, CICS Trigger Transactions e Batch.
Conclusão
Quando começamos a estudar Kubernetes, é comum acreditar que autoscaling significa apenas "criar mais Pods". Porém, vimos que a realidade é muito mais rica. O ecossistema foi projetado para atacar diferentes gargalos de forma especializada:
HPA responde ao aumento da carga criando ou removendo Pods.
VPA ajusta CPU e memória para que cada Pod tenha os recursos ideais.
Cluster Autoscaler adiciona ou remove nós do cluster conforme a capacidade física necessária.
KEDA amplia essa inteligência ao escalar aplicações com base em eventos e filas.
Para um Programador COBOL Padawan, essa arquitetura não deve ser vista como algo completamente novo. Ela representa a evolução de princípios que sempre existiram no mundo corporativo: distribuir carga, otimizar recursos, garantir disponibilidade e controlar custos.
No IBM Z, esses objetivos eram alcançados com WLM, Parallel Sysplex, Capacity on Demand, regiões CICS, tuning de DB2 e planejamento de capacidade. No Kubernetes, os mesmos princípios são implementados de forma declarativa, automática e integrada à nuvem.
A tecnologia mudou. As ferramentas evoluíram. Mas a missão continua exatamente a mesma: entregar sistemas resilientes, escaláveis e eficientes, capazes de atender milhões de usuários sem desperdiçar recursos. É essa mentalidade de engenharia que transforma um desenvolvedor em um verdadeiro arquiteto de soluções modernas.
