¿Quién necesita blue-green? Historias de actualizaciones de Kubernetes en vivo

Actualizar un clúster de Kubernetes en caliente puede sonar a jugar con fuego, pero si preguntas a suficientes ingenieros, descubrirás que un número sorprendente guarda las cerillas a mano.

En un mundo ideal, todos haríamos despliegues blue-green con precisión de cirujano: levantar un clúster nuevo, replicar el entorno, pasar todas las pruebas de integración y accionar la palanca solo cuando los astros se alineen. En el mundo tangible, muchos equipos prefieren decir: "Qué más da. Lo actualizamos in-place". Y la verdad es que funciona con mucha más frecuencia de lo que cabría esperar.

El camino cómodo no siempre es el equivocado

La confesión que desató esta ola de complicidad fue directa: "Actualizando el clúster in-place porque me da demasiada pereza hacer blue-green".

No había detrás una gran justificación de arquitectura ni un análisis de riesgos complejo, solo ese momento tan humano de "no tengo ganas". La respuesta superó los 700 votos a favor y un hilo de comentarios que recordaba a una sesión de terapia grupal para ingenieros de DevOps que alguna vez desplegaron cambios un viernes. Resulta que muchísima gente hace exactamente esto, y vive para contarlo.

La realidad de actualizar clústeres sobre el terreno

Uno esperaría encontrar historias de terror con despliegues rotos y rollbacks desesperados, y claro que hay alguna. En su mayoría, sin embargo, lo que abunda es humor socarrón, conocimiento práctico compartido y la certidumbre colectiva de que casi nadie dispone del tiempo ni del presupuesto necesarios para mantener una higiene de infraestructura impecable.

Un participante lo soltó sin rodeos: "Llevo años haciéndolo in-place. Quizá mire blue/green en 2026".

Otro se sumó: "Aquí con AKS... lo hacemos in-place desde el primer día... tenemos suficientes entornos para probarlo todo antes". Esa es la línea común: probar a conciencia, contener la respiración y pulsar el botón de actualizar.

No confundas ese tono desenfadado con pura temeridad. Muchos de estos profesionales tienen un plan de acción bien definido, aunque se parezca más a una batalla de trincheras que a una operación quirúrgica. Escalonan la actualización de los grupos de nodos, vacían los nodos con prudencia, revisan dos veces los CRD y suelen ensayar todo el proceso en un entorno de pruebas previo.

"Todo en default" y otras decisiones arriesgadas

El premio al mayor desparpajo ante el caos se lo llevan quienes ejecutan desarrollo, QA y producción dentro del mismo clúster, a veces incluso en el mismo namespace. Un comentario captó la esencia a la perfección: "Sí, también es el clúster de dev y QA". Al que siguió de inmediato: "Los auténticos valientes usan un solo namespace para los tres".

Casi puedes oír el grito ahogado de cualquier auditor de cumplimiento que lea esto. Aun así, el cielo no se ha caído sobre sus cabezas, al menos por ahora.

Algunos admitieron que ni siquiera cuentan con un clúster de desarrollo independiente. Un usuario lo resumió así: "No tengo clúster de desarrollo, ¿eso responde a tu pregunta?". Sí, responde de sobra.

El coste de hacer las cosas "como es debido"

Los despliegues blue-green dependen tanto de los recursos disponibles como de las buenas prácticas: tiempo, presupuesto y personal. Muchos equipos, en especial empresas emergentes o departamentos técnicos reducidos, se ven obligados a sopesar el ideal teórico frente a lo que resulta razonablemente viable.

Un arquitecto puso sobre la mesa el verdadero dilema: "Al arquitecto jefe le gusta decirme que no tenemos suficiente madurez porque no usamos blue-green ni tenemos un clúster de respaldo en marcha. Tengo que recordarle que empezamos así, pero lo dejamos por costes… complejidad".

Eso no es pereza, sino un compromiso operativo del tipo que cualquier ingeniero asume a diario.

EKS, AKS y el alivio de un plano de control administrado

Se percibe una notable inyección de confianza entre quienes recurren a servicios gestionados como EKS y AKS. Cuando otra entidad vigila el plano de control, cuesta mucho menos atreverse con un: "Venga, lo hacemos en vivo".

Tal como escribió un usuario: "Ahora gestiono EKS, y en mi trabajo anterior era autogestionado; en ambos casos in-place va bien, basta con leer los cambios incompatibles de antemano".

El dolor de cabeza real llega con los nodos de trabajo, sobre todo si ejecutas aplicaciones como Jenkins que no toleran bien los cambios sobre la marcha, o si mantienes entornos autogestionados donde cada fase de la actualización se siente como desactivar una bomba con los ojos vendados.

"Aprender es divertido" (hasta que deja de serlo)

Las anécdotas no paran de salir. Algunos desarrolladores borraron nodos pensando que acelerarían el proceso, solo para darse cuenta demasiado tarde de que se habían quedado sin grupos de nodos útiles. Otros repartieron certificados de cluster-admin a todo el equipo y confiaron en la suerte.

Un veterano resumió la actitud: "A veces es mejor tirarse a la piscina y resolverlo sobre la marcha. Si es producción, seguro que lo tienes solucionado antes de que amanezca". Una frase que suena menos a consejo y más a desafío de DevOps.

Entonces... ¿quién necesita de verdad blue-green?

¿Es blue-green un lujo, una prueba de madurez o simplemente otra casilla en la carta a los Reyes Magos de DevOps? Quizá las tres cosas. Apostar por blue-green no está mal, pero prescindir de él tampoco te convierte en un mal profesional.

Lo que enseñan las trincheras es que los equipos salen adelante adaptando las mejores prácticas a su realidad cotidiana. Priorizan una buena cobertura de pruebas, leen con atención las notas de versión y hacen ensayos en staging, incluso si acaban pulsando "actualizar" sobre el mismo clúster de producción que atiende el tráfico real. Lo hacen porque es lo que su infraestructura, sus finanzas y su negocio permiten.

Acepta el caos, pero respétalo

Nada de esto busca ensalzar la temeridad técnica. El trabajo real de infraestructura se mueve en ese punto intermedio e imperfecto entre la teoría y la práctica.

Si actualizas in-place, estupendo, pero hazlo con cabeza: vigila tus dependencias, drena los nodos y lee a fondo los cambios que rompen compatibilidad. Y si disfrutas del lujo de montar un blue-green, magnífico, pero eso no te otorga superioridad moral. Lo fundamental es tener muy claro por qué eliges el método que utilizas.

Al final del día, a Kubernetes le da igual si eres precavido, comodón o brillante. Lo único que le importa es si rompes algo. Y cuando eso ocurra (que ocurrirá), más vale que tus DNS propaguen rápido, tus CRD se comporten bien y tu plan de vuelta atrás sea algo más serio que "echarle la culpa al proveedor de red".