Despliegues avanzados en Kubernetes: estrategias y buenas prácticas

Estrategias de despliegue en Kubernetes

Los Deployments de Kubernetes ofrecen diferentes estrategias para actualizar tus aplicaciones. Elegir la estrategia adecuada es crucial para minimizar las interrupciones del servicio y garantizar una transición fluida.

Estrategia de reemplazo (Recreate)

La estrategia de reemplazo detiene todas las instancias de la versión anterior antes de iniciar las nuevas.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0

Ventajas:

• Sencilla de entender y de depurar
• Garantiza que solo una versión se ejecute a la vez

Inconvenientes:

• Tiempo de inactividad durante el despliegue
• Sin rollback automático en caso de fallo

Casos de uso:

• Aplicaciones que no admiten varias versiones simultáneas
• Entornos de desarrollo o de pruebas
• Aplicaciones con dependencias críticas de base de datos

Estrategia de Rolling Update (RollingUpdate)

La estrategia de actualización progresiva sustituye gradualmente las instancias antiguas por otras nuevas, manteniendo un número mínimo de instancias disponibles. Es la estrategia por defecto.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Número máximo de pods adicionales permitidos
      maxUnavailable: 0  # Número máximo de pods no disponibles durante la actualización
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0

Ventajas:

• Sin tiempo de inactividad
• Rollback automático en caso de fallo
• Control preciso sobre el proceso de actualización

Inconvenientes:

• Más compleja de configurar
• Puede requerir más recursos durante la actualización

Casos de uso:

• Aplicaciones en producción
• Servicios que requieren alta disponibilidad
• Aplicaciones que admiten varias versiones simultáneas

Estrategia de Blue/Green Deployment

Aunque Kubernetes no ofrece de forma nativa el despliegue blue/green, puedes implementarlo utilizando servicios y Deployments.

# Déploiement "Blue" (version actuelle)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
---
# Déploiement "Green" (nouvelle version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: myapp
        image: myapp:1.1
---
# Service qui pointe vers la version active
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
    version: blue  # Changez pour "green" pour basculer vers la nouvelle version
  ports:
  - port: 80
    targetPort: 8080

Ventajas:

• Cambio instantáneo entre versiones
• Sin degradación del servicio durante la actualización
• Rollback sencillo cambiando el selector del servicio

Inconvenientes:

• Requiere el doble de recursos durante el despliegue
• Configuración más compleja
• Requiere una gestión manual o un script para el cambio de versión

Casos de uso:

• Aplicaciones críticas con ventanas de mantenimiento estrictas
• Servicios que requieren un cambio rápido en caso de problema
• Aplicaciones con dependencias complejas entre versiones

Estrategia de Canary Deployment

Un despliegue canary expone una pequeña parte del tráfico a la nueva versión antes de desplegarla por completo.

# Déploiement principal (version actuelle)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-main
spec:
  replicas: 9
  selector:
    matchLabels:
      app: myapp
      version: main
  template:
    metadata:
      labels:
        app: myapp
        version: main
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
---
# Déploiement canary (nouvelle version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
      version: canary
  template:
    metadata:
      labels:
        app: myapp
        version: canary
    spec:
      containers:
      - name: myapp
        image: myapp:1.1
---
# Service qui distribue le trafic
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

Ventajas:

• Pruebas en producción con un riesgo mínimo
• Detección temprana de problemas
• Posibilidad de recopilar métricas antes del despliegue completo

Inconvenientes:

• Configuración más compleja
• Requiere una supervisión atenta durante la fase canary
• Puede requerir herramientas adicionales para el enrutamiento del tráfico

Casos de uso:

• Aplicaciones con un gran número de usuarios
• Servicios que requieren validación en producción
• Despliegues de alto riesgo

Gestión de rollbacks

Los rollbacks son esenciales para mantener la disponibilidad de tu aplicación en caso de problemas con una nueva versión.

Rollback automático con health checks

Configura sondas de salud (liveness y readiness) para que Kubernetes pueda detectar automáticamente los problemas y efectuar un rollback.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

Rollback manual con kubectl

Puedes efectuar un rollback manual a una versión anterior utilizando el comando kubectl rollout undo:

# Rollback vers la version précédente
kubectl rollout undo deployment/app-deployment

# Rollback vers une version spécifique
kubectl rollout undo deployment/app-deployment --to-revision=2

Buenas prácticas para los despliegues

1. Utiliza tags de imagen específicos

Evita usar latest como tag de imagen, ya que dificulta el seguimiento de las versiones y puede provocar despliegues no reproducibles.

# À éviter
image: myapp:latest

# Recommandé
image: myapp:1.0.2

2. Define límites de recursos

Especifica los límites de recursos para evitar que un pod consuma demasiados recursos y afecte a los demás pods.

spec:
  containers:
  - name: myapp
    image: myapp:1.0
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

3. Utiliza reglas de anti-afinidad

Despliega los pods en distintos nodos para mejorar la disponibilidad.

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - myapp
          topologyKey: kubernetes.io/hostname

4. Implementa estrategias de escalado

Configura el autoescalado horizontal (HPA) para ajustar automáticamente el número de réplicas en función de la carga.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-deployment
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

5. Utiliza ConfigMaps y Secrets

Separa la configuración de la aplicación del código para facilitar las modificaciones sin tener que reconstruir la imagen.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  LOG_LEVEL: info
---
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DB_PASSWORD: base64encodedpassword
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets

Ejemplo de despliegue completo

Este es un ejemplo completo de un Deployment de Kubernetes con las mejores prácticas:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0.2
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - myapp
              topologyKey: kubernetes.io/hostname
---
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

Conclusión

Los despliegues avanzados en Kubernetes ofrecen una gran flexibilidad para gestionar las actualizaciones de tus aplicaciones. Al elegir la estrategia de despliegue adecuada y seguir las mejores prácticas, puedes garantizar una transición fluida entre versiones manteniendo la disponibilidad de tu servicio.

En el próximo artículo exploraremos la gestión de secretos y configuraciones en Kubernetes, un aspecto crucial para proteger tus aplicaciones.