Planeador de recursos e skeiling automático

Resumo breve

1. Solicitações/limites corretos e classes de QoS.

2. Ajuste correto (topologia, afinidade, prioridades, pré-emoção).

3. Skailing automático de vários níveis: HPA/VPA/KEDA + Cluster/Node autoscaler + warm pools.

4. Lógica orientada SLO (latency/queue depth) com anti-flapping e orçamentos.

Modelo básico de recursos

Requests/Limits e classes de QoS

Requests = garantias para o planejador; Limits = tetos para runtime.
QoS: Guaranteed (req = lim por CPU/Memory), Burstable (parcial), BestEffort (nada).
Serviços de produção com SLO rígido - Guaranteed/Burstable; de fundo - Burstable/BestEffort.

CPU/Memória/IO/Rede

CPU - elástico (time-sharing), memória dura (OU-kill).
Em IO/rede coloque limites/prioridades separadamente (cgroups/TC), senão «vizinhos barulhentos».

GPU/Aceleradores

Peça vetoriamente (GPU = 1, VRAM através de perfis), use nodeSelector/taints e PodPriority para criticar.
Para a inferência - batch size e aquecimento de modelos.

Políticas de empilhamento (Scheduling)

Prioridades, pré e PDB

PriorityClass para caminhos críticos (pagamentos, login), a pré-emissão é permitida.
O sistema protege as réplicas mínimas de evacuação/update.

Afiniti/Topologia

node/pod affinity para colocação/descolocalização (por exemplo, não colocar réplicas por hóspede).
topologySpreadConstraints alinham as áreas/AZ.
NUMA/topologia: pin-CPU/hugepages onde a baixa latência é importante.

Teintas e Tolerans

Reconheça «prod», «batch», «gpu», «system». As críticas são menores que os vizinhos.

Skeiling automático: níveis e sinais

1) HPA (Horizontal Pod Autoscaler)

Esboça as réplicas de parede em métricas: CPU/Memory/Custom (Prometheus Adapter).
Bons sinais: latency p95/p99, queue length/lag, RPS per pod, consumer lag.
Anti-flapping: estabilização (stabilizationWindow), passo mínimo, cooldown.

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: api-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
minReplicas: 6 maxReplicas: 120 behavior:
scaleUp:
stabilizationWindowSeconds: 60 policies: [{ type: Percent, value: 100, periodSeconds: 60 }]
scaleDown:
stabilizationWindowSeconds: 300 policies: [{ type: Percent, value: 20, periodSeconds: 60 }]
metrics:
- type: Pods pods:
metric:
name: http_server_request_duration_seconds_p95 target:
type: AverageValue averageValue: "0.25" # 250ms

2) VPA (Vertical Pod Autoscaler)

Sintoniza requests/limits para consumo real (atualiza recomendações).
Modos: 'Off' (coletar), 'Auto' (reiniciar), 'Inicial' (somente no início).
Prática: incluir 'Off' → coletar estatísticas → aplicar nos lançamentos.

3) KEDA/fila baseada em skeiling

Responde a sinais externos como Kafka lag, SQS depth, Redis length, Prometheus.
Perfeito para Consumadores de Eventos/Filas (EDA).

yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: { name: consumer-scale }
spec:
scaleTargetRef: { name: txn-consumer }
minReplicaCount: 2 maxReplicaCount: 200 cooldownPeriod: 120 pollingInterval: 5 triggers:
- type: kafka metadata:
bootstrapServers: broker:9092 consumerGroup: tx-cg topic: payments lagThreshold: "10000"

4) Cluster/Node Autoscaler (CA) + Warm Pools

O CA adiciona/remove as nádegas com escassez/excesso.
Warm pools: noodles pré-aquecidos/imagens preparadas (acelere a cold start).
Para picos, step-escaling e minNodes aumentada com antecedência.

Velocidade de resposta e aquecimento

Atraso SLO: camada frontal ≤ 1-2 min, backends/BD, separadamente e com antecedência.
Aquecimento: TLS/DNS/conectórios, download de modelos, armazenamento de cachê e JIT.
Carga shadow para «bombear» o caminho de cold antes do evento.

Anti-flapping e estabilidade

Histerese nas métricas, suavização ( . médio).
O windows Estilization em HPA é grande em 'scaleDown'.
Skeiling step em vez de «beber»; rate-limit para alterar réplicas.
Budget skeiling: limitar% do tráfego/réplica adicionado em um minuto.

Observabilidade e SLO

• p95/99 latency, error rate, throughput, queue depth/lag, CPU/Memory saturation, pod pending time, node pressure.

• Crescimento pending pods, eventos unschedulable, escassez de IP/subsetores, image pull longo, evictions.
• Trailers: tail-based sampling nas caudas p99 → vislumbrando pontos estreitos no skale.

FinOps: custo de elasticidade

Métricas: $/1000 RPS, $/ms p95, $/hora de reserva.
Mix: on-demand + reserved + spot (para não-criticar).
O limite do skale automático está associado ao custo do erro - às vezes é vantajoso manter o estoque warm.

Especificidades para iGaming/Fintech

Picos de jogos/torneios: levantar com antecedência 'minReplicas' e 'minNodes', incluir warm pools e aquecimento de dinheiro/modelo.
Consoantes de pagamento: KEDA por lag + idempotidade, limites de provedores (PSP) como desencadeadores externos de degradação.
Antibot: um pool separado, uma escala rápida de regras, rotas cinzentas.
Regulação: PDB em serviços de compliance, prioridades superiores às do batch.

Folhas de cheque

Projeto

• Os requerimentos/limits foram definidos de acordo com o perfil; QoS selecionada.
• PriorityClass, PDB, taants/tolerações e topologySpread - configurados.
• HPA por métricas SLO, não apenas CPU.
• VPA em 'Off' para coletar recomendações (migração para 'Auto' programado).
• KEDA/filas para cargas de eventos.
• CA + warm pools, as imagens são armazenadas (imagem pré-pull).

Exploração

• Stabilization windows e cooldowns foram definidos (flapping excluído).
• Alertas em pending/unschedulable, lag, p95, erro-rate.
• Runbooks: «sem nó», «imagem não se estende», «OOM/evict», «tempestade de retrações».
• Capacity-review mensalmente: o fato de skate vs plano/custo.

Erros típicos

HPA apenas por CPU → lat-regress para IO/limite de BD.
A falta de PDB e de prioridades → as críticas são primeiro.
A mistura de crítica e batch em uma bala sem taints → «vizinhos ruidosos».
Aquecimento zero → lançamentos frios no auge.
Agressivo 'scaleDown' → bebe e thrash contêineres.
O KEDA sem idempotidade → mensagens duplicadas durante a tempestade.

Mini playbooks

1) Antes do evento de pico (T-30 min)

1. Aumentar 'minReplicas '/ minNodes, ativar warm pools.
2. Aqueça CDN/DNS/TLS/conectórios, carregue os modelos.
3. Incluir rotas/limites «cinzentos» para bots.
4. Verificar dashboards: pending/lag/p95.

2) Escassez de nodes (unschedulable)

1. Testar CA, quotas de nuvem, subnet/IP.
2. Reduzir temporariamente os limites do batch, ativar a pré-emissão para as prioridades mais baixas.
3. Elevar temporariamente o tipo de instância ou segundo pool.

3) Crescimento da lag na fila

1. KEDA: scale up por desencadeador; 2) elevar os limites do consoante;

2. incluir idempotency-keys e backpressure dos produtores.

4) Pilha de réplicas

1. Aumentar stabilization/cooldown; 2) ir para o skeiling step;

2. suavizar a métrica com a média exponencial.

Esparguetes de config

yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: { name: api-vpa }
spec:
targetRef: { apiVersion: "apps/v1", kind: Deployment, name: api }
updatePolicy: { updateMode: "Off" } # собираем рекомендации

--balance-similar-node-groups
--expander=least-waste
--max-empty-bulk-delete=10
--scale-down-utilization-threshold=0.5
--scale-down-delay-after-add=10m

yaml topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

Resultado

Planeador e skailing automático eficientes são solicitações/limitações corretas + calçamento inteligente + skailing em vários níveis (HPA/VPA/KEDA/CA) + aquecimento e anti-flapping atrelados ao SLO e valor de milissegundos. Fixe as políticas em IaC, observe as métricas «corretas» (latency/lag), mantenha a reserva warm sob picos - e a plataforma será elástica, previsível e econômica.