Escalado Automático en Kubernetes: Optimizando Recursos con HPA y VPA 🚀

El escalado automático es una capacidad fundamental en cualquier entorno de producción moderno basado en contenedores. En Kubernetes, esta funcionalidad nos permite adaptar dinámicamente los recursos de nuestra aplicación a la demanda real, evitando problemas de rendimiento por infrautilización o sobrecarga. Dos herramientas clave para lograr esto son el Horizontal Pod Autoscaler (HPA) y el Vertical Pod Autoscaler (VPA). Este tutorial explorará a fondo ambos mecanismos, sus diferencias, y cómo implementarlos eficazmente.

💡 ¿Por qué es Crucial el Escalado Automático en Kubernetes?

Imagina que tienes una aplicación web que experimenta picos de tráfico. Sin escalado automático, tendrías dos opciones:

1. Sobredimensionar tus recursos para manejar el pico, lo que resulta en un desperdicio significativo de recursos (y dinero) durante los períodos de baja demanda.
2. Subdimensionar tus recursos, arriesgándote a que tu aplicación se ralentice o falle cuando la demanda aumente, lo que lleva a una mala experiencia de usuario y posibles pérdidas económicas.

El escalado automático resuelve este dilema. Permite que tus aplicaciones consuman solo los recursos necesarios en cada momento, ajustándose dinámicamente a las fluctuaciones de la carga de trabajo. Esto se traduce en:

• Eficiencia de Costos: Paga solo por los recursos que realmente utilizas.
• Fiabilidad Mejorada: Tu aplicación puede manejar aumentos repentinos de tráfico sin degradación del rendimiento.
• Operaciones Simplificadas: Menos intervención manual para ajustar los recursos.
• Experiencia de Usuario Superior: Latencia reducida y mayor disponibilidad.

🛠️ Entendiendo el Horizontal Pod Autoscaler (HPA)

El Horizontal Pod Autoscaler (HPA) ajusta el número de réplicas de un Deployment, ReplicaSet, StatefulSet o ReplicationController basándose en métricas de uso de CPU, uso de memoria u otras métricas personalizadas. Cuando la demanda aumenta, HPA añade más pods; cuando disminuye, reduce el número de pods. Su objetivo es mantener una métrica deseada por pod.

¿Cómo funciona HPA? 🤔

HPA monitorea las métricas reportadas por los pods (a través del Metrics Server de Kubernetes). Luego, compara estas métricas con los umbrales definidos en su configuración. Si la métrica actual excede el umbral deseado, HPA calcula el número de réplicas necesario para volver al objetivo y actualiza el controlador (Deployment, etc.), que a su vez crea o elimina pods.

Instalando el Metrics Server

Si no lo tienes ya, instala el Metrics Server. Es un componente ligero que agrega datos de uso de recursos de los nodos y pods, y los expone a través de una API para que HPA pueda consumirlos.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Verifica que esté corriendo:

kubectl get apiservice v1beta1.metrics.k8s.io -o yaml

Deberías ver status: conditions: type: Available status: "True".

Creando una Aplicación de Prueba 🧪

Vamos a desplegar una aplicación simple para probar HPA. Crearemos un Deployment y un Service.

nginx-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hpa-demo
  labels:
    app: nginx-hpa
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-hpa
  template:
    metadata:
      labels:
        app: nginx-hpa
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
          limits:
            cpu: 200m

nginx-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-hpa-demo
spec:
  selector:
    app: nginx-hpa
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Aplica estos manifiestos:

kubectl apply -f nginx-deployment.yaml
kubectl apply -f nginx-service.yaml

Ahora deberías tener un pod de Nginx corriendo.

kubectl get pods

Configurando HPA ⚙️

Crearemos un HorizontalPodAutoscaler que apunte a nuestro Deployment de Nginx. Lo configuraremos para escalar basándose en el uso de CPU. Queremos que el uso promedio de CPU sea del 50%.

nginx-hpa.yaml:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-cpu-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-hpa-demo
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• scaleTargetRef: Apunta al Deployment que queremos escalar.
• minReplicas: Número mínimo de pods (en este caso, 1).
• maxReplicas: Número máximo de pods (hasta 10).
• metrics: Define las métricas a monitorear. Aquí, cpu con un objetivo de averageUtilization del 50%.

Aplica el HPA:

kubectl apply -f nginx-hpa.yaml

Verifica el estado del HPA:

kubectl get hpa

La salida mostrará el uso actual de CPU, el objetivo y el número de réplicas.

pres-macbookpro:~ pres$ kubectl get hpa
NAME            REFERENCE                     TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
nginx-cpu-hpa   Deployment/nginx-hpa-demo   0%/50%    1         10        1          12s

Actualmente, el uso de CPU es 0% porque no hay tráfico. El número de réplicas es 1.

Generando Carga para HPA 🔥

Para ver HPA en acción, necesitamos generar carga en nuestro pod de Nginx. Podemos hacerlo con un pod auxiliar que envíe peticiones continuas.

kubectl run -it --rm --restart=Never stress-test --image=busybox -- /bin/sh -c 'while true; do wget -q -O- nginx-hpa-demo; done'

Deja esta ventana de terminal abierta. En una nueva terminal, monitorea el HPA:

kubectl get hpa -w

Verás cómo el TARGETS aumenta y, después de un breve período, HPA incrementa el número de réplicas. Por ejemplo:

NAME            REFERENCE                     TARGETS      MINPODS   MAXPODS   REPLICAS   AGE
nginx-cpu-hpa   Deployment/nginx-hpa-demo   0%/50%       1         10        1          1m
nginx-cpu-hpa   Deployment/nginx-hpa-demo   56%/50%      1         10        1          1m
nginx-cpu-hpa   Deployment/nginx-hpa-demo   78%/50%      1         10        2          1m
nginx-cpu-hpa   Deployment/nginx-hpa-demo   62%/50%      1         10        3          1m
nginx-cpu-hpa   Deployment/nginx-hpa-demo   45%/50%      1         10        3          1m

También puedes observar los pods:

kubectl get pods -w

Verás cómo se crean nuevos pods de nginx-hpa-demo. Cuando detengas el stress-test (con Ctrl + C en la terminal de stress-test), HPA comenzará a reducir el número de réplicas hasta el minReplicas definido.

📈 Entendiendo el Vertical Pod Autoscaler (VPA)

Mientras que HPA se ocupa de escalar horizontalmente (añadir o quitar pods), el Vertical Pod Autoscaler (VPA) se encarga de escalar verticalmente, ajustando las solicitudes y límites de CPU y memoria para los contenedores dentro de un pod. Esto ayuda a garantizar que los pods tengan los recursos adecuados para funcionar eficientemente, evitando el desperdicio de recursos por sobre-provisionamiento y problemas de rendimiento por sub-provisionamiento.

¿Cómo funciona VPA? 🤔

VPA observa el uso de recursos históricos de los pods y, basándose en esta información, recomienda valores óptimos para las requests y limits de CPU y memoria. VPA puede operar en varios modos:

• Off: VPA solo proporciona recomendaciones, pero no las aplica.
• Recomendaciones (Initial): VPA establece las recomendaciones al crear el pod, pero no las actualiza durante su vida útil. (Este modo está en desuso en versiones recientes de VPA)
• Auto: VPA actualiza dinámicamente las solicitudes y límites. Esto a menudo implica recrear el pod si se requieren cambios significativos.
• External: Un controlador externo aplica las recomendaciones.

Instalando el Vertical Pod Autoscaler

VPA no viene instalado por defecto en la mayoría de los clústeres de Kubernetes. Puedes instalarlo desde el repositorio oficial. Necesitarás git y kubectl configurado.

1. Clona el repositorio de VPA:

git clone https://github.com/kubernetes/autoscaler.git

2. Navega al directorio de VPA:

cd autoscaler/vertical-pod-autoscaler

3. Despliega los componentes de VPA:

./hack/vpa-up.sh

Esto desplegará los componentes de VPA: `vpa-admission-controller`, `vpa-recommender` y `vpa-updater`.

Verifica que los pods estén corriendo:

kubectl get pods -n kube-system | grep vpa

Configurando VPA ⚙️

Utilizaremos el mismo Deployment de Nginx que creamos antes. Vamos a crear un objeto VerticalPodAutoscaler para él.

nginx-vpa.yaml:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: nginx-vpa-demo
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       nginx-hpa-demo
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        minAllowed:
          cpu: 50m
          memory: 50Mi
        maxAllowed:
          cpu: 1
          memory: 1Gi

• targetRef: Apunta al Deployment que queremos gestionar.
• updatePolicy.updateMode: Establecido en Auto, lo que significa que VPA ajustará automáticamente las requests y limits y reiniciará el pod si es necesario. Otros modos incluyen Off o Initial.
• resourcePolicy: Opcional, pero recomendado. Permite definir rangos minAllowed y maxAllowed para CPU y memoria, evitando que VPA configure valores fuera de los límites aceptables para tu aplicación.

Aplica el VPA:

kubectl apply -f nginx-vpa.yaml

Ahora, VPA comenzará a monitorear el pod de Nginx. Dale un tiempo para recolectar datos. Puedes generar carga de nuevo para ayudarlo a recopilar datos significativos.

Para ver las recomendaciones:

kubectl get vpa nginx-vpa-demo -o yaml

En la sección status.recommendations, verás las sugerencias de CPU y memoria. Si updateMode es Auto, VPA las aplicará.

status:
  recommendation:
    containerRecommendations:
    - containerName: nginx
      lowerBound:
        cpu: "25m"
        memory: "26214400"
      target:
        cpu: "100m"
        memory: "26214400"
      upperBound:
        cpu: "150m"
        memory: "26214400"
      uncappedTarget:
        cpu: "100m"
        memory: "26214400"

Aquí, target muestra las recomendaciones de VPA para CPU y memoria. Si los valores actuales en el Deployment no coinciden con target y updateMode es Auto, VPA reiniciará el pod para aplicar estos nuevos valores.

🤝 HPA y VPA: ¿Pueden Trabajar Juntos? La Gran Pregunta

Tradicionalmente, HPA y VPA han tenido un conflicto fundamental: ambos intentan controlar los recursos de un pod. HPA ajusta el número de pods basándose en el uso de recursos, mientras que VPA ajusta los requests de recursos de esos pods. Si VPA cambia los requests de CPU, por ejemplo, el porcentaje de utilización de CPU que HPA ve también cambiará, lo que podría llevar a un comportamiento impredecible.

Soluciones y Estrategias para la Coexistencia ✨

1. HPA Basado en Métricas Personalizadas/Externas: Si HPA escala basándose en métricas que no son CPU o memoria (ej. longitud de cola de mensajes, solicitudes por segundo de un Ingress), entonces VPA sí puede gestionar las requests y limits de CPU/memoria. Esta es la forma más común y segura de combinarlos.

2. VPA en Modo Off o Initial (Recomendaciones Solamente): Puedes usar VPA simplemente para obtener recomendaciones de recursos y aplicarlas manualmente a tu Deployment. HPA seguiría escalando por CPU/memoria, pero VPA solo sería un consejero.

3. VPA con controlledResources: VPA puede configurarse para controlar solo CPU o solo memoria, permitiendo que HPA use la otra métrica. Sin embargo, esto es menos común y puede ser complejo de gestionar.

4. Combinación HPA (custom metrics) + VPA (CPU/Memoria): Esta es la estrategia recomendada por muchos. Usa HPA para escalar por métricas de negocio o externas (que no son CPU/memoria del pod) y VPA para optimizar dinámicamente las solicitudes y límites de CPU/memoria de cada pod, asegurando que estén bien dimensionados.

📚 Mejores Prácticas y Consideraciones Finales

• Establece requests y limits iniciales: Aunque VPA te ayudará, tener buenos valores iniciales es crucial para la estabilidad y el rendimiento desde el principio.
• Monitorea tus métricas: Usa herramientas de monitoreo como Prometheus y Grafana para visualizar cómo se comportan tus pods y escaladores a lo largo del tiempo. Esto te ayudará a afinar los umbrales y políticas.
• Prueba en un entorno de no producción: Siempre prueba tus configuraciones de escalado automático en un entorno de staging antes de aplicarlas en producción.
• Tolerancia a interrupciones: Asegúrate de que tus aplicaciones puedan manejar reinicios de pods, especialmente si usas VPA en modo Auto.
• Considera PodDisruptionBudget: Para aplicaciones críticas, usa PodDisruptionBudget (PDB) para limitar el número de interrupciones simultáneas cuando VPA o cualquier otra acción de mantenimiento reinicie pods.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: my-app

• Cluster Autoscaler: Recuerda que HPA y VPA optimizan recursos dentro de los límites de los nodos existentes. Para escalar la infraestructura subyacente (nodos), necesitarás el Cluster Autoscaler, que añade o elimina nodos a tu clúster automáticamente.

🚀 Limpieza de Recursos

Una vez que hayas terminado de experimentar, limpia los recursos para evitar cargos innecesarios:

kubectl delete hpa nginx-cpu-hpa
kubectl delete vpa nginx-vpa-demo
kubectl delete service nginx-hpa-demo
kubeclt delete deployment nginx-hpa-demo

# Si instalaste el metrics server y/o VPA para este tutorial, también puedes eliminarlos
# Eliminar Metrics Server (puede variar según la instalación):
# kubectl delete -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Eliminar VPA (desde el directorio de VPA clonado):
# ./hack/vpa-down.sh

El escalado automático es una de las características más potentes de Kubernetes para gestionar aplicaciones en un entorno dinámico. Al comprender y aplicar tanto HPA como VPA, puedes construir sistemas altamente eficientes, resilientes y rentables. ¡Mantén tus aplicaciones en Kubernetes siempre optimizadas! 🌟