Autoscaling

Horizontal Pod Autoscaler (HPA)

El escalado horizontal consiste en añadir o remover réplicas de Pods dinámicamente según la demanda (hacerse "más ancho"), a diferencia del escalado vertical (VPA), que aumenta los recursos (CPU/Memoria) de los Pods existentes (hacerse "más alto").

El Flujo de Trabajo del HPA (¿Cómo funciona?)

El HPA funciona como un bucle cerrado continuo (control loop) gestionado por el kube-controller-manager. Por defecto, se ejecuta cada 15 segundos (--horizontal-pod-autoscaler-sync-period) y sigue estos pasos:

Recolección de Métricas: El HPA consulta al API Server las métricas de consumo de los Pods seleccionados. El API Server obtiene estos datos directamente del Metrics Server.
Cálculo del Algoritmo: Compara el uso actual frente al objetivo configurado.
Escalado: Si el cálculo lo requiere, el HPA modifica el campo replicas del recurso objetivo (Deployment, ReplicaSet o StatefulSet).

Requisitos Obligatorios de Infraestructura

Para que el HPA funcione correctamente en un clúster, deben cumplirse estrictamente dos condiciones:

Metrics Server Instalado: Sin él, el HPA estará "ciego" y el comando kubectl get hpa mostrará la columna TARGETS en estado <unknown>.
Resources Requests Definidos: El Pod DEBE tener configurados los requests de CPU y/o Memoria dentro de su definición en el Deployment. El HPA calcula los porcentajes basándose en este valor de reserva inicial. Si no hay requests, el HPA no sabrá respecto a qué calcular el porcentaje y fallará.

Comandos de Supervivencia

En el examen (especialmente CKAD), el tiempo es oro. Evita crear el YAML desde cero y utiliza la vía imperativa:

Crear un HPA de forma imperativa (Ejemplo CPU)

Escala un deployment llamado mi-app entre 2 y 10 réplicas cuando el promedio de consumo de CPU de los Pods supere el 50% de su request:

kubectl autoscale deployment mi-app --min=2 --max=10 --cpu-percent=50

Inspeccionar y Monitorear el HPA

El comando clave para verificar si está escalando y ver el consumo real en tiempo real:

kubectl get hpa
# Monitorear activamente los cambios de réplicas y consumo
kubectl get hpa mi-app -w

Ver los Eventos del Autoscaler (Troubleshooting)

Si el HPA no está escalando como debería, investiga las razones al final de la salida de este comando:

kubectl describe hpa mi-app

Definición Declarativa (Formato YAML)

Si el examen o tu entorno de GitOps te pide un archivo de configuración estructurado para la versión de API estable (autoscaling/v2), aquí tienes la plantilla optimizada:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mi-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mi-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 60 # Reduce el tiempo de espera a solo 1 minuto

Comportamiento Avanzado: Estabilización y Políticas (Cooldown)

Un gran problema en producción es el Flapping (o comportamiento de "serrucho"), donde un pico repentino de tráfico hace que el clúster escale hacia arriba, y un segundo después el tráfico baja y el clúster escala hacia abajo, repitiendo este ciclo destructivo y desestabilizando los pods.

Para mitigar esto, Kubernetes incluye mecanismos de Políticas de Estabilización (Cooldown):

Scale-Up (Escalado hacia arriba): Por defecto, es inmediato para garantizar que la aplicación responda rápido ante la carga de usuarios.
Scale-Down (Escalado hacia abajo): Por defecto, tiene una ventana de estabilización de 5 minutos (stabilizationWindowSeconds). Esto significa que el HPA recordará el pico de carga más alto de los últimos 5 minutos y no removerá ningún Pod hasta asegurarse de que la carga realmente se ha estabilizado a la baja.

Tips de Velocidad y Troubleshooting

¿TARGETS en <unknown>?: Si despliegas un HPA y tras un par de minutos sigue diciendo <unknown>, ejecuta kubectl top pods. Si te da un error, el problema es que el Metrics Server está caído o no está instalado en el laboratorio. Si kubectl top pods responde bien, entonces olvidaste poner el bloque resources.requests en el YAML del Deployment.
Cuidado con los campos duplicados: Si configuras un HPA para un Deployment, elimina o no uses manualmente el campo replicas: X en tus archivos de despliegue de CI/CD (o archivos base de Kustomize). Si dejas el campo estático y aplicas el YAML de nuevo, el deployment forzará las réplicas viejas temporalmente, generando un conflicto con las decisiones del HPA.
Uso de Memoria como métrica: Aunque se puede usar la memoria (name: memory), ten cuidado en producción. Muchas aplicaciones (como las basadas en Java o Node.js) no liberan la memoria inmediatamente después de usarla (Garbage Collection tardío). Esto puede provocar que el HPA mantenga el clúster escalado al máximo eternamente aunque ya no haya tráfico real. ¡La CPU siempre suele ser el indicador más confiable para el tráfico web!