El coste oculto de 'attaching a runner' en CI/CD: Kubernetes, cloud y self-hosted
La arquitectura de los runners de CI/CD (Kubernetes, nube o self-hosted) define el coste real de las implementaciones. Un análisis de las opciones más comunes.
Tener un runner conectado a tu pipeline no es solo un paso de configuración, es una decisión de infraestructura con coste asociado. En entornos donde el tráfico de commits a main es constante, la forma en que alojes estos agentes determina si tu factura de nube se dispara o se mantiene controlada. La diferencia entre un entorno donde un solo desarrollador prueba el código y uno enterprise con decenas de personas mergeando simultáneamente es abismal en términos de gasto.
Hay tres caminos principales para desplegar estos runners, cada uno con sus implicaciones de coste y complejidad.
El primero es usar un clúster de Kubernetes o OpenShift. Es la opción estándar en entornos corporativos porque permite aislar los runners por proyecto y por entorno (build, test, prod). El problema está en el estado de reposo: muchas configuraciones por defecto de los controladores de runners mantienen al menos un pod activo las 24 horas solo para escuchar jobs. Si el tráfico es alto, los pods escalan hacia arriba bajo carga, y eso encarece la factura rápidamente. Aunque algunos controladores permiten escalar a cero entre jobs, no es el comportamiento predeterminado en la mayoría de los setups.
La segunda opción es el servicio nativo de tu proveedor cloud (AWS, Azure o GCP). Aquí el modelo de precios es por uso, pero la acumulación es similar: cada segundo de ejecución suma y suman.
La tercera vía, y la que ha ganado tracción, es el runner self-hosted. GitHub Actions lo soporta nativamente: creas el runner en los ajustes del repo, descargas el binario y lo instalas en cualquier máquina. La pieza clave que suele sorprender a los administradores es la lógica de red: el agente en tu máquina (una Raspberry Pi, un servidor viejo o un contenedor local) inicia una conexión saliente larga (long-lived connection) hacia GitHub. No es GitHub quien llama a tu máquina. Esto significa que no necesitas abrir puertos entrantes, hacer port forwarding ni tocar la regla de firewall de entrada solo para correr pipelines. Una vez registrado, cada paso del pipeline se ejecuta localmente sin coste adicional de infraestructura en la nube.
Para equipos que buscan reducir costes fijos y tienen hardware disponible, el self-hosted es la vía más eficiente. Para quien necesita aislamiento estricto y escalabilidad elástica sin gestionar hardware físico, Kubernetes sigue siendo la opción, siempre que se configure correctamente la escalada a cero para evitar pods zombis consumiendo recursos.
