Kustomize base и окружения dev/stage

В «Релизе» уже есть одно dev приложение. Теперь посмотрим на структуру, которая позволяет поддерживать dev и stage без двух расходящихся копий каждого Deployment. Kustomize base хранит общие ресурсы, overlays задают namespace, число копий, image и параметры. Результат — два самостоятельных желаемых набора с общим прикладным контрактом API/web.

Конечный архив содержит gitops/base и оба overlays полностью. Автор не выполнял Kustomize build, kubectl kustomize или sync этих наборов. API сверены с официальным разделом Argo CD о Kustomize. Вывод и его последствия далее ожидаемые; пригодность конкретной toolchain читатель проверяет в своей локальной среде.

Base описывает то, что действительно общее

В base находятся api.yaml, web.yaml и services.yaml. API сохраняет порты, probes, ресурсы и обязательную SecretRef из «Площадки». Web проксирует /api к Service api. Selectors совпадают с Pod labels и не меняются только из-за названия окружения. Такой общий контракт позволяет разобраться в одной цепочке HTTP, затем перенести её в другой namespace.

Base не содержит Namespace или Secret. Их создание относится к bootstrap. Это не недостающий файл конечного примера: reader получает полные команды создания учебных Secret в README. Разделение ответственности важно для allowlist AppProject и дальнейшего prune. Прикладное Application не должно случайно стать владельцем инфраструктуры своего источника или чужих полномочий.

У base есть configMapGenerator api-config с исходными GREETING, APP_VERSION и BOOT_DELAY_MS. Generator формирует версионируемое имя с hash и переписывает ссылку в Deployment. Когда данные меняются, template получает другое имя ConfigMap, что связывает новую конфигурацию с созданием новых процессов. Это помогает избежать ручного restart после простой замены содержимого объекта с постоянным именем.

Overlay задаёт самостоятельный результат

Dev kustomization ссылается на ../../base, задаёт namespace ploshchadka-dev, одну API копию и собственное приветствие. Stage использует ploshchadka-stage и две копии. Web image остаётся один в обеих средах. Stage не становится производственным сайтом из-за имени: это второе локальное окружение того же kind-кластера с выбранными учебными отличиями.

Ниже приведено основное содержание dev файла. Он входит в Git как исходник, а не является временным результатом build.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: ploshchadka-dev
resources:
  - ../../base
images:
  - name: ploshchadka-api
    newTag: '1'
  - name: ploshchadka-web
    newTag: '1'
replicas:
  - name: api
    count: 1
configMapGenerator:
  - name: api-config
    behavior: merge
    literals:
      - GREETING=Площадка — dev
      - APP_VERSION=1

Behavior merge дополняет или заменяет данные generator, уже определённого в base. BOOT_DELAY_MS остаётся общим, GREETING становится dev, APP_VERSION явно соответствует начальной версии. Если вместо merge создать независимый generator с тем же именем без понятного поведения, Kustomize может получить конфликт исходного набора. Здесь связь общих и отличающихся параметров видна прямо в файле.

Namespace transform применяется к namespaced ресурсам и согласует их размещение. Application destination также указывает ploshchadka-dev. Совпадение этих двух решений следует поддерживать: нельзя считать destination универсальным исправлением любого namespace, уже заданного внутри source. Reader читает построенный набор и проверяет адреса, прежде чем sync.

Версионируем конфигурацию вместе с образом

APP_VERSION используется самим API для текста ответа. Если image api два, а параметр остался один, браузер может показать старый номер при новом коде. Поэтому promotion меняет оба поля как совместимый набор. Номер в JSON удобен для урока, но точное происхождение артефакта всё равно определяется image и его проверенным digest, когда он известен.

Hash ConfigMap связан с его данными, а не только с git commit. Изменение replicas не обязано создавать новый config hash. Изменение GREETING может создать другое имя и новую Pod template ссылку при том же image. Так Kubernetes получает конкретный сигнал обновления процессов для новых параметров окружения, не ожидая, что старый Node процесс сам перечитает env.

После нескольких конфигурационных версий старые ConfigMap могут остаться live, поскольку автоматический prune отключён. Они становятся предметом следующего осознанного удаления, а не доказательством неудачной сборки. Для rollback это полезно: прежние ссылки и данные видны, однако сохранение объектов не заменяет наличия старого image и согласованного source состояния.

Reader смотрит построенные адреса

Самостоятельный локальный проход может включать kubectl kustomize нужного overlay для чтения построенного YAML. В этой подготовке команда не выполнялась. Ожидаемый набор dev содержит Deployment api/web, Service api/web и hash ConfigMap в ploshchadka-dev; stage содержит аналогичные имена в своём namespace. Не должно быть инфраструктурных объектов argocd или release-lab.

Идентичность Kubernetes ресурса включает namespace, kind и name. Поэтому одинаковое Service api в dev и stage не является общим объектом. Web DNS имя api разрешается в собственной области, сохраняя локальный маршрут к правильному upstream. Если вынести Service в один общий namespace без изменения URL, прикладной контракт перестанет соответствовать ожиданию.

Одна ошибка в base распространяется на оба окружения. Это цена общего исходника и причина внимательного просмотра совместимого набора. Отличие, которое должно касаться только dev, записывают в dev overlay. Общую поправку readiness, действительно нужную всем, записывают в base. Если постоянно копировать base целиком в stage ради одного числа, будущие исправления снова начнут расходиться.

Два Application не означают один общий sync

Release-dev и release-stage имеют отдельные paths и namespaces, поэтому синхронизируются независимо. Commit может менять только dev overlay: stage желаемое содержимое остаётся прежним, хотя main разрешается в новый commit. Это различие между revision repository и фактическим набором ресурсов конкретного path нужно понимать при чтении history.

Выбор одного Git repository не запрещает переносить stage позже. В нашем маршруте сначала меняют dev, наблюдают его результат, затем отдельным commit переносят те же release поля в stage. Так история показывает решение о продвижении, а ручной sync определяет применение. Полностью автоматический promotion, CI сборка образов и внешние среды архивом не создаются.

Теперь reader может объяснить, какие поля общие, какие зависят от окружения и почему hash конфигурации меняет шаблон процесса. Оба overlays дают полный самостоятельный набор приложения, сохраняя исходные имена «Площадки». Следующая глава превратит это устройство в конкретное продвижение API версии два без повторной сборки разного кода для каждого окружения.

Оглавление серии