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

Недавно проект kpt официально пополнил ряды «песочницы» CNCF. Если открыть документацию, нас встретит тяжеловесное определение. Переведем его на человеческий язык и разберемся, зачем CNCF перезапускает kpt, в чем его фундаментальное отличие от Kustomize и почему подход Configuration as Data спасает при деплое.

kpt работает с пакетами Kubernetes Resource Model (KRM) — декларативными YAML-манифестами, описывающими желаемое состояние ресурсов. Пакет не привязан к сложной инфраструктуре. это может быть что угодно: локальная папка на ноутбуке, ZIP-архив или подкаталог в Git-репозитории.

Внутри пайплайнов работают встроенные валидаторы и мутаторы, которые проверяют и модифицируют содержимое пакетов.

Термин WYSIWYG — «Что видишь, то и получишь» — пришел из мира текстов и означает предсказуемость печати. Здесь же это значит, что файл — ровно то, что окажется в кластере. Никаких изменений «на лету» в процессе доставки, никаких внешних шаблонов или скрытых метамоделей.

Кажется, что kpt умеет почти все. Он и создает базовые заготовки, и автоматически превращает шаблоны в параметризованные конфигурации для сотен разных площадок. Он берет на себя ревью, валидацию и сам деплой с мониторингом статуса.

Немаловажно, что kpt модульный — любую его часть легко встроить в уже существующий CI/CD-процесс.

Подход «конфигурация как код» (CaS, Configuration as Code) уже привычен, но kpt идет дальше: «конфигурация как данные» (CaD, Configuration as Data). Инфраструктура хранится, управляется и версионируется как чистое описание, а не прячется внутри исполняемых скриптов.

Что все это дает на практике.

Идеальный аудит — структурированные данные можно сравнить, прогнать через линтер и отправить на ревью без запуска кода. Четко видна разница — до и после