GitHub выпустила Actions Runner Controller 0.15.0 для крупных пулов в Kubernetes

GitHub сообщила о выпуске Actions Runner Controller 0.15.0. Обновление затрагивает надёжность, масштабирование и наблюдаемость runner scale sets, однако подробный список изменений компания пока не опубликовала в кратком анонсе.

Actions Runner Controller управляет self-hosted runner’ами GitHub Actions в Kubernetes
Actions Runner Controller управляет self-hosted runner’ами GitHub Actions в Kubernetes
Изображение из исходного материала

GitHub сообщила о выпуске Actions Runner Controller (ARC) версии 0.15.0 — инструмента для управления self-hosted runner’ами GitHub Actions в Kubernetes. Анонс опубликован 1 октября 2026 года в GitHub Changelog.

Главный фокус релиза — runner scale sets, то есть группы исполнителей, которые контроллер создаёт и масштабирует для заданий GitHub Actions. По заявлению GitHub, версия 0.15.0 содержит улучшения надёжности, масштабируемости и наблюдаемости. Компания рассчитывает, что они помогут обслуживать крупные конфигурации с меньшим числом перебоев во время обновлений и изменений Kubernetes API.

При этом исходный анонс остаётся кратким. В нём нет количественного сравнения с предыдущей версией, полного перечня исправлений, списка изменённых метрик или результатов независимого тестирования. Поэтому заявления об улучшении устойчивости и масштабирования пока следует рассматривать как описание разработчика, а не как подтверждённый бенчмарк.

На какие сценарии рассчитан релиз

ARC связывает GitHub Actions с Kubernetes: runner’ы выполняют задания CI/CD, а контроллер управляет их жизненным циклом и масштабированием. Такой подход позволяет запускать исполнителей в собственном кластере и подстраивать их количество под текущую нагрузку.

Версия 0.15.0 особенно ориентирована на установки с большим числом runner scale sets. В подобных конфигурациях проблемы с контроллером или Kubernetes API могут затрагивать сразу несколько групп runner’ов. Даже кратковременные сбои способны привести к задержкам в очереди заданий, ошибкам масштабирования или неполному отображению состояния инфраструктуры.

GitHub отдельно упоминает работу во время обновлений и изменений Kubernetes API. Это не означает, что новая версия автоматически устраняет все риски совместимости: конкретные версии Kubernetes, настройки доступа, сетевые политики и способ установки ARC остаются значимыми факторами. Подробные требования нужно сверять с документацией GitHub по ARC.

Корректное завершение и обслуживание кластера

В описании релиза также выделено graceful shutdown — корректное завершение работы компонентов. Для инфраструктуры CI это важно при плановых перезапусках, обновлении контроллера и обслуживании Kubernetes-кластера.

При резкой остановке можно потерять состояние операций или прервать выполнение заданий. Корректное завершение должно дать системе возможность обработать остановку предсказуемо, однако опубликованный анонс не уточняет, какие именно компоненты ARC изменились и как новая версия ведёт себя с уже запущенными заданиями.

Из сообщения GitHub нельзя сделать вывод, что все рабочие процессы будут продолжены без прерывания или что переход на 0.15.0 исключает простои. Перед обновлением стоит отдельно проверить перезапуск контроллера, удаление и создание runner’ов, а также поведение заданий при плановом обслуживании узлов.

Для сравнения с текущей установкой полезно зафиксировать версию ARC, Kubernetes, конфигурацию runner scale sets и параметры ресурсов. Исходный код и материалы по проекту доступны в репозитории actions/actions-runner-controller на GitHub.

Что меняется в наблюдаемости

Третье направление релиза — observability, или наблюдаемость. GitHub говорит об улучшении точности метрик, которые используются для контроля состояния контроллера и runner scale sets.

Для команд с большим количеством групп это может иметь практическое значение: операторы опираются на метрики при настройке оповещений, анализе очередей и поиске причин, по которым новые runner’ы не создаются вовремя. Ошибочные или неполные показатели способны скрыть проблему либо, наоборот, создать ложный сигнал.

В анонсе не названы конкретные метрики, их прежние и новые имена, а также возможные изменения форматов или меток. Поэтому после обновления недостаточно проверить, что контроллер запустился. Нужно убедиться, что дашборды продолжают получать данные, правила оповещений срабатывают, а значения действительно отражают число доступных runner’ов и состояние масштабирования.

До появления подробных примечаний к версии нельзя утверждать, что обновление будет полностью совместимо с каждой существующей системой мониторинга.

Что проверить перед обновлением до 0.15.0

Командам, использующим ARC в production, разумно сначала развернуть версию 0.15.0 в тестовом кластере. Минимальная проверка может включать следующие сценарии:

  • запуск нескольких заданий с разной длительностью и параллельностью;
  • масштабирование runner scale sets при росте очереди;
  • перезапуск контроллера во время выполнения заданий;
  • плановое обслуживание Kubernetes-узлов;
  • проверка создания, остановки и повторного подключения runner’ов;
  • сравнение метрик и оповещений с показателями предыдущей версии;
  • проверка журналов контроллера после обновления Kubernetes API или связанных компонентов.

Отдельно стоит проверить инструкции по обновлению и совместимости для конкретной конфигурации. Краткое сообщение GitHub не содержит сведений о необходимых изменениях манифестов, известных ограничениях или миграциях. Если такие детали не указаны в документации, переход лучше проводить поэтапно — сначала на небольшой группе runner scale sets, затем на остальной инфраструктуре.

На данный момент подтверждено появление ARC 0.15.0 и заявлены улучшения в трёх областях: надёжность, масштабирование и наблюдаемость. Насколько заметным будет эффект для конкретного кластера, зависит от числа групп, характера заданий и версии Kubernetes.

Источники