Despliegues sin miedo: Argo Rollouts, tu red de seguridad para Kubernetes

Argo Rollouts es un potente controlador de Kubernetes con un conjunto de CRDs que amplía las capacidades de despliegue: blue-green, análisis canary, experimentación y entrega progresiva en Kubernetes.

Argo Rollouts se integra con ingress controllers y service meshes para desplazar el tráfico de forma gradual hacia las nuevas versiones durante una actualización. Además, recolecta y analiza métricas de varios proveedores para verificar KPIs clave y promover o hacer rollback automáticamente durante el proceso.

Al igual que el objeto deployment, el controlador de Argo Rollouts gestiona la creación, el escalado y la eliminación de ReplicaSets. Estos ReplicaSets se definen en el campo spec.template dentro del recurso Rollout, que utiliza la misma plantilla de pod que el objeto deployment. Argo Rollouts no tiene soporte para StatefulSet ni DaemonSet.

Cuando se modifica spec.template, se le indica al controlador de Argo Rollouts que se introducirá un nuevo ReplicaSet. El controlador usará la estrategia definida en el campo spec.strategy para determinar cómo avanzará el rollout desde el ReplicaSet anterior al nuevo. Una vez que el nuevo ReplicaSet termina de escalar (y, opcionalmente, supera un Analysis), el controlador lo marca como "stable".

También puedes usar spec.WorkoadRef para gestionar deployments existentes en Argo Rollouts sin eliminar la configuración actual.

Requisitos previos

• Cluster de Kubernetes configurado y kubectl instalado y configurado.
• Instalar el plugin kubectl de Argo Rollouts en tu máquina.

Instalar Argo Rollouts

• Ejecuta los siguientes comandos para instalar Argo Rollouts en el cluster. Consulta la documentación oficial para conocer más opciones.

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

Estrategia de despliegue Blue-Green

Un despliegue blue-green consiste en correr dos entornos idénticos de forma simultánea. Uno, llamado entorno blue, representa el entorno de producción actual; el otro, llamado entorno green, contiene la nueva versión de la aplicación que quieres desplegar. Durante este tiempo, solo la versión antigua recibe tráfico de producción. Este enfoque permite probar la nueva versión antes de redirigir el tráfico real al nuevo entorno.

representación visual del despliegue blue-green

Veamos cómo aplicar Argo Rollouts a la estrategia Blue-Green con un despliegue sencillo.

• Despliega una aplicación nginx de ejemplo en el cluster con el siguiente comando, que actuará como entorno blue.

kubectl create deployment nginx --image nginx:1.19.10 --replicas 2

Pods de la aplicación de ejemplo

• Crea dos servicios de Kubernetes para el deployment. Uno para el entorno actual (blue) y otro para el nuevo entorno (green).

kubectl expose deployment nginx --name nginx-active --port 80 --target-port 80
kubectl expose deployment nginx --name nginx-preview --port 80 --target-port 80

Servicio y endpoints de ejemplo

• Crea un recurso Argo Rollout con la configuración necesaria para la estrategia Blue-Green. Consulta la documentación oficial para ver todas las opciones.

cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  strategy:
    blueGreen: #Indica que el rollout debe usar la estrategia Blue-Green
      activeService: nginx-active # Referencia al servicio que el rollout modifica como servicio activo.
      previewService: nginx-preview # Nombre del servicio que el rollout modifica como servicio preview.
      previewReplicaCount: 1 #Cantidad de réplicas a correr bajo el servicio preview antes del switchover.
      # Indica si el rollout debe promover automáticamente el nuevo ReplicaSet
      # al servicio activo o entrar en estado pausado. Si no se especifica,
      # el valor por defecto es true. +optional
      autoPromotionEnabled: false
  # WorkloadRef referencia un workload que provee la plantilla de Pod
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
EOF

• Verifica el nuevo replicaset y la configuración de Argo Rollout, como se muestra abajo.

Estado de Pods, Replicasets y Argo Rollout

• Los pods gestionados por el replicaset inicial no se eliminan automáticamente. Se recomienda escalar manualmente las réplicas del deployment a 0, ya que ahora el Argo Rollout se encarga de la gestión. Ejecuta el comando a continuación para reducir los pods no gestionados.

kubectl scale deployment nginx --replicas 0

• Cambiemos la versión de la imagen a latest, lo que disparará una nueva revisión.

kubectl set image deployment/nginx nginx=nginx:latest

Estado del despliegue Blue-Green antes de la promoción

• El entorno Green ya está listo y puedes usar el servicio nginx-preview para probar los cambios sin afectar el tráfico en vivo que sirve el servicio nginx-active.
• También puedes usar el dashboard de Argo Rollouts para monitorear el estado del rollout. Ejecuta el siguiente comando para acceder al dashboard.

kubectl argo rollouts dashboard -n default

Estado del rollout en el dashboard de Argo Rollouts

• Promueve la nueva versión a producción con el siguiente comando.

kubectl argo  rollouts promote nginx

Estado del despliegue Blue-Green después de la promoción

Un despliegue canary es un lanzamiento por fases que reparte el tráfico entre una versión ya desplegada y una nueva, liberándola de forma progresiva a un subconjunto de usuarios antes del rollout completo.

Los ingress controllers y service meshes, como NGINX e Istio, permiten un control de tráfico más avanzado para canary, como la división de tráfico de grano fino o por cabeceras HTTP.

representación visual del despliegue canary

Veamos cómo aplicar Argo Rollouts al despliegue Canary.

• Despliega una aplicación de ejemplo en el cluster.

kubectl create deployment nginx-canary --image nginx:1.19.10 --replicas 5

• Crea un servicio de Kubernetes para el deployment. A diferencia del despliegue Blue-Green, canary no requiere dos servicios distintos para el mismo deployment, ya que los nuevos endpoints de pods se agregan al servicio de Kubernetes según el porcentaje de Canary.

kubectl expose deployment nginx-canary --port 80 --target-port 80

Pods y servicio de la aplicación de ejemplo

• Crea un recurso Argo Rollout para la estrategia canary. Consulta la documentación oficial para ver todas las opciones.

cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx-canary
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx-canary
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-canary
  strategy:
    canary: #Indica que el rollout debe usar la estrategia Canary
      maxSurge: "25%"
      maxUnavailable: 0
      steps:
      - setWeight: 10
      - pause:
          duration: 1h #Pausa por 1 hora y espera para promover a la siguiente etapa canary
      - setWeight: 30
      - pause: {} # pausa indefinida y requiere acción manual de promoción
      - setWeight: 100
      - pause: {} # pausa indefinida y requiere acción manual de promoción
EOF

Estado de Pods, replicaset y Argo Rollout

• Igual que con el despliegue blue-green, hay que escalar a cero las réplicas del deployment actual para que el Argo Rollout pueda gestionar todos los nuevos pods que forman parte del nuevo replicaset.

kubectl scale deployment nginx-canary --replicas 0

• Desplegamos una nueva versión de la aplicación y observamos el despliegue canary.

kubectl set image deployment/nginx-canary nginx=nginx:latest

Estado inicial (10%) del despliegue canary

Estado del rollout canary en el dashboard de Argo

• Promueve manualmente el rollout entre las etapas canary.

kubectl argo rollouts promote nginx-canary

Estado del rollout canary al 30%

Estado del rollout canary en el dashboard de Argo

Estado del rollout canary al 100%

Estado del rollout canary en el dashboard de Argo

Argo Rollouts ofrece una funcionalidad de analysis que te permite definir y ejecutar diversas validaciones y pruebas sobre tu aplicación durante o después de los despliegues, ayudándote a verificar la estabilidad y el rendimiento de la nueva versión antes de promoverla al 100% del tráfico de producción.