Module как зависимость Application

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

M2 урок 1 — Module — cluster-wide инфраструктура. Здесь мы разбираем объекты, через которые Module появляется в кластере и становится доступен как зависимость Application (сам механизм requirements.modules.mandatory со стороны Application — в M6, здесь — только объекты и статусная модель со стороны платформы).

Теория

ModuleSource и ModuleConfig

ModuleSource — cluster-scoped объект, описывающий откуда платформа берёт модули (адрес registry, авторизация, release channel источника). ModuleConfig — конфигурация конкретного модуля: включён/выключен, какие настройки у него заданы.

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

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:
    # специфичные для конкретного модуля настройки

PackageRepository/PackageRepositoryOperation

PackageRepository — cluster-scoped источник Package (может быть источником и для Module, и для Application) — именно этот объект отвечает за появление в кластере конкретных версий, которые можно установить (через ApplicationPackageVersion для Application, разбирается детально в M5 уроке 6). PackageRepositoryOperation фиксирует конкретную операцию синхронизации с реальным registry (аналог «джобы» на скачивание метаданных).

Единая статусная модель Deckhouse-объектов

Практически все CRD платформы (и Module, и Application, и объекты вокруг них) используют единую модель статуса:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

status:
  conditions:
    - type: Ready
      status: "True"
      reason: "AllComponentsReady"
      lastTransitionTime: "2026-06-01T10:00:00Z"
  summary:
    state: "Ready" # человекочитаемое агрегированное состояние
    message: "Модуль работает штатно"
    tip: "" # подсказка, что делать, если state не Ready

status.conditions — детальный, машинно-читаемый список условий (аналог conditions у Deployment/Pod из M1, тот же паттерн Kubernetes API); status.summary.{state,message,tip} — упрощённая, человекочитаемая сводка специфичная для платформы Deckhouse (в чистом Kubernetes такого поля нет) — именно tip часто прямо подсказывает следующий диагностический шаг. Мы вернёмся к этому полю подробно для Application в M5 уроке 10 и для troubleshooting в целом — в M10 уроке 10.

Troubleshooting обеих сторон зависимости

Если ваш Application зависит от Module (полностью — M6), диагностика проблемы требует проверки обеих сторон:

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

• Диагностировать только Application, не проверив, включён ли зависимый Module. Если requirements.modules.mandatory указывает на выключенный/отсутствующий Module — проблема физически не в вашем Application, а в отсутствующей зависимости платформы.
• Путать ModuleSource (откуда брать) с ModuleConfig (как настроить уже присутствующий модуль). Без ModuleSource модуль физически не появится в списке доступных для включения.
• Игнорировать status.summary.tip. Это специально предназначенное поле-подсказка платформы — часто самый быстрый путь к решению, быстрее, чем разбор всех conditions вручную.

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

1
2
3
4
5

d8 k get modulesource
d8 k get moduleconfig
d8 k get moduleconfig ingress-nginx -o yaml
d8 k get module ingress-nginx -o jsonpath='{.status.summary}'; echo
d8 k get packagerepository 2>/dev/null || echo "появится начиная с установки первого Application-пакета — см. M5"

Смоделируйте выключение модуля и посмотрите на изменение статусной модели (используйте некритичный для вашего курса модуль, не ломайте ingress-nginx, если он используется другими уроками):

1

d8 k get moduleconfig -o custom-columns=NAME:.metadata.name,ENABLED:.spec.enabled

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

В этом уроке нет собственной сборки — это обзор платформенных объектов зависимостей.

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

1
2
3
4

d8 k get modulesource
d8 k get moduleconfig [<name>] [-o yaml]
d8 k get module <name> -o jsonpath='{.status.summary}'
d8 k get packagerepository

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

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

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

• Deckhouse — Справочник CRD платформы
• Deckhouse — Работа с Application

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

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

Книги

• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

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

• Предыдущий урок: M2.02 — Как устроен Deckhouse изнутри.
• Следующий урок: M2.04 — Компоненты и линтеры платформы.
• Полный практический пример зависимости: M6 урок 2 — pgadmin + managed-postgres.

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