Kustomize-конфигурации под ключ: overlay + GitOps для Kubernetes

Разработка Kustomize-конфигураций: где ломается ручное управление

Пока окружений два, манифесты правят руками: копируют рабочий набор, меняют тег образа и число реплик, выкатывают. На третьем контуре появляется тестовый стенд с другим Ingress и лимитами ресурсов, и выясняется, что одинаковых файлов больше нет: расхождения копились месяцами, и уже никто не скажет, какие из них осознанные, а какие — след ночной отладки.

Дрейф конфигураций между окружениями всплывает в самый неудобный момент. Откат на предыдущий релиз не воспроизводится: в кластере остались правки, внесённые напрямую, минуя репозиторий. История изменений инфраструктуры живёт в переписке и чьей-то памяти, а декларативные конфигурации Kubernetes существуют только на бумаге — источник истины размыт между репозиторием и живым кластером.

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

Разработка Kustomize-конфигураций убирает саму возможность такого расхождения: база описывает общее для всех контуров, overlay — только различия, а сборка манифеста предсказуема и повторяема. Разбираем, как это закрывается на практике.

Эффект в эксплуатации: скорость выката, отката и восстановления

Декларативная сборка конфигураций меняет то, как считается время выката релиза. Overlay описывает только отличие среды от базового слоя — разработчик правит дельту, а не копию манифеста целиком, поэтому путь изменения от ветки до работающего пода становится коротким и одинаковым для всех сред. При сборке через Kustomize и хранении окружений в Git выкат сводится к применению уже собранного состояния: нет шага «руками поправить в кластере то, что забыли в репозитории».

Доля ручных операций в релизе падает вместе с этим. Правки доступа, лимитов, числа реплик и адресов внешних сервисов живут в отдельных слоях и наследуются предсказуемо, поэтому типовой релиз проходит без доступа инженера к кластеру. То, что раньше держалось на памяти дежурного, теперь зафиксировано в репозитории и проходит проверку до применения.

Время восстановления после отказа определяется тем, есть ли у системы известное предыдущее состояние. Оно есть: возврат — это откат коммита и повторная сверка, а не аварийное редактирование объектов под нагрузкой. Сверка возвращает кластер к описанному состоянию целиком, включая объекты, которые кто-то изменил вручную между релизами.

Стоимость простоя сервиса здесь считается не часами, а долей часа: инцидент закрывается переключением на проверенную ревизию, а не поиском причины в живом окружении. Уходит целый класс отказов — расхождение конфигураций между стендами и продом, из-за которого одинаковый код ведёт себя по-разному.

Режимы работы с конфигурациями: сравнение подходов

Различия между контурами обычно укладываются в десяток значений: число реплик, лимиты, адреса внешних сервисов, режимы логирования. То, как эти отличия описаны, определяет цену добавления нового окружения и предсказуемость выката — при одном подходе достаточно нового наложения, при другом придётся править все файлы сразу.

Сравнение подходов конфигурирования по трём критериям — где хранятся отличия, сколько ручной работы на новый контур и что происходит с воспроизводимостью:

На практике устойчиво работает связка «общая база конфигураций плюс наложения для окружений»: база проходит проверку один раз, в наложении лежат только отличия, и ревью занимает минуты. Шаблоны с подстановкой переменных оставляем для значений из внешнего источника — адресов и учётных данных; описывать ими всю конфигурацию значит потерять проверку корректности и разбирать результат генерации вручную. Если в проекте до сих пор правят файлы после генерации — это первый признак, что описанием окружений пора заниматься системно.

Этапы внедрения: от аудита до передачи регламентов

Работы идут волнами, и каждая заканчивается проверяемым артефактом: сначала фиксируем фактическое состояние, затем проектируем структуру и лишь потом включаем автоматическую синхронизацию. Порядок убирает классическую ошибку — GitOps подключают раньше, чем конфигурации приведены к единому виду, и оператор начинает удалять то, что годами правили руками.

1. Аудит манифестов и кластера. Сверяем репозиторий с реальным состоянием, находим ручные правки, дубли и расхождения по лимитам. На выходе — карта окружений и список ресурсов, которые нельзя отдавать автоматике.
2. Проектирование структуры. Договариваемся о базовом слое и оверлеях на окружение, об именовании, о том, что уходит в общие патчи, а что в генераторы конфигов и секретов.
3. Настройка репозитория конфигураций. Раскладываем каталоги, встраиваем сборку конфигураций в проверку изменений, включаем валидацию схем и обязательный просмотр разницы перед применением.
4. Сборка окружений. Тестовый, предпродуктивный и продуктивный оверлеи; следим, чтобы различия описывались патчами, а не копиями файлов.
5. Проверка и приёмка на тестовом контуре. Прогоняем полный цикл синхронизации с автокоррекцией дрейфа, смотрим поведение при откате и при удалении ресурса из репозитория.
6. Перенос продакшена. Переводим окружение пошагово, оставляя откат возвратом коммита, и закрываем ручные доступы только после стабильной работы.
7. Передача регламентов. Отдаём инструкции по добавлению окружения и сервиса, правила ревью изменений, порядок отката, проводим обучение дежурной смены.

Состав поставки: репозиторий, схемы окружений, регламенты и доступы

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

• Структура репозитория: базовые слои, наложения под каждое окружение — разработку, стенд, продуктив, общие модули и точки расширения. Порядок применения слоёв зафиксирован, поэтому сборка даёт одинаковый результат у любого инженера.
• Схема окружений: таблица различий — что вынесено в наложения, что осталось общим, какие настройки добавляются при появлении нового стенда.
• Политики доступа и роли: кто правит базовые слои, кто — только наложения стенда, кто подтверждает выкат в продуктив. Права выдаются ролями, персональных исключений нет.
• Работа с секретами: что хранится в защищённом хранилище, как значения подставляются в конфигурации, как проходит ротация и почему ключи не попадают в репозиторий.
• Регламент выката изменений: проверка конфигурации до слияния, обязательная проверка вторым инженером, порядок согласования прод-правок.
• Откат: метки версий, история изменений и пошаговая процедура возврата к предыдущему состоянию — включая случай, когда правка уже затронула данные.
• Документация инфраструктуры: карта окружений, схема зависимостей, инструкция развёртывания с нуля и типовые операции. Новый инженер вводится в контур по ней, без устных пояснений.

Кейс: как сократили время выката и убрали ручные правки

Проект — платформа из 60+ сервисов на четырёх контурах: разработка, тестовый, предпродуктивный и продуктивный. Конфигурации лежали в трёх местах одновременно: шаблоны с переопределениями, скрипты в сборочном конвейере и ручные правки дежурного прямо в кластере, когда нужно было поднять лимиты или сменить адрес внешней зависимости. Чем именно продуктив отличался от предпродуктивного, достоверно не знал никто — кроме инженера, который последним что-то поправил.

Что было до

Выкат одного контура занимал 40–50 минут, и большая часть времени уходила не на сборку, а на ожидание и ручные проверки между шагами. В каждом релизе инженеры вносили 10–14 правок руками: где-то через панель управления кластером, где-то правкой файла на сервере. Ошибка в такой правке не воспроизводилась на тестовом контуре — она проявлялась только на продуктиве, и на разбор уходило от двух часов. Инцидентов, причиной которых было расхождение конфигураций между контурами, набиралось три-четыре в месяц.

Что стало после

Мы перенесли описания в единый декларативный вид на Kustomize: общий базовый слой, поверх него переопределения по контурам, различия вынесены в отдельные файлы, а не спрятаны в скриптах. Изменения проходят проверку и применяются автоматически из репозитория — состояние кластера всегда соответствует тому, что лежит в основной ветке.

Отдельно стоит про долгие разборы: теперь расхождение видно на этапе проверки изменений, до продуктивного контура, поэтому класс отказов «на тестовом работало, на продуктиве нет» из процесса ушёл.

Чем отличается декларативная сборка от шаблонизации?

Шаблонизация подставляет значения в текст манифеста: движок рендерит единый источник с переменными и условиями, и валидный документ получается только после рендера. Наложения — подход Kustomize — работают иначе: поверх общей базы применяется патч, который меняет отдельные поля — число реплик, ресурсы, адрес внешнего сервиса, набор меток. База остаётся самостоятельным рабочим манифестом, который можно применить как есть.

Наложения выигрывают там, где окружения расходятся на единицы полей. Патч стратегического слияния не переписывает структуру, а доопределяет её, поэтому общий каркас живёт в одном месте, а отличия стенда читаются за минуту. Добавили сервис — он появляется во всех окружениях сразу, а выключить его на конкретном стенде можно отдельным исключением.

Шаблоны нужны, когда структура действительно ветвится: разные наборы сервисов, вычисляемые значения, генерация из внешнего реестра. Плата за это — потеря проверяемости до рендера. Шаблон нельзя применить напрямую, и ошибка в условии всплывает уже в кластере, а не на машине инженера.

На дистанции поддержка окружений держится на том, восстанавливается ли итоговое состояние по цепочке «база плюс патчи». Если для ответа на вопрос «что уедет в кластер» надо открыть пять шаблонов и три набора значений, сопровождение превращается в археологию. Практичный выбор — база с наложениями как основа, а шаблон точечно, для мест с настоящей логикой.

Технические сомнения: секреты, окружения, миграция

Сомнения у инженеров возникают не на уровне идеи, а на уровне деталей: где живут секреты, что делать с контуром, который годами правили руками, и как перейти на декларативное управление, не остановив продакшен. Ниже — ответы на то, что чаще всего проверяют перед стартом.

У нас всё настроено руками — переписывать с нуля?

Нет. Сначала снимаем фактическое состояние контура в манифесты и раскладываем его на общий base и overlay. Затем идёт сверка: собранная конфигурация сравнивается с текущей, разница показывается до применения. После переключения контур управляется только из репозитория, а ручная правка откатывается автоматически.

Можно ли мигрировать без остановки продакшена?

Да, переключение идёт по контурам: новый вариант поднимается рядом со старым, проходит проверки на живом трафике, и только потом трафик переводится. Откат — обратное переключение на прежний overlay, занимает минуты и не требует пересборки образов.

Почему стенд и продакшен расходятся?

Потому что различия правят вручную в двух местах. Мы выносим их в overlay явно: число реплик, лимиты ресурсов, адреса внешних сервисов, теги образов. Общий base при этом один, поэтому расхождение видно до применения, а не всплывает в момент релиза.

Что происходит после передачи?

Отдаём репозиторий, схемы окружений и инструкции по типовым операциям — релиз, откат, добавление нового окружения. Обучение проводим на ваших контурах. Дальше — сопровождение по договору: обновления, разбор инцидентов, доработка overlay при росте числа сервисов.

Обсудим задачу и вернёмся с оценкой и планом

Чтобы оценка была предметной, а не «плюс-минус порядок», в заявке достаточно описать несколько вещей — ниже то, что помогает быстрее посчитать объём.

• Целевые кластеры и окружения: сколько их, чем dev отличается от stage и prod.
• Текущее состояние конфигураций: единый набор манифестов, чарты или уже собранные overlay-и, что в них дублируется.
• Состав базового слоя: рабочие нагрузки, сервисы, маршрутизация, параметры окружения, секреты и способ их подстановки.
• Модель доступов: кто меняет конфигурации, нужны ли отдельные роли под команды и ревью изменений.
• Требования к выкату и откату: как быстро возвращать предыдущее состояние, нужны ли поэтапные раскатки.
• Контур GitOps: какая ветка считается источником истины, есть ли ограничения по внешним репозиториям.
• Организационные рамки: закрытый контур, собственные реестры образов, требования безопасности и аудита.

На созвоне уточняем границы: какие окружения идут в первый этап, что переиспользуем из текущих конфигураций, где нужны отдельные слои под команду. На выходе вы получаете оценку объёма, порядок работ по этапам и схему, по которой внедрение декларативных конфигураций под ключ доходит до передачи инфраструктуры команде — с документацией и разбором решений.

Опишите задачу по пунктам выше — обсудим её предметно и вернёмся с оценкой и планом работ.