Есть ли способ использовать центральный патч для нескольких файлов kustomization.yaml?
Допустим, у меня есть 2 файла kustomization.yaml, каждый из которых определяет resource одного и того же типа/пространства имен/имени. Но я хочу иметь один патч, применимый к каждому.
Структура каталогов:
- patches
- directory1
- kustomization.yaml
- service-a.yaml
- directory2
- kustomization.yaml
- service-a.yaml
каталог1/customization.yaml:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: numaflow-system
resources:
- service-a.yaml # defines Service "Service-A" in namespace "Namespace-A"
каталог2/customization.yaml:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: numaflow-system
resources:
- service-a.yaml # defines Service "Service-A" in namespace "Namespace-A"
В моем каталоге patches я хочу иметь патч для «Service-A», который применим к обоим. Мы также можем представить, что в том же каталоге есть еще много патчей для других ресурсов, каждый из которых определен в каталоге1 и каталоге2.
Есть ли способ ссылаться на этот каталог patches из каждого файла kustomization.yaml? Стремимся сделать это таким образом, чтобы не требовалось отдельно перечислять все отдельные файлы исправлений в каждом файле kustomization.yaml.
Мы попытались обновить файл kustomization.yaml, включив в него:
patchesStrategicMerge:
- ../patches
Но, возможно, там нельзя ссылаться на каталог?
Я пытался создать простой пример, представив, что это всего лишь один сервис. На самом деле оба файла service-a.yaml будут состоять из множества определений ресурсов. На самом деле их будет не только 2, а по одному для каждой версии кода. И пытаюсь найти способ не перечислять каждый файл патча отдельно в каждом файле kustomization.yaml.
По сути, наша база кода состоит как из нашего кода, так и из манифеста ресурсов, которые нам нужно запустить. Это медленно меняется с каждым выпуском программного обеспечения. у нас есть файл kustomization.yaml для каждой версии и набор исправлений, которые считаются совместимыми с каждой версией.
Ответы 1
tl;dr: Вы можете делать все, что хотите, используя компоненты kustomize , но я обеспокоен тем, что это решение закрывает проблему, вызванную организацией вашего репозитория.
Учитывая такую раскладку:
.
├── directory1
│ ├── kustomization.yaml
│ └── service-a.yaml
├── directory2
│ ├── kustomization.yaml
│ └── service-a.yaml
└── patches
└── mypatch
└── kustomization.yaml
Как выглядит patches/mypatch/kustomization.yaml (обратите внимание на apiVersion и kind):
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
patches:
- patch: |-
apiVersion: v1
kind: Service
metadata:
name: postgresql
labels:
patched_label: is very exciting
Мы можем написать тогда написать directory1/kustomization.yaml вот так:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: mynamespace
resources:
- service-a.yaml
components:
- ../patches/mypatch
И аналогично для directory2.
Предположим, что directory1/service-a.yaml выглядит так:
apiVersion: v1
kind: Service
metadata:
name: postgresql
spec:
ports:
- name: postgresql
port: 5432
selector:
name: postgresql
Запуск kustomize build directory1 выдаст на выходе:
apiVersion: v1
kind: Service
metadata:
labels:
patched_label: is very exciting
name: postgresql
namespace: mynamespace
spec:
ports:
- name: postgresql
port: 5432
selector:
name: postgresql
Как это выглядит?
Что беспокоит по поводу организации репозитория?
Обычно, если я хочу применить одно и то же исправление к нескольким манифестам, я бы менял структуру, чтобы исправление применялось на самом внешнем уровне, а не то, что мы делаем здесь. Но я недостаточно знаю об организации вашего репозитория, чтобы понять, уместно ли это.
Было бы полезно иметь больше информации здесь. Чем
service-a.yamlотличается в двух каталогах? Каково содержание патча? Вероятно, существует несколько способов решения этой проблемы, и детали имеют значение.