Apagar de noche los clústeres no productivos de Kubernetes: 3.390 euros menos
Un administrador automatizó el escalado a cero de sus entornos de desarrollo y pruebas en OpenShift y Kubernetes con etiquetas de horario y un job programado que restaura las réplicas por la mañana.
Los entornos de desarrollo y pruebas se pasan la noche y el fin de semana sin que nadie los toque, pero siguen quemando cómputo. Un administrador ha contado cómo automatizó el apagado y el encendido de sus clústeres no productivos en OpenShift y Kubernetes, y sostiene que la factura pasó de 18.572 a 15.182 euros. La cifra es suya: no hay desglose de cuánto corresponde a cómputo, cuánto a almacenamiento ni en qué periodo se mide ese ahorro.
El problema no era técnico, era de disciplina
El punto de partida es el de siempre. Apagar a mano se olvidaba, y cuando alguien se acordaba de cerrar, otro equipo se quejaba a la mañana siguiente porque su entorno no estaba listo a primera hora. Cualquiera que haya gestionado namespaces compartidos reconoce el patrón: nadie discute que sobran recursos, lo que falta es que el apagado no dependa de la memoria de una persona.
Su enfoque se apoya en tres piezas. Primero, etiquetar namespaces o cargas de trabajo con una etiqueta de horario. Segundo, un job programado que recorre lo etiquetado, baja los deployments a cero réplicas por la noche y por la mañana los devuelve al número de réplicas que tenían antes. Tercero, una lista de exclusiones para lo que tiene que seguir en pie y alertas si un escalado de subida falla.
Ese último detalle es el que separa una automatización que sobrevive de una que alguien desactiva a la semana. Bajar a cero es trivial; lo que rompe el inventario es que el encendido de la mañana no complete, porque entonces el equipo pierde media jornada y el responsable del script lo apaga para siempre. De ahí que las alertas no sean un adorno.
El texto no entra en dónde se guarda el recuento previo de réplicas entre el apagado y el encendido, ni qué pasa si alguien despliega durante la ventana de cero. Tampoco publica código ni repositorio, así que ahora mismo es un enfoque que hay que reimplementar, no un proyecto que se instale con un helm chart.
Donde el patrón se rompe
Escalar deployments a cero no vale para todo. Las bases de datos con estado, las colas que acumulan mensajes y los servicios que mantienen sesiones en memoria no se llevan bien con desaparecer cada noche, y esos son justo los que más caros salen. Lo razonable es empezar por lo que se puede matar sin consecuencias y dejar el resto en la lista de exclusiones, que es exactamente para lo que el autor la usa.
Para quien tenga clústeres efímeros de revisión de pull requests, la idea es aún más rentable: esos entornos no deberían existir más allá de lo que dura la revisión, y muchas veces ahí siguen. Un etiquetado de horario y un job programado cubren buena parte del caso, y en Kubernetes las herramientas para hacerlo ya están en el propio plano de control: un CronJob y permisos para tocar el campo de réplicas. El ahorro concreto dependerá de cuánto de vuestro gasto esté en entornos que nadie usa fuera de horario, y esa proporción suele ser más alta de lo que la gente cree.
