¿Qué son los despliegues canarios?

El despliegue canario es una estrategia de lanzamiento de nuevas funciones, en la que la actualización se implementa gradualmente a una pequeña parte de los usuarios y, en ausencia de problemas, se extiende a toda la audiencia.

Fases principales:

1. Despliegue del grupo canario: La nueva versión de la aplicación se implementa en un pequeño subconjunto de servidores o usuarios.
2. Monitoreo: Se realiza un monitoreo exhaustivo de métricas (errores, rendimiento, comportamiento del usuario) para el grupo canario.
3. Expansión o reversión:
   • Si el monitoreo muestra éxito, el despliegue se amplía gradualmente a un grupo mayor de usuarios.
   • Si se detectan problemas, el despliegue se revierte para el grupo canario, protegiendo a la mayoría de los usuarios.

Ventajas:

• Minimización de riesgos: Los problemas afectan a un pequeño subconjunto de usuarios.
• Reversión rápida: Es fácil revertir a la versión anterior.
• Pruebas en condiciones reales: Evaluación del comportamiento de la nueva funcionalidad bajo carga real.

Desventajas:

• Complejidad de infraestructura: Se requiere soporte para varias versiones de la aplicación simultáneamente.
• Gestión del tráfico: Se necesitan mecanismos para enrutar el tráfico a diferentes versiones.
• Análisis de datos: Se requiere una recopilación y análisis efectivos de métricas.

Ejemplo de implementación en Kubernetes:

// Despliegue para v1
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v1
spec:
  replicas: 10 // Cantidad principal
  selector:
    matchLabels:
      app: my-app
      version: v1
  template:
    metadata:
      labels:
        app: my-app
        version: v1
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v1

---

// Despliegue para canario v2
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v2-canary
spec:
  replicas: 1 // Grupo canario
  selector:
    matchLabels:
      app: my-app
      version: v2
  template:
    metadata:
      labels:
        app: my-app
        version: v2
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v2

---

// Servicio para enrutar tráfico (usando selectores)
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Para gestionar la distribución del tráfico entre v1 y v2, se utilizan controladores Ingress (por ejemplo, Nginx Ingress, Istio) con capacidad de distribución ponderada del tráfico.