Недавно проект kpt официально пополнил ряды «песочницы» CNCF. Если открыть документацию, нас встретит тяжеловесное определение. Переведем его на человеческий язык и разберемся, зачем CNCF перезапускает kpt, в чем его фундаментальное отличие от Kustomize и почему подход Configuration as Data спасает при деплое.
kpt — что это и для чего
kpt работает с пакетами Kubernetes Resource Model (KRM) — декларативными YAML-манифестами, описывающими желаемое состояние ресурсов. Пакет не привязан к сложной инфраструктуре. это может быть что угодно: локальная папка на ноутбуке, ZIP-архив или подкаталог в Git-репозитории.
Внутри пайплайнов работают встроенные валидаторы и мутаторы, которые проверяют и модифицируют содержимое пакетов.
Термин WYSIWYG — «Что видишь, то и получишь» — пришел из мира текстов и означает предсказуемость печати. Здесь же это значит, что файл — ровно то, что окажется в кластере. Никаких изменений «на лету» в процессе доставки, никаких внешних шаблонов или скрытых метамоделей.
Кажется, что kpt умеет почти все. Он и создает базовые заготовки, и автоматически превращает шаблоны в параметризованные конфигурации для сотен разных площадок. Он берет на себя ревью, валидацию и сам деплой с мониторингом статуса.
Немаловажно, что kpt модульный — любую его часть легко встроить в уже существующий CI/CD-процесс.
Данные вместо кода: в чем профит
Подход «конфигурация как код» (CaS, Configuration as Code) уже привычен, но kpt идет дальше: «конфигурация как данные» (CaD, Configuration as Data). Инфраструктура хранится, управляется и версионируется как чистое описание, а не прячется внутри исполняемых скриптов.
Что все это дает на практике.
Идеальный аудит — структурированные данные можно сравнить, прогнать через линтер и отправить на ревью без запуска кода. Четко видна разница — до и после применения изменений.
Разделение ответственности — намерения и логика их воплощения живут отдельно.
«Компонуемость» — разные утилиты способны читать и трансформировать одни и те же модели, а функции легко выстраивать в цепочки независимых, тестируемых мутаций.
Хотите выиграть призы и бонусы на аренду серверов?
Приглашаем решить ИТ-кроссворд! Более 100 вопросов на разные темы из мира ИИ и машинного обучения — ежедневно с 6 по 9 июля.
Чем же не угодил Kustomize
Рынок оркестрации перегрет. Справедлив вопрос: зачем тащить в проект еще одно решение? Тому есть несколько причин.
Во-первых, обновления in-place (на месте). Тот же Kustomize генерирует итоговые манифесты динамически через систему патчей (оверлеев) прямо во время рендера. А вот kpt позволяет изучить и согласовать финальную конфигурацию заранее — никаких сюрпризов при развертывании в рабочее окружение.
Во-вторых, снижение рисков. Строгое отделение KRM-моделей от KRM-функций минимизирует непредсказуемое «сползание» конфигурации и неожиданные побочные эффекты.
В-третьих, фокус на главном. Не смотрю на свою универсальность, kpt не пытается стать «швейцарским ножом». Напротив, решается конкретный пласт задач с опорой на расширяемую библиотеку функций и поддерживается интеграция с признанными лидерами: ArgoCD, Flux, Helm и Porch.
Где kpt уже работает
Помимо базовых песочниц с Nginx и WordPress, в репозитории kpt-samples недавно появился пример работы с проектом Headlamp.
Самый сложный и масштабный пример — в проекте Nephio, где kpt выступает ключевым звеном пайплайна для развертывания open-source сетей (RAN и Core) поверх Kubernetes.
Курс на первый выпуск
Статус CNCF Sandbox — только начало. Сейчас команда готовит kpt к широкому внедрению, а главная цель — стабилизировать API для выхода первой версии.
В дорожной карте:
улучшение пайплайнов — нужен рост производительности и расширение возможностей для работы с внешними подключениями;
новая документация — требуется полная реструктуризация для нормальной читаемости и соответствия индустриальным стандартам;
долгожданные функции — нативная обработка секретов, мультикластерная поддержка и интеграция с Helm.
Проект открыт к контрибьюторам. Все движение — на GitHub, неформальное общение — в Slack.
