Kubernetes переписал ядро Image Promoter: в 10 раз быстрее без простоев

Каждый контейнерный образ, загружаемый из registry.k8s.io, проходит через kpromo — промоутер образов Kubernetes. Этот инструмент копирует образы из промежуточных (staging) регистров в производственные, подписывает их с помощью cosign, реплицирует подписи по более чем 20 региональным зеркалам и генерирует аттестации происхождения SLSA. Если kpromo выходит из строя, релиз Kubernetes блокируется. За последние несколько недель команда переписала его ядро с нуля, удалила 20% кодовой базы и сделала его значительно быстрее — и никто этого не заметил. В этом и заключалась цель.

Как устроен kpromo и почему потребовалась перезапись

Промоутер образов появился в конце 2018 года как внутренний проект Google, созданный Линусом Арвером. Основная задача заключалась в замене ручного, доступного только сотрудникам Google процесса копирования образов в k8s.gcr.io на GitOps-подход, управляемый сообществом. Разработчик отправляет образ в staging-регистр, открывает PR с YAML-манифестом, проходит ревью и мерж — автоматизация выполняет остальное. Этот процесс был формализован в KEP-1734.

В начале 2019 года код переместился в репозиторий kubernetes-sigs/k8s-container-image-promoter и быстро разрастался. За несколько лет Стивен Август объединил несколько инструментов (cip, gh2gcs, krel promote-images, promobot-files) в единый CLI под названием kpromo. Репозиторий переименовали в promo-tools. Адольфо Гарсия Вейтия (Puerco) добавил поддержку подписи cosign и SBOM, Тайлер Феррара — сканирование уязвимостей, а Карлос Панато поддерживал проект в рабочем состоянии. 42 контрибьютора сделали около 3500 коммитов в более чем 60 релизах. Инструмент функционировал, но к 2025 году код нёс на себе груз семи лет инкрементальных доработок от разных SIG и подпроектов. В README прямо указывалось: «вы увидите дублированный код, несколько техник для выполнения одной задачи и несколько TODO».

С какими проблемами столкнулись разработчики

Производственные задачи по продвижению образов для основных компонентов Kubernetes регулярно занимали более 30 минут и часто завершались ошибками из-за ограничения скорости (rate limit). Базовая логика промоутера превратилась в монолит, который было сложно расширять и трудно тестировать. Добавление новых возможностей, таких как поддержка нескольких архитектур или улучшенное логирование, требовало значительных усилий и могло нарушить существующую функциональность. Кроме того, команда стремилась повысить надёжность: любой сбой в промоутере блокировал выход релиза, а ручное вмешательство было рискованным и медленным.

Как проходила перезапись: подход и результаты

Команда подошла к задаче системно. Вместо того чтобы пытаться рефакторить существующий монолит, они решили переписать ядро с нуля, сохранив совместимость API и формат YAML-манифестов. Основные изменения коснулись логики сравнения образов: старая версия загружала полные списки тегов из обоих регистров и сравнивала их в памяти, что приводило к огромным накладным расходам. Новая версия использует потоковую обработку и параллельные запросы, что сократило время выполнения типовой задачи с 30 минут до менее чем 3 минут. Удалось удалить 20% кодовой базы — около 6 тысяч строк кода, которые были либо дублированы, либо больше не нужны. При этом все существующие тесты и интеграционные проверки проходят без изменений.

Какие преимущества получила инфраструктура Kubernetes?

Для конечных пользователей Kubernetes ничего не изменилось: образы по-прежнему доступны по тем же URL, с теми же подписями и аттестациями. Разработчики, которые открывают PR с новыми образами, также не увидят разницы в процессе. Однако команда инфраструктуры Kubernetes получила более надёжный и быстрый инструмент. Ускорение в 10 раз означает, что окно уязвимости между коммитом и доставкой образа сокращается, а вероятность сбоев из-за rate limit снижается. Кроме того, новая архитектура упрощает добавление функций: теперь проще реализовать поддержку новых архитектур, улучшить мониторинг или интегрироваться с другими системами безопасности.

Кого затронет это изменение

В первую очередь это изменение важно для мейнтейнеров Kubernetes и операторов, управляющих собственными регистрами образов. Для компаний, использующих Kubernetes в production, улучшение означает более стабильные и быстрые обновления. Разработчики, работающие над инструментарием вокруг Kubernetes, могут использовать новую кодовую базу как эталон для своих проектов. В сообществе СНГ, где популярны self-hosted решения, ускорение промоутера может снизить нагрузку на каналы связи при синхронизации образов.

Что будет дальше

Команда планирует продолжить оптимизацию: в ближайших релизах ожидается улучшение обработки ошибок и добавление метрик для мониторинга производительности. Также ведётся работа по интеграции с новыми форматами подписей и аттестаций. Репозиторий promo-tools остаётся открытым для контрибьюций, и команда приглашает разработчиков присоединиться к улучшению инструмента. Основной фокус — сохранить незаметность: все изменения должны быть прозрачны для пользователей.

Итог

Незаметная перезапись ядра kpromo — пример того, как инфраструктурные проекты могут эволюционировать без простоев и без ущерба для пользователей. Удаление 20% кода и десятикратное ускорение — это не просто техническое достижение, а повышение надёжности всего процесса релиза Kubernetes. Следить за развитием promo-tools стоит всем, кто работает с контейнерными образами в масштабе Kubernetes.