kpt как WYSIWYG для Kubernetes или почему «конфигурация как данные» лучше шаблонов

Недавно проект 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.