El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
HOME Mis cursos Finalizados
◄ Anterior
◄

Escalado y Balanceo de Carga

Siguiente ►
►

En este tema estudiaremos cómo hacer crecer una aplicación contenedorizada para atender más tráfico y cómo repartir ese tráfico de forma equilibrada entre sus instancias. El escalado y el balanceo de carga son dos caras de la misma moneda: de poco sirve tener muchas réplicas si el tráfico no se distribuye bien entre ellas. Veremos las estrategias de escalado, cómo se aplican en Docker Swarm y en Kubernetes, los mecanismos de balanceo internos y externos, una introducción al autoescalado y las consideraciones de estado que condicionan todo lo anterior.

Objetivos de Aprendizaje

  • Distinguir entre escalado horizontal y vertical y saber cuándo aplicar cada uno.
  • Gestionar réplicas en Docker Swarm y en Kubernetes.
  • Comprender el balanceo de carga interno y el realizado mediante reverse proxy o ingress.
  • Conocer los fundamentos del autoescalado horizontal (HPA) en Kubernetes.
  • Entender por qué las aplicaciones stateless escalan mejor que las stateful.

Escalado Horizontal vs Escalado Vertical

Existen dos formas básicas de aumentar la capacidad de una aplicación:

Tipo En qué consiste Ventajas Inconvenientes
Horizontal (scale out) Añadir más réplicas/instancias Alta disponibilidad, sin límite práctico Requiere balanceo y, a menudo, ser stateless
Vertical (scale up) Dar más recursos (CPU/RAM) a cada instancia Sencillo, sin cambios de arquitectura Límite del hardware; un único punto de fallo

En el mundo de los contenedores, el escalado horizontal es la estrategia predominante: en lugar de hacer un contenedor más potente, se ejecutan más copias del mismo contenedor y se reparte la carga entre ellas. Es la base de la resiliencia y la elasticidad modernas.

Réplicas en Docker Swarm

En Swarm, escalar es ajustar el número de réplicas de un servicio:

docker service scale miapp_web=5

Explicación:

  • docker service scale: cambia el número de réplicas de un servicio existente.
  • miapp_web=5: lleva el servicio miapp_web a 5 réplicas; Swarm las distribuye automáticamente entre los nodos disponibles.

También puedes definir las réplicas en el fichero Compose dentro del bloque deploy:

services:
  web:
    image: nginx:latest
    deploy:
      replicas: 5

Swarm incorpora un balanceador interno (la routing mesh) que reparte automáticamente las peticiones entrantes entre todas las réplicas del servicio, sin configuración adicional.

Réplicas en Kubernetes

En Kubernetes, el número de réplicas se controla en el Deployment. De forma imperativa:

kubectl scale deployment miapp-deployment --replicas=5

O de forma declarativa, ajustando el campo replicas del manifiesto y aplicándolo:

spec:
  replicas: 5
kubectl apply -f deployment.yaml

Kubernetes creará o eliminará Pods hasta alcanzar el número deseado y los repartirá entre los nodos del clúster según la disponibilidad de recursos.

Balanceo de Carga Interno

El balanceo interno reparte el tráfico entre las réplicas dentro del clúster:

  • En Swarm: la routing mesh enruta cualquier petición que llegue a un puerto publicado hacia alguna réplica sana del servicio, esté en el nodo que esté.
  • En Kubernetes: el objeto Service actúa como balanceador interno. Mantiene una IP virtual estable y distribuye las peticiones entre todos los Pods que cumplan su selector de etiquetas.

En ambos casos, el balanceo interno es automático: tú defines el número de réplicas y el orquestador se encarga de repartir el tráfico.

Balanceo Mediante Reverse Proxy e Ingress

Para exponer aplicaciones al exterior con funciones avanzadas (rutas por dominio, TLS, redirecciones), se usa un nivel adicional de balanceo:

  • Reverse proxy: un servidor como Nginx o Traefik situado delante de las réplicas que recibe el tráfico externo y lo reparte. Ejemplo conceptual de configuración Nginx:
upstream miapp {
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000;
}

server {
    listen 80;
    location / {
        proxy_pass http://miapp;
    }
}

Explicación:

  • upstream miapp: define un grupo de servidores backend (las IPs ficticias de las réplicas).

  • proxy_pass http://miapp: reenvía las peticiones entrantes al grupo, repartiéndolas entre los backends.

  • Ingress (Kubernetes): un objeto que gestiona el acceso HTTP/HTTPS externo y enruta según el host o la ruta hacia los Services internos. Requiere un Ingress Controller (por ejemplo, Nginx Ingress). Ejemplo de manifiesto:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: miapp-ingress
spec:
  rules:
    - host: miapp.ejemplo.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: miapp-service
                port:
                  number: 80

Explicación línea a línea:

  • kind: Ingress: objeto que define reglas de enrutado HTTP externo.
  • rules.host: dominio (ficticio) que activa esta regla.
  • path / pathType: Prefix: aplica la regla a todas las rutas que empiecen por /.
  • backend.service: el Service interno (miapp-service, puerto 80) al que se envía el tráfico.

Introducción al Autoescalado (HPA)

Hasta ahora hemos escalado manualmente. Kubernetes permite escalar de forma automática según la carga con el Horizontal Pod Autoscaler (HPA), que ajusta el número de réplicas en función de métricas como el uso de CPU.

kubectl autoscale deployment miapp-deployment --cpu-percent=70 --min=2 --max=10

Explicación:

  • kubectl autoscale deployment ...: crea un HPA para el Deployment indicado.
  • --cpu-percent=70: objetivo de uso medio de CPU; si se supera, se añaden réplicas.
  • --min=2 / --max=10: límites inferior y superior de réplicas.

El HPA observa continuamente la métrica y ajusta las réplicas: las aumenta cuando la carga sube y las reduce cuando baja, dentro de los límites definidos. Requiere que el clúster disponga de un metrics server para recopilar las métricas.

Consideraciones de Estado: Stateless vs Stateful

El escalado horizontal funciona de maravilla con aplicaciones stateless (sin estado) y se complica con las stateful (con estado).

Característica Stateless Stateful
Guarda datos en la instancia No Sí
Cualquier réplica atiende cualquier petición Sí No siempre
Facilidad de escalado Alta Baja, requiere coordinación
Ejemplos API REST, servidor web Bases de datos, colas

Recomendaciones:

  • Diseña tus aplicaciones para que sean stateless: no guardes datos de sesión ni ficheros en el contenedor.
  • Externaliza el estado a servicios especializados: bases de datos, cachés (Redis) o almacenamiento de objetos.
  • Para cargas con estado en Kubernetes, existen objetos específicos como StatefulSet y volúmenes persistentes, que aportan identidad estable y almacenamiento a cada réplica.

Así, cualquier réplica puede atender cualquier petición indistintamente, que es justo lo que permite escalar y balancear sin problemas.

Errores Comunes y Consejos

  • Escalar una aplicación stateful como si fuera stateless: provoca inconsistencias de datos. Externaliza el estado primero.
  • Escalar sin balanceo: añadir réplicas sin un balanceador no mejora nada; asegúrate de que el tráfico se reparte.
  • Olvidar los límites de recursos: sin requests/limits de CPU y memoria, el scheduler no puede ubicar bien los Pods y el HPA no funciona correctamente.
  • HPA sin metrics server: el autoescalado por CPU necesita métricas; sin el componente que las recopila, el HPA no actúa.
  • Confiar solo en el escalado vertical: tiene un techo (el del hardware) y deja un único punto de fallo. Prioriza el horizontal.
  • Sesiones pegajosas innecesarias: si dependes de que cada usuario vuelva siempre a la misma réplica, pierdes flexibilidad. Externaliza la sesión.

Ejercicios

Ejercicio 1

Explica con un ejemplo la diferencia entre escalado horizontal y vertical, e indica cuál es preferible en un entorno de contenedores y por qué.

Ejercicio 2

Indica los comandos para escalar a 6 réplicas un servicio miapp_web en Docker Swarm y un Deployment miapp-deployment en Kubernetes.

Ejercicio 3

Crea un HPA para el Deployment miapp-deployment que mantenga el uso de CPU en torno al 60 %, con un mínimo de 3 y un máximo de 12 réplicas. Explica brevemente qué hará.

Soluciones

Solución al Ejercicio 1:

El escalado vertical consiste en dar más recursos a una sola instancia: por ejemplo, pasar un contenedor de 1 a 4 GB de RAM. El horizontal consiste en ejecutar más instancias: por ejemplo, pasar de 2 a 8 réplicas del mismo contenedor. En entornos de contenedores se prefiere el horizontal porque ofrece alta disponibilidad (si una réplica cae, las demás siguen atendiendo), no está limitado por el tamaño de una única máquina y encaja con el balanceo de carga automático de los orquestadores.

Solución al Ejercicio 2:

# Docker Swarm
docker service scale miapp_web=6

# Kubernetes
kubectl scale deployment miapp-deployment --replicas=6

Solución al Ejercicio 3:

kubectl autoscale deployment miapp-deployment --cpu-percent=60 --min=3 --max=12

Este HPA vigila el uso medio de CPU de los Pods del Deployment. Si supera el 60 %, añade réplicas (hasta un máximo de 12); si baja, las reduce (hasta un mínimo de 3). Así la aplicación se adapta automáticamente a la carga sin intervención manual.

Conclusión

En este tema hemos aprendido a escalar aplicaciones contenedorizadas y a balancear su tráfico. Hemos diferenciado el escalado horizontal del vertical, gestionado réplicas en Swarm y Kubernetes, comprendido el balanceo interno y el realizado con reverse proxy e ingress, introducido el autoescalado con HPA y reflexionado sobre la importancia de diseñar aplicaciones stateless. Con esto cerramos el Módulo 6 sobre Docker en producción. En el siguiente módulo, Ecosistema y Herramientas de Docker, exploraremos las herramientas que rodean y amplían Docker, empezando por Docker Machine.

◄ Anterior
◄
Siguiente ►
►
El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
© Copyright 2026. Todos los derechos reservados