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 к широкому внедрению, а главная цель — стабилизировать программный оболочку для выхода первой версии.

В дорожной карте:

• улучшение пайплайнов — нужен рост производительности и плагин возможностей для работы с внешними подключениями;

• новая документация — требуется полная реструктуризация для нормальной читаемости и соответствия индустриальным стандартам;

• долгожданные функции — нативная обработка секретов, мультикластерная сопровождение и интеграция с Helm.

Проект открыт к контрибьюторам. Все движение — на GitHub, неформальное общение — в Slack.