GitHub publicó el 30 de septiembre la versión 0.15.0 de Actions Runner Controller (ARC), con cambios orientados a mejorar la fiabilidad, escalabilidad y observabilidad de las flotas de runners autoalojados en Kubernetes. La compañía señala que la versión reduce interrupciones durante actualizaciones y disminuye carga innecesaria sobre la API de Kubernetes, según el changelog oficial.
Las actualizaciones de parche interrumpen menos los scale sets
ARC 0.15.0 modifica cómo se actualizan determinados recursos durante cambios de versión. Las actualizaciones de parche pasan a ejecutarse en el propio recurso, reduciendo el impacto entre autoscaling runner sets y ephemeral runner sets.
También mejora el apagado del controlador. terminationGracePeriodSeconds pasa a ser configurable y se alinea con el tiempo de apagado ordenado del controller manager.
Más control sobre capacidad y API de Kubernetes
GitHub permite configurar límites QPS y burst para el cliente Kubernetes de los listeners y añade parámetros de concurrencia globales o por controlador mediante max-concurrent-reconciles. Además, los controladores filtran eventos entrantes para ejecutar menos reconciliaciones innecesarias.
En entornos con muchos scale sets, estas opciones ayudan a evitar que la capa de control genere presión excesiva sobre el clúster.
Las métricas sustituyen parte de las actualizaciones de estado
La agregación de estado de EphemeralRunnerSet y AutoscalingRunnerSet se traslada a métricas. Esto reduce peticiones de actualización de estado y mejora la observabilidad de la flota sin escribir constantemente sobre recursos de Kubernetes.
La versión también permite volver a registrar un runner scale set cuando el registrado ya no existe en el servicio de Actions y acelera la eliminación de runners efímeros cuando el pod termina correctamente.
Qué debería comprobar una empresa antes de actualizar
Los equipos con ARC deberían probar primero 0.15.0 en un clúster no crítico, revisar métricas de listeners y controladores y comparar tiempos de escalado y reconciliación. Si existen límites personalizados de API o políticas de apagado, conviene validar que los nuevos parámetros no entren en conflicto con la configuración del clúster.
Las mejoras tienen más impacto cuanto mayor es la flota. Para una pyme con pocos runners, el cambio puede notarse sobre todo durante upgrades y picos de CI; para organizaciones grandes, puede reducir carga operativa y errores de control.
Este cambio encaja con otras novedades recientes que conviene revisar en equipos técnicos: la actualización de GitHub CodeQL, el proof of presence de GitHub, la adopción de passkeys en Microsoft Entra, el parche crítico de GitLab, el nuevo Microsoft Defender ISOC y Cloudflare Threat Signals.
Fotografía: Lukas Blazek / Pexels.
