Si alguna vez has tenido que actualizar una aplicación crítica en producción, sabes que hacerlo puede ser todo un desafío. El riesgo de downtime o de errores inesperados es alto, y eso afecta directamente a la experiencia de usuario y a la confiabilidad de tu servicio. Aquí es donde entra en juego el blue green deployment, una estrategia que permite desplegar nuevas versiones sin interrumpir a los usuarios, y lo mejor: con la posibilidad de hacer rollback rápidamente si algo falla.
En mi experiencia como ingeniero DevOps, he implementado múltiples veces esta técnica en clústeres Kubernetes de diferentes tamaños y entornos, desde startups hasta grandes corporaciones. En este artículo te contaré cómo implementar blue green deployment en Kubernetes paso a paso, con explicaciones claras, ejemplos prácticos y recomendaciones avanzadas para que puedas asegurar tus despliegues y mejorar la gestión de versiones.
¿Qué es exactamente blue green deployment y por qué es tan valioso en Kubernetes?
El concepto de blue green deployment es simple: tener dos entornos totalmente idénticos, llamados “blue” y green. En cualquier momento, uno de ellos está recibiendo todo el tráfico de producción (activo) y el otro está inactivo, listo para recibir una versión nueva o ser el fallback. Cuando tienes que actualizar tu aplicación, despliegas la nueva versión en el entorno inactivo (por ejemplo, el entorno green), y solo una vez que verificas que funciona correctamente, rediriges las peticiones para que apunten al nuevo entorno. Esto garantiza:
- Cero downtime porque el entorno activo sigue funcionando hasta el último momento.
- Rollback inmediato: si algo va mal, solo tienes que volver a apuntar el tráfico al entorno anterior.
- Pruebas en producción más seguras: puedes hacer validaciones con tráfico real sin afectar a los usuarios.
En Kubernetes, estos entornos se implementan fácilmente con recursos separados, como Deployments y Servicios, usando etiquetas y selectores para controlar qué versión recibe el tráfico.
Paso 1: Preparar tus recursos de Kubernetes para el blue green deployment
Lo primero es definir bien los recursos que representarán los entornos blue y green. Para esto, crearemos dos Deployments independientes, con etiquetas claras que diferencian cada versión.
Ejemplo de Deployment para el entorno blue:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: blue
template:
metadata:
labels:
app: myapp
version: blue
spec:
containers:
– name: myapp
image: myapp:v1
ports:
– containerPort: 8080
Luego, defines uno similar para myapp-green, apuntando a la nueva imagen, por ejemplo myapp:v2.
🔴 ¿Quieres entrar de lleno al mundo DevOps & Cloud Computing? 🔴
Descubre el DevOps & Cloud Computing Full Stack Bootcamp de KeepCoding. La formación más completa del mercado y con empleabilidad garantizada
👉 Prueba gratis el Bootcamp en DevOps & Cloud Computing por una semanaDespués, creas un Servicio único que controle el tráfico y que apunte únicamente al entorno activo, usando para esto el selector de etiquetas:
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
selector:
app: myapp
version: blue # al inicio, solo blue recibe tráfico
ports:
– port: 80
targetPort: 8080
type: ClusterIP
De este modo, dependiendo de la etiqueta version que apunte el Servicio, dirigirás el tráfico a blue o green.
Paso 2: Desplegar la nueva versión en el entorno inactivo y validar
Cuando quieras lanzar una actualización:
- Aplica el Deployment para la nueva versión (por ejemplo,
myapp-green). - Espera a que los Pods se levanten y estén en estado Ready.
- Realiza pruebas funcionales y de carga. Puedes usar
kubectl port-forwardpara acceder directamente al entorno green sin afectar el servicio en producción:kubectl port-forward deployment/myapp-green 8080:8080 - Verifica logs, métricas y comportamientos para asegurarte que todo funciona como esperas.
Paso 3: Cambia la versión activa actualizando el selector del Servicio
Con la nueva versión validada, es momento de redirigir el tráfico. Para ello, actualiza el selector del Servicio para que apunte a la etiqueta version: green:
kubectl patch service myapp-service -p ‘{«spec»:{«selector»:{«app»:»myapp»,»version»:»green»}}}’
Este cambio es instantáneo y Kubernetes rerutea todas las solicitudes al entorno green sin downtime visible para los usuarios.
Paso 4: Monitorea el despliegue y ten un plan de rollback
La supervisión es clave para detectar problemas tempranos. Recomiendo usar herramientas como Prometheus y Grafana para monitorear métricas de latencia, errores y disponibilidad. Además, puedes configurar alertas para reaccionar rápido. Si detectas cualquier problema, simplemente vuelve a apuntar el selector del Servicio a la versión anterior (version: blue), haciendo un rollback en segundos.
Optimización avanzada: Integrando CI/CD, Helm y gestión de tráfico con Istio
En proyectos reales, automatizar el blue green deployment potencia la eficiencia y reduce errores manuales. Aquí te comparto mejores prácticas que usé personalmente en varios despliegues complejos:
- CI/CD con Jenkins, GitLab o GitHub Actions: automatiza la creación y despliegue de los ambientes blue y green, pruebas automatizadas y actualización del selector del Servicio.
- Helm para gestión de plantillas: usar charts parametrizables facilita crear y mantener los Despliegues y Servicios para blue green con un solo comando.
- Service Mesh (Istio/Linkerd): permite gestionar reglas de enrutamiento más granulares, haciendo posible desde despliegues blue green más sofisticados hasta despliegues canary y A/B testing sin tocar directamente los Servicios.
- ArgoCD o Flux: para GitOps, facilitando el control declarativo del estado de los clústeres y las versiones desplegadas.
Estos enfoques no solo fortalecen la estrategia blue green sino que aportan control y trazabilidad ideales para ambientes productivos.
FAQs sobre implementación blue green deployment en Kubernetes
¿Puedo usar blue green deployment en un solo clúster Kubernetes?
Sí, simplemente usando diferentes etiquetas en tus recursos para identificar blue y green, sin necesidad de varios clústeres.
¿Qué pasa con aplicaciones stateful?
En estos casos hay que manejar el estado con cuidado: usar bases de datos externas, compartir volúmenes con soporte simultáneo o migración del estado para evitar inconsistencias.
¿Cuándo es preferible blue green sobre canary deployment?
Blue green es más directo y seguro para despliegues enteros o cuando necesitas rollback inmediato. Canary es mejor si deseas hacer despliegues graduales y analizar métricas antes del cambio total.
Conclusión: La clave para despliegues confiables está en dominar blue green deployment en Kubernetes
Si quieres profundizar y transformar tu carrera profesional en DevOps, Kubernetes y despliegues avanzados, te invito a visitar el Bootcamp en DevOps & Cloud Computin y conocer sus formaciones especializadas, que te preparan para retos reales del mercado.
He visto proyectos donde la falta de estrategia provocó caídas, pérdida de usuarios y horas de trabajo para revertir. Implementar blue green deployment en Kubernetes es una de las mejores inversiones para hacer que tus lanzamientos sean predecibles y sin sorpresas. Esta técnica te empodera para entregar nuevas versiones a tus usuarios sin interrupciones, con la seguridad de poder revertir con un simple cambio de selector en Kubernetes. Además, combinándola con herramientas como Helm, Istio y CI/CD, podrás alcanzar niveles profesionales en automatización y control. Te recomiendo la siguiente lectura Documentación oficial de Kubernetes sobre Deployments.
