pgadmin + managed-postgres целиком

Что нужно знать перед уроком

M6 урок 1 — как объявляется и проверяется requirements.modules.mandatory. Здесь — полный сквозной путь от «модуля нет в кластере вообще» до «Application видит его и полностью работает», на живом примере pgAdmin (веб-интерфейс администрирования PostgreSQL), зависящего от Module managed-postgres.

Теория

Полная цепочка объектов от пустого кластера до работающего Application

Шаг 1–2: ModuleSource → ModuleConfig

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

apiVersion: deckhouse.io/v1alpha1
kind: ModuleSource
metadata:
  name: deckhouse-marketplace
spec:
  registry:
    repo: registry.deckhouse.io/deckhouse/modules
    dockerCfg: <base64-encoded-dockerconfigjson>
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: managed-postgres
spec:
  enabled: true
  settings:
    storageClass: "gp3"
    version: "16"

Проверка на этом шаге (M2 урок 3):

1
2
3

d8 k get modulesource
d8 k get moduleconfig managed-postgres -o yaml
d8 k get module managed-postgres -o jsonpath='{.status.phase}'; echo

Ожидаемый результат: status.phase: Ready у самого Module managed-postgres (Module — не Application, у него нет поля status.summary; готовность отражается именно в status.phase, см. документацию Deckhouse — Жизненный цикл Module) — без этого дальнейшие шаги не имеют смысла, т.к. зависимость ещё не готова.

Шаг 3: PackageRepository — источник самого Application-пакета

1
2
3
4
5
6
7
8
9

apiVersion: deckhouse.io/v1alpha1
kind: PackageRepository
metadata:
  name: my-registry
spec:
  registry:
    repo: registry.example.com/packages
    scheme: HTTPS
    dockerCfg: <base64-encoded-docker-config>

Проверка:

1
2

d8 k get packagerepository
d8 k get applicationpackageversion | grep pgadmin

PackageRepository — независимый от ModuleSource объект (M2 урок 3): один регистрирует источник Module (cluster-wide инфраструктура), другой — источник Application-пакетов (пользовательские приложения). Оба должны быть настроены до установки Application, зависящего от Module: ModuleSource/ModuleConfig — чтобы зависимость физически существовала в кластере, PackageRepository — чтобы сам пакет pgadmin был обнаружен и доступен для установки.

Шаг 4: Application — финальная установка

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: pgadmin
  namespace: team-alpha
spec:
  packageName: pgadmin
  packageRepositoryName: my-registry
  packageVersion: "v8.0.0"
  settings:
    hostname: "pgadmin.example.com"
    defaultEmail: "admin@example.com"

На этом шаге платформа выполняет проверку из M6 урока 1: смотрит requirements.modules.mandatory пакета pgadmin (объявляет зависимость от managed-postgres), проверяет, что модуль присутствует и Ready — и только затем запускает реальный Nelm-рендер (M4) шаблонов пакета.

Проверка на каждом шаге — не только в конце

Ключевой методологический урок этого сценария: не ждите установки Application, чтобы проверить, всё ли настроено правильно — проверяйте каждый промежуточный объект отдельно:

1
2
3
4
5
6
7
8

# Шаг 1-2: Module готов?
d8 k get module managed-postgres -o jsonpath='{.status.phase}'; echo

# Шаг 3: пакет обнаружен?
d8 k get applicationpackage pgadmin -o yaml

# Шаг 4: Application готов?
d8 k get app pgadmin -n team-alpha -o jsonpath='{.status.summary}'; echo

Такая пошаговая проверка резко сокращает время диагностики — если что-то не работает на шаге 4, но шаги 1–3 подтверждены как исправные, вы сразу знаете, что проблема — в самом Application (настройки, шаблоны, хуки), а не в платформенных зависимостях.

Частые ошибки и подводные камни

• Пытаться установить Application раньше, чем зависимый Module перешёл в Ready. Даже если ModuleConfig.spec.enabled: true уже применён, самому модулю может понадобиться время на разворачивание — установка Application до готовности зависимости приведёт к ожидаемому, но избегаемому Installed=False.
• Путать PackageRepository (источник Application-пакетов) с ModuleSource (источник Module). Это независимые объекты для независимых каталогов — настройка одного не влияет на доступность другого.
• Пропускать промежуточную проверку и сразу переходить к диагностике готового Application. Пошаговая верификация (Module → PackageRepository → Application) экономит время, точно локализуя, на каком шаге реально возникла проблема.

Практика в кластере

Повторите полный сценарий из теории в вашем практическом кластере (M0 урок 3):

1. Настройте ModuleSource+ModuleConfig для managed-postgres (используйте актуальный источник, доступный вашему CE-кластеру, или тестовый модуль-заглушку, если полноценный managed-postgres недоступен в вашей сборке — упражнение имеет смысл даже с упрощённым модулем для отработки самого сценария).

2. Настройте PackageRepository, указывающий на тестовый registry с опубликованным пакетом pgadmin (или подготовленным вами аналогом на основе структуры из M5).

3. Установите Application pgadmin и пройдите весь путь с промежуточной проверкой на каждом шаге, как описано в теории.

4. Смоделируйте разрыв зависимости: отключите managed-postgres после того, как pgadmin уже был Ready, и понаблюдайте за переходом в Not Ready:

1
2

d8 k patch moduleconfig managed-postgres --type=merge -p '{"spec":{"enabled":false}}'
d8 k get app pgadmin -n team-alpha -w

Практика разработки

Практики разработки в этом уроке нет — фокус на сквозном сценарии эксплуатации уже готового пакета, использующего зависимость от Module.

Шпаргалка команд урока

1
2
3
4
5
6
7

d8 k get modulesource
d8 k get moduleconfig <name> [-o yaml]
d8 k get module <name> -o jsonpath='{.status.phase}'
d8 k get packagerepository
d8 k get applicationpackage <name> -o yaml
d8 k get applicationpackageversion
d8 k get app <name> -n <ns> -o jsonpath='{.status.summary}'

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• Deckhouse — Package repository
• Deckhouse — Зависимости Module

Статьи и блоги

• Разворачиваем приложение в кластере Kubernetes под управлением Deckhouse c помощью werf — Flant на Habr.
• Вышла werf 2.0: новый движок развёртывания Nelm — Flant на Habr.
• Готовим Gitea со вкусом werf CI/CD в кластере Deckhouse. Часть 3 — Flant на Habr.

Книги

• Michael Hausenblas, Stefan Schimanski. Programming Kubernetes. 2019. ISBN 978-1492047107.

Связанные материалы

• Предыдущий урок: M6.01 — requirements.modules.mandatory целиком.
• Следующий урок: M6.03 — Два обязательных модуля одновременно.

✓ Урок пройден — все вопросы самопроверки отвечены верно