kubectl rollout status respondió «successfully rolled out» — pero ¿qué demuestra eso? Solo que los nuevos pods pasaron la readiness probe. La probe comprueba «el proceso arrancó», no «el servicio funciona»: una regresión que sube la error rate del 0,1 % al 2 % es invisible para un RollingUpdate estándar — terminará de reemplazar los pods e informará del éxito. El incidente empieza después, cuando el 100 % del tráfico ya está en la versión nueva. Progressive delivery invierte el modelo: el release es una hipótesis — «la versión nueva no es peor que la vieja» —, el tráfico llega por porciones, las métricas verifican la hipótesis y un fallo revierte el despliegue sin intervención humana. En el stack de la CNCF esa capa la cubre Argo Rollouts.
Rollout en lugar de Deployment
Argo Rollouts es un controlador (se instala una vez por clúster) y el CRD Rollout: un reemplazo del Deployment con el mismo pod template más el campo strategy — blueGreen o canary. En el ciclo GitOps nada se rompe: la CI construye la imagen y actualiza el tag en el repositorio gitops, ArgoCD sincroniza los manifiestos y Rollouts decide cómo la versión nueva recibe tráfico. La separación de responsabilidades queda limpia: GitOps responde «qué desplegamos», progressive delivery responde «a qué velocidad y con qué red de seguridad».
Blue-green: rollback instantáneo a doble precio
La estrategia blueGreen mantiene dos versiones completas a la vez: activeService dirige el tráfico de producción a los pods stable, previewService a los nuevos. Con autoPromotionEnabled: false la promoción se convierte en un gate manual: la versión nueva se puede probar con smoke tests por la dirección de preview mientras el tráfico de producción no la ve. La promoción es un cambio de Service; el rollback, el mismo cambio en sentido inverso — segundos en ambas direcciones. El precio: infraestructura doble mientras dura el release y cuidado extra con las migraciones de base de datos — ambas versiones miran el mismo esquema.
Canary: tráfico por pasos, veredicto por PromQL
La estrategia canary describe el despliegue como una secuencia de pasos: setWeight: 20 → pausa → 50 → 80 → promoción completa. Lo que decide no es la pausa sino el análisis: el bloque analysis conecta un AnalysisTemplate — consultas PromQL con umbrales que el controlador ejecuta en cada paso desde el que se indique. Un análisis fallido es un abort automático: se retira el peso del canary, todo el tráfico vuelve a stable y el objeto queda marcado como Degraded. Nadie despierta al on-call para decidir si revertir — la reversión ya ocurrió.
La calidad del gate la deciden las métricas. La success rate cuenta solo los 5xx: los 4xx son errores del cliente, e incluirlos significa revertir releases por bugs ajenos. La latencia se compara en el P99, no en la media: el P50 esconde la cola, y los usuarios se quejan precisamente de la cola. Ambas consultas suelen existir ya en el clúster — son los mismos SLI que alimentan las alertas de SLO.
Burn rate: el SLO como fusible del despliegue
Conectar el SLO da el siguiente nivel: el análisis observa no la error rate cruda sino la velocidad a la que se quema el error budget. Con un SLO del 99,9 % el presupuesto mensual de errores es de 43 minutos; un burn rate de 10× lo consume en tres días. De ahí la regla «a 10×, parar los despliegues»: una sola condición PromQL api:burn_rate:ratio_rate1h > 10 en el AnalysisTemplate convierte el SLO de métrica de reporting en fusible automático. Un release malo no agota el presupuesto a cero, y uno sano no se bloquea por exceso de cautela: mientras el presupuesto está intacto, una subida menor de errores es un ticket, no un rollback.
Elección de estrategia y tres trampas
La elección es pragmática. Blue-green — cuando los releases son raros, la observabilidad es modesta y el rollback instantáneo es crítico; se paga con infraestructura doble. Canary — cuando los releases son frecuentes y las métricas maduras: más barato, más gradual, más amable con las migraciones de base de datos. Un patrón de promoción probado entre entornos: dev — blue-green con promoción manual; staging y prod — canary con promoción automática.
Las trampas de las primeras adopciones. Primera: el HPA debe apuntar al Rollout (scaleTargetRef con kind: Rollout), no al Deployment — de lo contrario el autoscaling y el despliegue pelean por las replicas. Segunda: instalado vía Kustomize más Helm, ArgoCD muestra los CRD como OutOfSync para siempre — el API server muta el esquema tras el apply; la cura es ignoreDifferences sobre .spec, .status y las annotations. Tercera: durante un canary los secretos viven en dos versiones — los pods canary ven la nueva, los stable la vieja, y el rollback devuelve la vieja; la rotación de secretos debe contemplarlo en el checklist, no descubrirlo durante un incidente.
Progressive delivery no es un lujo de plataformas a escala de Google. Un controlador, un CRD y un AnalysisTemplate con dos consultas PromQL — y el despliegue deja de ser un salto de fe: las métricas que ya recoges para las alertas empiezan a proteger cada release antes de que se convierta en un incidente.