Planteamiento y alcance
Este es un problema del plano de control de releases, no simplemente cambiar el número de réplicas de un Deployment varias veces. El controlador registra la versión deseada, el paso actual, el peso del tráfico, el resultado del análisis y las decisiones humanas, y luego refleja las acciones de forma confiable en el plano de datos. Google SRE define un canary como un despliegue parcial, limitado en el tiempo y sujeto a evaluación. El RollingUpdate de Kubernetes ofrece una disponibilidad básica; la entrega progresiva añade análisis basado en tráfico, pausas, aprobaciones y rollback automatizado.
Qué evalúa el entrevistador
- Separar el estado del plano de control, de la carga de trabajo, del enrutamiento y del análisis de métricas.
- Modelar la promoción como una máquina de estados duradera e idempotente en lugar de un script irrecuperable.
- Definir ventanas comparables de canary/control, tamaños de muestra, barreras de seguridad (guardrails) y retraso de métricas.
- Manejar un release más nuevo que reemplaza a uno anterior, reinicios del controlador, métricas no disponibles y éxito regional parcial.
- Preservar quién aprobó, por qué un rollout se pausó o abortó, y qué versión quedó como estable.
Preguntas para aclarar primero
- ¿El tráfico se divide por solicitud, usuario, región o réplica? ¿Se requiere asignación estable en buckets?
- ¿Qué métricas son compuertas estrictas (hard gates) y cuáles son de observación? ¿Cómo se definen el error budget y la muestra mínima?
- ¿El rollback solo desvía el tráfico o también detiene y reduce la escala del canary? ¿Cómo se asegura la compatibilidad de formatos de base de datos y mensajes?
- ¿Los pasos son automáticos o requieren aprobación manual? ¿Cómo se autoriza la aprobación?
- ¿Las regiones avanzan juntas, de forma independiente, o una falla regional detiene el rollout global?
Una respuesta en 30 segundos
“Modelaría un release como una máquina de estados duradera con pasos, pesos objetivo, política de pausas, plantilla de análisis, tiempo de espera (timeout) y versión de rollback. Un bucle de reconciliación idempotente aplica el estado deseado a las cargas de trabajo y al enrutamiento, y luego lee el estado real y las métricas acotadas a la versión. La promoción requiere muestras suficientes, una ventana completa y cumplir con las barreras de error, latencia de cola y métricas de negocio; la falta de una fuente de métricas pausa el proceso por defecto. Cada acción lleva una versión de release y de paso, lo que permite que los reinicios converjan de manera segura. Las aprobaciones, pausas, rollbacks y cambios de enrutamiento se convierten en un registro de auditoría.”
Respuesta detallada
Paso 1: Definir recursos y estados
Un recurso de release contiene release_id, versiones candidata y estable, pasos, paso actual, peso objetivo, plantilla de análisis, motivo de pausa, tiempo de espera y política de rollback. Los estados pueden ser PENDING, RUNNING, PAUSED, PROMOTING, ABORTING, SUCCEEDED y FAILED. Cada transición necesita precondiciones explícitas y efectos idempotentes.
Paso 2: Separar los planos de control y de datos
El plano de control almacena el estado deseado y las conclusiones del análisis; el plano de datos ejecuta Pods, Services, Ingress o una service mesh. Una escritura exitosa en la API no equivale al éxito del rollout. Se deben observar las réplicas disponibles, el peso real, la preparación (readiness) y las etiquetas de versión. maxUnavailable y maxSurge de Kubernetes restringen el reemplazo, no el tráfico canary a nivel de solicitud.
Paso 3: Diseñar una asignación de tráfico estable
Utiliza una clave de solicitud o de usuario consistente para que un mismo usuario no salte entre canary y control. La capa de enrutamiento reporta los pesos reales y el conteo de accesos por versión. Para múltiples regiones, almacena el peso objetivo y el real por región; un promedio global no debe ocultar una región con el 100% de fallas.
Paso 4: Definir ventanas de análisis y barreras de seguridad
Una plantilla de análisis declara consultas, período de muestreo, muestra mínima, tolerancia, fallas consecutivas y tiempo máximo de espera. Las métricas cubren disponibilidad, latencia de cola, saturación de recursos y resultados de negocio críticos, cada una etiquetada por versión, región y denominador de tráfico. Una ventana incompleta o la falta de datos pausa el proceso; la ausencia de datos no significa éxito.
Paso 5: Implementar una reconciliación recuperable
El controlador lee periódicamente el release, la carga de trabajo, la ruta y el resultado del análisis para calcular la siguiente acción. Las escrituras externas incluyen release_id y la versión del paso, de modo que los reintentos no dupliquen reglas ni aprobaciones. Tras un reinicio, converge a partir del estado persistido y observado. Si el peso real diverge, pausa y repara antes de continuar con la promoción.
Paso 6: Manejar pausas, aprobaciones y tiempos de espera
Los pasos pueden pausarse automáticamente, por una duración determinada o indefinidamente para aprobación. La aprobación incluye identidad, alcance y la versión del paso actual; una aprobación antigua no puede promover un release nuevo. Un tiempo de espera pausa o aborta según la política, en lugar de expandir el tráfico. Una promoción forzada requiere autorización y un motivo.
Paso 7: Diseñar límites de rollback y compatibilidad
Normalmente, el rollback desvía primero el tráfico hacia la versión estable y luego decide si detener o reducir la escala del canary. Las migraciones de bases de datos, los esquemas de eventos y los formatos de caché necesitan una ventana de superposición compatible con ambas versiones; revertir un binario no puede deshacer escrituras irreversibles. El rollback en sí debe ser idempotente, observable y retener la versión estable anterior.
Paso 8: Verificar, auditar y ensayar
Prueba la promoción, los pesos de enrutamiento, la agrupación de métricas, las pausas, el reinicio del controlador, la caída del sistema de métricas, la caída regional, webhooks duplicados y un release más nuevo reemplazando al actual. Audita el estado deseado y real, el actor, la hora, el motivo y una instantánea de las métricas. El ejercicio debe demostrar que una señal anómala detiene la expansión, no solo que una API devolvió 200.
Compensaciones y límites
RollingUpdate nativo frente a un controlador progresivo
RollingUpdate se adapta a servicios que requieren reemplazo gradual de réplicas y verificaciones de preparación. El tráfico, las métricas de negocio, las aprobaciones y el rollback automatizado requieren capacidades adicionales del controlador o de la plataforma; el porcentaje de réplicas no es el porcentaje de solicitudes.
Rollback automático frente a decisiones humanas
Las compuertas estrictas son adecuadas para fallas de alta confianza y detección rápida. Para métricas de negocio ambiguas o con retraso, la automatización debe pausar y notificar al responsable. La política debe definir la autoridad final de detención.
Progresión global frente a regional
La progresión global es más simple pero amplifica el riesgo regional. La progresión independiente es más segura pero requiere más estado y capacidad. Elige según el aislamiento de tráfico, la residencia de datos y los límites de dominios de falla.
Simulacros de falla y evolución
Falla: tratar la proporción de réplicas canary como proporción de tráfico
El conteo de réplicas no es el conteo de solicitudes; la reutilización de conexiones y el tráfico regional sesgan el peso real. Asigna en la capa de enrutamiento y registra los accesos.
Falla: promover cuando faltan métricas
El retraso en las consultas, los errores de etiquetas o muestras pequeñas pueden generar resultados vacíos. Pausa ante la falta de datos y reconstruye una ventana completa tras la recuperación.
Falla: revertir únicamente la imagen de la aplicación
Escrituras irreversibles de esquemas, eventos o caché pueden hacer que la versión antigua sea ilegible. Agrega compuertas de compatibilidad antes del rollout y desvía el tráfico antes de remediar los datos.
Errores comunes y preguntas de seguimiento
Error: mantener la máquina de estados solo en la memoria del controlador
Un reinicio pierde pasos, aprobaciones y la versión de rollback. Persiste los recursos de release y los eventos de auditoría; la memoria es solo una caché.
Pregunta de seguimiento: ¿cómo evitas que un controlador antiguo sobrescriba un release nuevo?
Utiliza versiones de recursos y de pasos con actualizaciones condicionales. Vuelve a leer antes de escribir y detén acciones obsoletas si la versión cambió.
Pregunta de seguimiento: ¿cómo manejas dos releases al mismo tiempo?
Utiliza un mutex de servicio o ruta, o asigna explícitamente el presupuesto de tráfico entre los candidatos. Dos controladores no deben mutar un mismo peso de forma independiente.
Pregunta de seguimiento: ¿por qué p99 puede sufrir una regresión mientras la latencia promedio es normal?
El promedio oculta un pequeño conjunto de solicitudes severamente lentas. Compara la latencia de cola y los errores con la misma versión, región y denominador.
Pregunta de seguimiento: ¿qué pasa si el sistema de métricas se cae?
Pausa y marca ANALYSIS_UNAVAILABLE, manteniendo el peso actual. Vuelve a ejecutar la ventana tras la recuperación; la falta de datos no es sinónimo de éxito.
Pregunta de seguimiento: ¿cómo mides el propio controlador?
Monitorea el tiempo de permanencia en cada paso, el error de peso real frente al objetivo, la tasa de falsos rollbacks, el retraso en la detección, el tiempo de recuperación, la integridad de la auditoría y las invalidaciones manuales.