Каждый образ с registry.k8s.io попал туда через kpromo. Без него ни один выпуск Kubernetes не выходит. Ядро переписали с нуля, удалили 16 000+ строк, ускорили. Пользователи не заметили ничего.
Что делает kpromo
Копирует образы в производственную среду, подписывает через cosign, реплицирует подписи на 20+ зеркал, генерирует аттестации происхождения по SLSA.
Почему понадобился рефакторинг
За 7 лет — 42 участника, 3 500 коммитов, 60+ выпусков. К 2025 производственные задания падали с ошибками лимита запросов и работали больше 30 минут. Монолитная логика мешала.
Как переписывали
9 фаз, каждая — отдельный запрос на слияние.
Фаза 1 — ограничение частоты с адаптивным откатом.
Фаза 2 — реестр и авторизация за интерфейсами.
Фаза 3 — движок конвейера: продвижение как последовательность шагов.
Фазы 4–5 — проверка происхождения SLSA, выпуск v4.2.0 на обкатку.
Фазы 6–9 — разделение подписи и репликации, удаление старого кода.
Новый конвейер
Setup → Plan → Provenance → Validate → Promote → Sign → AttestШаги последовательны — каждый получает полный бюджет лимита запросов.
Производительность
Параллельное чтение 1 350 реестров: фаза Plan с ~20 мин до ~2 мин.
57% образов без подписей — пропускают, обращений к API вдвое меньше.
Проверка основного реестра перед зеркалами: с ~17 часов до ~15 минут.
Итоги
— 40+ запросов на слияние, выпуски v4.2.0, v4.3.0, v4.4.0
— кодовая база уменьшилась на 20%, закрыто 19 задач
— аттестации происхождения, сканирование уязвимостей, логика повторных попыток
Команда
kpromo cip принимает те же флаги и читает те же манифесты. Никто ничего не обновлял.➡️ Блог разработчиков
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#пульс_индустрии