Deployment en Kubernetes

📌 ¿Qué es un Deployment en Kubernetes?

Un Deployment es un objeto de alto nivel de Kubernetes que define y gestiona la creación, actualización y escalado de Pods de manera declarativa. Es la forma más común y recomendada para desplegar aplicaciones en Kubernetes.

El Deployment asegura que siempre haya una cantidad deseada de Pods disponibles y operativos, y permite actualizarlos de forma controlada.

🎯 Objetivos principales de un Deployment

• Crear y administrar Pods y sus réplicas.
• Actualizar una aplicación sin tiempo de inactividad (rolling updates).
• Revertir a una versión anterior si ocurre un error.
• Escalar horizontalmente (más o menos réplicas).
• Asegurar la alta disponibilidad.

🧱 Componentes de un Deployment

Un archivo de Deployment (.yaml) incluye:

• apiVersion: Versión de la API de Kubernetes.
• kind: El tipo de recurso, que es Deployment.
• metadata: Información como el nombre y etiquetas.
• spec: Especificación del Deployment:
  • replicas: Número de réplicas deseadas.
  • selector: Cómo identificar qué Pods maneja este Deployment.
  • template: La plantilla de los Pods que se van a crear (como si fuera un Pod).
    • Incluye contenedores, puertos, variables de entorno, etc.

🧠 ¿Cómo funciona internamente?

Kubernetes usa el Deployment Controller que constantemente compara el estado deseado (especificado en el .yaml) con el estado actual del clúster. Si detecta diferencias:

• Crea nuevos Pods.
• Elimina los que sobran.
• Reemplaza versiones antiguas por nuevas (si hay cambios en la imagen, por ejemplo).

Esto se hace de forma gradual y controlada mediante un rolling update, lo que evita el tiempo de inactividad.

🔁 Actualizaciones controladas

Recreate

Es una estrategia de actualización en la cual Kubernetes primero elimina todos los Pods antiguos antes de crear los nuevos.

1. Elimina todos los Pods actuales del Deployment.
2. Espera a que todos los Pods se terminen por completo.
3. Luego crea los nuevos Pods con la versión actualizada.

spec:
  strategy:
    type: Recreate

Esto es lo opuesto a RollingUpdate, que actualiza los Pods uno por uno sin bajar todo el servicio.

Rolling Updates

La estrategia RollingUpdate permite que los Pods antiguos sean reemplazados gradualmente por Pods nuevos, sin eliminar todos al mismo tiempo. Es decir, la aplicación sigue disponible durante toda la actualización.

En el yaml se coloca:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

1. Crea un nuevo Pod con la nueva imagen.
2. Espera a que esté en estado "Listo".
3. Elimina uno de los Pods antiguos.
4. Repite el proceso hasta completar el cambio.

🎯 Objetivo: mantener siempre un número mínimo de Pods funcionando. Esto evita que el servicio se caiga.

🔢 Parámetros clave

🔹 maxUnavailable

• Número (o porcentaje) máximo de Pods que pueden estar no disponibles durante la actualización.
• Por defecto: 25%
• Ejemplo:
  • Si tienes 4 réplicas y maxUnavailable: 1, se puede apagar 1 Pod durante la actualización.

🔹 maxSurge

• Número (o porcentaje) máximo de Pods que se pueden crear por encima del número deseado de réplicas.
• Por defecto: 25%
• Ejemplo:
  • Si tienes 4 réplicas y maxSurge: 1, Kubernetes puede tener hasta 5 Pods durante la actualización (1 extra).

♻️ Rollback

Un rollback es la acción de revertir un Deployment a una versión anterior, generalmente porque la nueva actualización falló o tuvo problemas (como errores en la app, fallas de conectividad, caídas, etc.).

Este comando revierte el Deployment a la versión anterior (revisión anterior).

kubectl rollout undo deployment <nombre-del-deployment>

Cada vez que haces una actualización del Deployment (por ejemplo, cambias la imagen), Kubernetes guarda una "revisión" del Deployment. Estas revisiones se numeran automáticamente.

kubectl rollout history deployment <nombre>

📈 Escalado (Scaling)

Puedes aumentar o reducir el número de réplicas fácilmente:

kubectl scale deployment <nombre> --replicas=5

O modificar el campo replicas: en el YAML y aplicar con kubectl apply.

✅ Ventajas de usar Deployments

• Permiten automatizar la gestión de aplicaciones.
• Son ideales para ciclos de vida largos de aplicaciones.
• Facilitan el CI/CD (integración y entrega continua).
• Ofrecen resistencia a fallos (si un Pod falla, se reemplaza automáticamente).
• Permiten una gestión declarativa y reproducible de tus aplicaciones.

🧪 Ejemplos

Crear un deploymen manual sin yaml

A continuación, muestro un ejemplo completo de cómo crear un Deployment de forma manual desde la consola con kubectl create deployment, y luego realizar una actualización con rolling update (cambio de versión de NGINX) sin usar archivo YAML.

kubectl create deployment nginx-deployment --image=nginx:1.21

Este comando crea un Deployment con:

• Nombre: nginx-deployment
• Imagen: nginx:1.21
• Réplicas: 1 (por defecto)

Para ver mejor el efecto del rolling update, escálalo a 3 réplicas:

kubectl scale deployment nginx-deployment --replicas=3

Vemos los pods creados:

kubectl get pods

Actualizar la imagen a nginx:1.25 (rolling update)

kubectl set image deployment/nginx-deployment nginx=nginx:1.25 --record

Este comando hace:

• Cambio de versión de la imagen (nginx:1.21 → nginx:1.25)
• Rolling update automático (sin downtime)
• Guarda el cambio en el historial (--record)

kubectl rollout status deployment nginx-deployment

También puedes observar los Pods mientras se actualizan:

kubectl get pods -w

Revisamos los pods y el deployment

kubectl get deploy -o wide

Ver historial de versiones

kubectl rollout history deployment nginx-deployment

Revertir la actualización (opcional)

kubectl rollout undo deployment nginx-deployment

Con estos pasos podemos crear un deployment manual.