Kubernetes Strategic Merge Patch Simulator
Смоделировать слияние base и overlay манифестов по правилам strategic merge, без установки kubectl.
Как это работает
Обычный YAML-мерж (и даже стандартный JSON Merge Patch из RFC 7396) при слиянии двух объектов с полем-массивом просто заменяет весь массив целиком значением из overlay. Kubernetes strategic merge patch работает принципиально иначе для определённых полей: массив containers мержится поэлементно по полю name — если в overlay указан контейнер с тем же именем, что и в base, их поля объединяются, а не весь список подменяется. Это задаётся через patchMergeKey в OpenAPI-схеме самого Kubernetes и не является общим правилом YAML или JSON — это специфика конкретно объектов Kubernetes. Kubernetes Strategic Merge Patch Simulator online воспроизводит эту логику для типовых объектов вроде Deployment и Pod без необходимости ставить kubectl или kustomize локально.
Base-манифест и overlay почти всегда содержат что-то вроде реальных имён внутренних сервисов, адресов приватного registry с токеном доступа в imagePullSecrets, или конкретных значений resource limits, отражающих реальную нагрузку прод-кластера — не самый очевидный, но вполне реальный источник утечки, если просто вставить оба файла в чат нейросети с вопросом "а как это смержится". А сама механика strategic merge — вещь, в которой путаются даже опытные инженеры: JSON Merge Patch, Strategic Merge Patch и обычная YAML-подстановка друг на друга не похожи, и языковая модель нередко путает эти три разных алгоритма местами, выдавая уверенный, но неверный результат.
Симулятор берёт base-манифест и overlay, применяет strategic merge с учётом patchMergeKey для известных полей вроде containers, volumes и ports (по протоколу и порту), а для незнакомых полей — стандартную рекурсивную логику объединения объектов и полной замены массивов, и показывает итоговый манифест, который реально получит кластер — именно то, что показал бы kubectl kustomize build, не будь его под рукой.
Частые вопросы
Чем strategic merge отличается от обычного JSON Merge Patch?
JSON Merge Patch по RFC 7396 всегда заменяет массив целиком значением из patch, а strategic merge для определённых Kubernetes-полей вроде containers использует patchMergeKey (обычно name), чтобы мержить элементы массива по этому ключу, а не заменять весь список одним куском.
Какие поля Kubernetes-объектов мержатся по ключу, а не заменяются целиком?
Самые частые примеры — containers и initContainers в PodSpec (ключ name), volumes (ключ name), и ports контейнера (составной ключ из containerPort и protocol), полный список задан в OpenAPI-схеме Kubernetes через аннотации patchMergeKey для каждого конкретного поля отдельно.
Работает ли симулятор для CRD, кастомных ресурсов?
Для CRD без собственной OpenAPI-схемы с явно заданными patchMergeKey симулятор применяет стандартную рекурсивную логику объединения объектов, специфичное для конкретного CRD поведение мержа массивов может отличаться и потребует ручной проверки результата.
Можно ли удалить элемент массива через overlay, а не просто добавить?
Strategic merge поддерживает специальную директиву $patch: delete для явного удаления элемента по ключу вместо простого добавления или обновления, симулятор распознаёт эту директиву и обрабатывает удаление корректно, если она встречается в overlay.
Даёт ли симулятор ровно тот же результат, что kubectl kustomize build?
Для типовых Deployment, Pod, Service и похожих встроенных объектов Kubernetes — да, для менее распространённых объектов или сложных комбинаций patches и transformers Kustomize результат стоит перепроверить реальным kubectl kustomize перед боевым применением.