Argo Rollouts Kubernetes: Despliegues Canary en 7 Pasos 2026

Argo Rollouts Kubernetes sustituye el Deployment estándar por un controlador que sabe desplegar por fases: envía el 10 % del tráfico a la versión nueva, mide si se comporta bien y decide si sigue o revierte. Todo sin intervención manual y sin sacar a nadie de la cama.

El RollingUpdate nativo de Kubernetes hace una cosa y la hace bien: reemplaza pods sin cortar el servicio. Lo que no sabe hacer es juzgar. Si la versión nueva devuelve errores 500, el rolling update seguirá adelante alegremente hasta reemplazar el último pod.

Qué es Argo Rollouts Kubernetes y qué problema resuelve

Argo Rollouts Kubernetes es un controlador y un conjunto de CRDs que aportan estrategias de despliegue avanzadas: blue-green, canary, análisis automatizado y experimentación. Forma parte del ecosistema Argo, igual que el servidor ArgoCD para GitOps automatizado, pero resuelve un problema distinto: ArgoCD se ocupa de qué se despliega, y este controlador de cómo se despliega.

La pieza central de Argo Rollouts Kubernetes es el recurso Rollout, que reemplaza al Deployment. Su spec.template es idéntico al que ya conoces, pero añade un campo spec.strategy donde describes la progresión. El controlador gestiona los ReplicaSets por debajo y aplica esa progresión paso a paso.

Canary frente a blue-green

Como regla práctica: si puedes convivir con dos versiones sirviendo a la vez, canary. Si las versiones son incompatibles entre sí, blue-green.

Conviene entender qué hace Argo Rollouts Kubernetes por debajo, porque explica casi todo su comportamiento. Cuando modificas spec.template, no toca los pods existentes: crea un ReplicaSet nuevo con la versión entrante y mantiene vivo el anterior. A partir de ahí, cada paso de la estrategia ajusta el número de réplicas de cada ReplicaSet, el peso del enrutado o ambas cosas. Un rollback no es más que devolver el ReplicaSet estable al 100 %, y por eso es prácticamente instantáneo: los pods viejos nunca llegaron a desaparecer.

Requisitos previos antes de instalar Argo Rollouts Kubernetes

La instalación es sencilla, pero hay cuatro condiciones que conviene comprobar antes para no descubrirlas a mitad del primer despliegue.

• Clúster 1.24 o superior y permisos para crear CRDs y ClusterRoles.
• Un servicio con tráfico real. Un canary sobre un servicio que recibe tres peticiones al día no te dirá absolutamente nada.
• Aplicación sin estado o compatible hacia atrás. Durante la progresión conviven dos versiones: si comparten base de datos, el esquema debe soportar ambas.
• Métricas ya disponibles si piensas llegar al análisis automatizado del paso 7.

Ese tercer punto es el que más despliegues rompe. Antes de automatizar nada, revisa si tus migraciones de esquema son compatibles con la versión anterior; si no lo son, blue-green te dará menos disgustos que canary.

Instalar Argo Rollouts Kubernetes en 7 pasos

Necesitas un clúster con Kubernetes 1.24 o superior y kubectl configurado contra él. Los pasos son acumulativos: al terminar tendrás un despliegue canary funcionando de verdad, no un «hola mundo».

Paso 1: desplegar el controlador

El controlador de Argo Rollouts Kubernetes vive en su propio espacio de nombres y vigila los recursos Rollout de todo el clúster.

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

Verifica que el pod arranca correctamente antes de continuar. Si se queda en CrashLoopBackOff, casi siempre es un problema de RBAC en clústeres con políticas restrictivas.

kubectl get pods -n argo-rollouts
kubectl get crd | grep argoproj

Paso 2: instalar el plugin de kubectl

Sin el plugin puedes trabajar, pero a ciegas. Es la herramienta que te deja ver la progresión en tiempo real y promocionar manualmente.

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

kubectl argo rollouts version

Paso 3: convertir tu Deployment en un Rollout

Este es el paso que asusta y no debería. Cambias kind: Deployment por kind: Rollout, ajustas apiVersion y añades la estrategia. El resto del manifiesto se queda igual.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: tienda-api
spec:
  replicas: 10
  selector:
    matchLabels:
      app: tienda-api
  template:
    metadata:
      labels:
        app: tienda-api
    spec:
      containers:
        - name: tienda-api
          image: registry.local/tienda-api:1.4.0
          ports:
            - containerPort: 8080
  minReadySeconds: 30
  revisionHistoryLimit: 3
  strategy:
    canary:
      maxSurge: "25%"
      maxUnavailable: 0
      steps:
        - setWeight: 10
        - pause: { duration: 10m }
        - setWeight: 30
        - pause: { duration: 10m }
        - setWeight: 60
        - pause: { duration: 5m }

Cada setWeight fija el porcentaje de tráfico que recibe la versión nueva y cada pause es una ventana de observación. Un pause: {} sin duración detiene el despliegue indefinidamente hasta que promociones a mano, muy útil para el último salto al 100 %.

Paso 4: definir los servicios

Sin gestor de tráfico, la distribución se aproxima por número de réplicas. Para un reparto exacto necesitas dos servicios y un proveedor de enrutado.

  strategy:
    canary:
      canaryService: tienda-api-canary
      stableService: tienda-api-stable
      trafficRouting:
        plugins:
          argoproj-labs/gatewayAPI:
            httpRoute: tienda-api-route
            namespace: produccion

Aquí encaja de forma natural con el trabajo previo: si ya migraste a Gateway API como evolución del Ingress, el plugin manipula tu HTTPRoute y reparte pesos con precisión real. También funciona con Istio como service mesh o con Ingress NGINX mediante sus integraciones específicas.

La ventaja de la vía Gateway API es que desacopla el controlador del proveedor concreto: cualquier implementación que cumpla la especificación —Traefik, Cilium, Contour, HAProxy o Kuma— queda soportada sin código específico. Tienes los detalles de configuración en la documentación del plugin de Gateway API. Un detalle práctico: el plugin etiqueta las rutas que gestiona mientras dura el despliegue, precisamente para que tu herramienta GitOps pueda ignorarlas y no revierta los pesos temporales.

Paso 5: lanzar y observar el despliegue

Aplica el manifiesto y abre el visor. La primera vez que veas la progresión en la terminal entenderás por qué merece la pena el plugin.

kubectl apply -f rollout.yaml
kubectl argo rollouts get rollout tienda-api --watch

Ahora provoca un despliegue real cambiando la imagen. El controlador arrancará la progresión definida en steps.

kubectl argo rollouts set image tienda-api \
  tienda-api=registry.local/tienda-api:1.5.0

Paso 6: promocionar o abortar

Mientras el despliegue está en pausa tienes el control. Estos son los tres comandos que acabarás usando a diario.

kubectl argo rollouts promote tienda-api
kubectl argo rollouts promote tienda-api --full
kubectl argo rollouts abort tienda-api

El abort devuelve todo el tráfico a la versión estable de inmediato. Es tu botón rojo, y conviene haberlo probado en preproducción antes de necesitarlo en serio.

Paso 7: automatizar la decisión con análisis

Hasta aquí el despliegue avanza por tiempo. El verdadero salto de calidad de Argo Rollouts Kubernetes llega cuando avanza por métricas: un AnalysisTemplate consulta a Prometheus y decide por ti.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: tasa-exito
spec:
  args:
    - name: service-name
  metrics:
    - name: tasa-exito
      interval: 5m
      successCondition: result[0] >= 0.95
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{service="{{args.service-name}}",code!~"5.."}[5m]))
            /
            sum(rate(http_requests_total{service="{{args.service-name}}"}[5m]))

Después lo referencias como un paso más dentro de la progresión. Si la tasa de éxito baja del 95 %, el despliegue se aborta solo.

      steps:
        - setWeight: 20
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: tasa-exito
            args:
              - name: service-name
                value: tienda-api-canary

Para que esto funcione necesitas métricas fiables, así que conviene tener resuelta la capa de observabilidad con Prometheus monitorizando el clúster. La documentación de análisis detalla el resto de proveedores admitidos, como Datadog, New Relic o CloudWatch.

Estrategia blue-green con Argo Rollouts Kubernetes

Si tu aplicación no admite dos versiones conviviendo, cambia la estrategia y quédate con el resto del manifiesto igual. El controlador levantará la versión nueva completa, la dejará accesible en un servicio de vista previa y esperará tu visto bueno antes de conmutar.

  strategy:
    blueGreen:
      activeService: tienda-api-activo
      previewService: tienda-api-preview
      autoPromotionEnabled: false
      scaleDownDelaySeconds: 300
      prePromotionAnalysis:
        templates:
          - templateName: tasa-exito

Los tres campos que marcan la diferencia son autoPromotionEnabled, que en false obliga a una promoción explícita; scaleDownDelaySeconds, que mantiene la versión anterior levantada cinco minutos por si hay que volver corriendo; y prePromotionAnalysis, que ejecuta las comprobaciones contra el servicio de vista previa antes de que ningún usuario real lo toque.

El coste es evidente: durante la ventana de conmutación necesitas el doble de capacidad. En un clúster con autoescalado de nodos eso se traduce en factura, así que ajusta scaleDownDelaySeconds a lo mínimo con lo que te sientas cómodo.

Buenas prácticas de Argo Rollouts Kubernetes en producción

• Empieza sin análisis. Las primeras semanas, usa sólo pausas por tiempo y observa. Automatizar decisiones sobre métricas que no conoces bien es la vía rápida a rollbacks fantasma.
• Ajusta failureLimit con cabeza. Un valor de 1 provoca abortos por un pico puntual; valores altos anulan la protección.
• Mantén maxUnavailable: 0 en servicios críticos, aunque el despliegue tarde algo más.
• No mezcles ventanas largas con GitOps agresivo. Si Flux sincroniza el estado en continuo o lo hace ArgoCD, configura las exclusiones para que no revierta los cambios temporales de peso.
• Usa revisionHistoryLimit bajo. Cada revisión guarda un ReplicaSet; con 3 tienes margen de sobra para volver atrás.

Problemas frecuentes con Argo Rollouts Kubernetes

Un apunte sobre el último caso, porque desconcierta a mucha gente: el autoescalado y la entrega progresiva se pisan si no los coordinas. Con el scaleTargetRef bien apuntado al Rollout, el controlador reparte las réplicas calculadas por el HPA entre la versión estable y la canary respetando el peso vigente. Si lo dejas apuntando al Deployment que ya no existe, el HPA simplemente no hará nada y lo descubrirás el día de más tráfico.

Para el día a día, el controlador incluye además un panel web que se abre con kubectl argo rollouts dashboard y sirve en localhost:3100. No sustituye a tu observabilidad, pero para ver el estado de varias progresiones a la vez y promocionar con un clic resulta cómodo, sobre todo mientras el equipo se acostumbra al flujo nuevo.

Conclusión sobre Argo Rollouts Kubernetes

La entrega progresiva no va de desplegar más rápido, va de reducir el radio de impacto cuando algo sale mal. Argo Rollouts Kubernetes convierte esa idea en algo declarativo y versionable, sin scripts a medida ni intervención humana en mitad de la noche.

Mi recomendación para adoptar Argo Rollouts Kubernetes es empezar por un solo servicio, sin estado y con tráfico suficiente para que las métricas signifiquen algo. Cuando ese primer canary lleve un mes funcionando y hayas visto un rollback automático real, extenderlo al resto será casi trámite. Tienes el proyecto completo en el repositorio oficial de argoproj y la referencia en su documentación.

Preguntas frecuentes sobre Argo Rollouts Kubernetes