Как реализовать наследование конфигураций в Kubernetes?

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

Основные лайфхаки, так сказать:

1. kustomize (он уже в kubectl встроен, ёпта): Тут идея простая, как три копейки. Делаешь базовую конфигурацию (base/) — этакий фундамент, общий для всех. А потом на него, как дерьмо на вентилятор, набрасываешь оверлеи (overlays/) — они наследуют от base и что-то там своё допиливают или меняют.

   Структура папок получается примерно такая:

   my-app/
   ├── base/                     <-- Здесь лежит святое, основа основ
   │   ├── deployment.yaml
   │   ├── kustomization.yaml
   │   └── service.yaml
   └── overlays/                 <-- А тут уже пошла конкретика, под каждое окружение
      ├── production/           <-- Для продакшена, где всё серьёзно
      │   ├── kustomization.yaml  # Тыкает пальцем на base и говорит: "Вот откуда брать!"
      │   └── replica-patch.yaml   # И тут же свой патч подсовывает
      └── staging/              <-- Для тестов, где можно пошалить
          └── ... (ну вы поняли)

   Сам файл overlays/production/kustomization.yaml выглядит просто, блядь:

   bases:
    - ../../base   # Смотри, мама, я наследую!
   patchesStrategicMerge:
    - replica-patch.yaml  # А это мои личные доработки, чих-пых!

2. Helm Charts и их зависимости (dependencies): Ну, тут тоже понятно. Можно запилить общий chart, объявить его как зависимость в другом, а потом в своём values.yaml переопределять всё, что душе угодно. Как будто взял у соседа табуретку, но обил её новым дермантином, блядь.

3. Янки-трюки (YAML Anchors & Aliases) внутри одного файла: Это для любителей всё в одну кучу, но с изяществом. Типа, объявил шаблон раз и юзаешь его где хочешь.

   # Объявляем якорь, назовём его "база"
   baseConfig: &base
    image: myapp:latest
    ports:
      - containerPort: 8080
   
   # А теперь используем, да ещё и своё добавляем!
   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: app-production
   spec:
    template:
      spec:
        containers:
          - name: app
            <<: *base  # Всё из якоря "база" сюда прилетело, магия, блядь!
            env:       # А это уже наши личные понты
              - name: ENV
                value: "production"

Итог, ёпта: Если не хотите, чтобы ваши конфиги превратились в адское месиво, где ни хуя не разберёшься, то kustomize — ваш выбор, чуваки. Он нативный, гибкий, и им не надо ебаться с установкой кучи лишнего софта. Всем спасибо, я отдыхаю.