requirements.modules.mandatory целиком

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

M5 урок 2 — синтаксис requirements.modules.mandatory в package.yaml. M5 урок 5 — Application может зависеть только от Module, не от другого Application. Здесь — что конкретно происходит при попытке установить Application, чей mandatory-модуль отсутствует или выключен.

Теория

Как объявляется зависимость

1
2
3
4
5
6

# package.yaml
requirements:
  modules:
    mandatory:
      - name: managed-postgres
        constraint: ">= 1.0.0"

mandatory — список Module, обязательных для функционирования пакета (в отличие от опциональных зависимостей, которые в модели Module могут расширять функциональность без блокировки при отсутствии, см. Module Requirements из M2 урока 3). Для Application-пакета все mandatory-зависимости — жёсткое условие: без них платформа не позволит перейти в состояние Ready.

Проверка ДО установки Application

Deckhouse проверяет наличие и версию каждого mandatory-модуля до того, как Application перейдёт в состояние Installed. Последовательность:

Что видит пользователь при отсутствующей зависимости

1

d8 k get app my-umami -n team-alpha -o jsonpath='{.status.conditions}'

1
2
3
4
5
6
7
8

- type: Installed
  status: "False"
  reason: InstallFailed
  message: "Required module 'managed-postgres' is not enabled in the cluster"
- type: Ready
  status: "False"
  reason: NotReady
  message: "Application is not ready: Installed condition is False"

reason здесь — общий для любой причины провала установки (InstallFailed, единственный официально задокументированный reason для проваленного Installed, см. Troubleshooting Application), а вот message прямо называет отсутствующий модуль — это позволяет администратору или разработчику Application мгновенно понять, что нужно сделать (включить managed-postgres через ModuleConfig, M2 урок 3), не копаясь в логах контроллера.

Связь с диагностической цепочкой M5 урока 10

Это прямое расширение статусной модели из M5 урока 10: Installed=False из-за отсутствующей зависимости — это конкретный, частый в реальности пример причины, по которой Installed (а следовательно, и Ready) не проходит. Диагностика по-прежнему идёт «сверху вниз» по цепочке conditions, но теперь у вас есть конкретный сценарий, который стоит проверять в первую очередь при работе с Application, у которого объявлены mandatory-зависимости.

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

• Диагностировать проблему исключительно в Application-пакете, не проверив статус зависимого Module. Если Installed=False, reason=InstallFailed, а message называет отсутствующий/невключённый модуль — проблема физически не в вашем пакете, а в платформенной зависимости (M2 урок 3).
• Указывать слишком широкий или, наоборот, слишком узкий constraint. Например, constraint: ">= 0.0.0" фактически отключает проверку версии, теряя защиту от несовместимых версий модуля; излишне узкий constraint (= 1.0.0) делает пакет хрупким к любому патч-обновлению зависимого модуля.
• Забыть, что зависимость проверяется и при последующих обновлениях, не только при первой установке. Если администратор впоследствии отключит managed-postgres, уже установленный Application также перейдёт в Not Ready — зависимость проверяется непрерывно, а не только в момент kubectl apply.

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

1. Убедитесь, что managed-postgres (или любой другой mandatory-модуль вашего пакета Umami) выключен в тестовом кластере, и установите Application:

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

d8 k get moduleconfig managed-postgres -o jsonpath='{.spec.enabled}'; echo
d8 k apply -n course-m6-umami -f - <<'EOF'
apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: umami-dep-demo
spec:
  packageName: umami
  packageRepositoryName: my-registry
  packageVersion: "v0.1.0"
  settings:
    hostname: "umami-dep-demo.local"
EOF

2. Изучите статус и убедитесь, что причина явно названа:

1

d8 k get app umami-dep-demo -n course-m6-umami -o jsonpath='{.status.conditions}' | jq

3. Включите модуль и понаблюдайте за переходом в Installed=True:

1
2

d8 k patch moduleconfig managed-postgres --type=merge -p '{"spec":{"enabled":true}}'
d8 k get app umami-dep-demo -n course-m6-umami -w

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

Добавьте requirements.modules.mandatory в package.yaml Umami (продолжение работы из M5), если ещё не сделано:

1
2
3
4
5

requirements:
  modules:
    mandatory:
      - name: managed-postgres
        constraint: ">= 1.0.0"

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

1
2

d8 k get moduleconfig <module-name> -o jsonpath='{.spec.enabled}'
d8 k get app <name> -n <ns> -o jsonpath='{.status.conditions}'

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

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

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

• Deckhouse — Разработка Application-пакета
• Deckhouse — Зависимости Module
• Deckhouse — Troubleshooting Application

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

• Разворачиваем приложение в кластере 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.

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

• Предыдущий модуль: M5.10 — Статусная модель Application целиком.
• Следующий урок: M6.02 — pgadmin + managed-postgres целиком.

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