Planificador de recursos y auto-skaling

Resumen breve

1. Consultas/límites correctos y clases QoS.

2. Apilamiento correcto (topología, afinidad, prioridades, preempresa).

3. Patinaje automático en niveles: HPA/VPA/KEDA + Cluster/Node autoscaler + warm pools.

4. Lógica orientada a SLO (latency/queue depth) con anti-flapping y presupuestos.

Modelo básico de recursos

Requests/Limits y clases QoS

Requests = garantías para el planificador; Límites = techos para runtime.
QoS: Guaranteed (req = amb por CPU/Memory), Burstable (parcialmente), BestEffort (nada).
Servicios de producción con SLO rígido - Guaranteed/Burstable; los de fondo son Burstable/BestEffort.

CPU/Memoria/IO/Red

La CPU es elástica (tiempo compartido), la memoria es rígida (OOM-kill cuando se excede).
En IO/red, establecer límites/prioridades por separado (cgroups/TC), de lo contrario «vecinos ruidosos».

GPU/aceleradores

Consulta vectorialmente (GPU = 1, VRAM a través de perfiles), usa nodeSelector/taints y PodPriority para criticar.
Para infiernos - batch size y modelos de calefacción.

Directivas de apilamiento (Scheduling)

Prioridades, preempresas y PDB

PriorityClass para rutas críticas (pagos, inicio de sesión), la preempresión está permitida.
PodDisruptionBudget protege las réplicas mínimas cuando se evacuan/apdates.

Afinidad/Topología

node/pod affinity para la ubicación/descoloración (por ejemplo, no poner réplicas en un solo host).
topologySpreadConstraints alinean las podas por zonas/AZ.
NUMA/topología: pin-CPU/hugepages donde la baja latencia es importante.

Teints y tolerances

Divida los grupos: 'prod',' batch ',' gpu ',' system '. Las críticas aguantan menos vecinos.

Auto-Skaling: niveles y señales

1) HPA (Horizontal Pod Autoscaler)

Patineta de réplicas de hadas por métricas: CPU/Memory/Customic (Prometheus Adapter).
Buenas señales: latency p95/p99, queue length/lag, RPS per pod, consumer lag.
Anti-flapping: estabilización (estabilidadVentana), paso 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)

Afina requests/limits para el consumo real (actualiza las recomendaciones).
Modos: 'Off' (recogida), 'Auto' (reinicio), 'Inicial' (sólo cuando se inicia).
Práctica: habilitar 'Off' → recopilar estadísticas → aplicar en lanzamientos.

3) KEDA/Skaling basado en cola

Responde a señales externas: Kafka lag, SQS depth, Redis length, Prometheus.
Ideal para consumidores de eventos/colas (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

CA agrega/quita nodos cuando hay déficit/exceso.
Warm pools: nodos precalentados/imágenes preparadas (aceleran cold start).
Para los picos - step-scaling y minNodes aumentados por adelantado.

Velocidad de reacción y calentamiento

Reacción de retraso de SLO: capa frontal ≤ 1-2 min, backend/DB - por separado y por adelantado.
Calentamiento: TLS/DNS/connects, carga de modelos, calentamiento de caché y JIT.
Carga de sombras para «bombear» la ruta de acceso al evento.

Anti-flapping y estabilidad

Histéresis en métricas, suavizado (exp. medias).
Windows de estabilización en HPA, grande en 'scaleDown'.
Step Skaling en lugar de «saw»; rate-limit para modificar réplicas.
Budget Skaling: limitar el% del tráfico/réplicas agregadas en un minuto.

Observabilidad y SLO

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

• Crecimiento de pending pods, eventos sin edular, déficit de IP/subredes, image pull largo, evictions.
• Tracks: sampling tail-based en las colas p99 → ver cuellos de botella al skale.

FinOps: costo de elasticidad

Métricas: $/1000 RPS, $/ms p95, $/hora de reserva.
Mix: on-demand + reserved + spot (para no criticar).
El umbral del auto-skale está relacionado con el costo del error: a veces es beneficioso mantener un warm-stock.

Especificidad para iGaming/fintech

Picos de partidos/torneos: elevar de antemano 'minReplicas' y minNodes, habilitar warm pools y calentar cachés/modelos.
Consumidores de pago: KEDA por lag + idempotencia, límites de proveedores (PSP) como desencadenantes externos de degradación.
Antibot: pool separado, escala rápida de reglas, rutas «grises».
Regulación: PDB en servicios de cumplimiento, las prioridades son mayores que las del batch.

Hojas de cheques

Diseño

• Las solicitudes/límites se establecen de acuerdo con los datos de perfil; QoS seleccionado.
• PriorityClass, PDB, taints/tolerations y topologySpread - configurados.
• HPA sobre métricas SLO, no sólo CPU.
• VPA en 'Off' para recoger recomendaciones (migración a 'Auto' planificada).
• KEDA/colas para cargas de eventos.
• CA + warm pools, las imágenes se almacenan en caché (image pre-pull).

Explotación

• Se especifican Windows y cooldowns de estabilización (se excluye el flapping).
• Alertas en pending/unschedulable, lag, p95, error-rate.
• Runbooks: «no nod», «image no tira», «OOM/evist», «tormenta de retraídas».
• Capacity-review mensual: el hecho de skale vs plan/costo.

Errores típicos

HPA solo por CPU → regresión lat bajo IO/límites de DB.
La falta de PDB y de prioridades → las críticas son las primeras en preemprender.
Mezclando crítica y batch en un mismo grupo sin taints → «vecinos ruidosos».
Cero calentamiento → inicios fríos en el pico.
Agresivo 'scaleDown' → sierra y contenedores thrash.
KEDA sin idempotencia → mensajes duplicados durante una tormenta.

minipleybuki

1) Antes del evento máximo (T-30 min)

1. Aumentar 'minReplicas '/minNodes, activar warm pools.
2. Calentar CDN/DNS/TLS/connects, cargar modelos.
3. Habilitar rutas/límites «grises» para los bots.
4. Comprobar dashboards: pending/lag/p95.

2) Deficiencia de nodo (unschedulable)

1. Comprobar CA, cuotas de nube, subred/IP.
2. Reducir temporalmente los límites de batch, habilitar la preempresión para prioridades bajas.
3. Levantar temporalmente un tipo de instancia más grande o un segundo grupo.

3) El crecimiento del lag en la cola

1. KEDA: escala hasta el desencadenante; 2) elevar los límites del consumer;

2. incluir los productores de idempotency-keys y backpressure.

4) Sierra de réplicas

1. Aumentar la estabilización/cooldown; 2) cambiar a step skaling;

2. suavizar la métrica con una media exponencial.

Opciones de configuración

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

El planificador eficiente y el auto-skaling son solicitudes/límites correctos + apilamiento inteligente + skaling multinivel (HPA/VPA/KEDA/CA) + calentamiento y anti-flapping enlazados a SLO y costo de milisegundos. Fije las políticas en IaC, observe las métricas «correctas» (latency/lag), mantenga el warm stock bajo los picos - y la plataforma será elástica, predecible y económica.