CRD платформы вокруг Application

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

M2 урок 3 — общая статусная модель платформы (conditions/status.summary) и объекты PackageRepository/PackageRepositoryOperation. Здесь — полная картина всех пяти CRD marketplace-модели платформы и как они связаны друг с другом.

Теория

Пять CRD полной resource-модели marketplace

Только Application — namespace-scoped; все остальные четыре CRD существуют на уровне кластера, т.к. они описывают доступные для установки пакеты (аналог каталога), не привязанные к какому-то конкретному namespace до момента реальной установки конкретным пользователем.

Разбор потока данных

1. Администратор создаёт PackageRepository, указывая адрес registry и расписание сканирования.
2. PackageRepository инициирует PackageRepositoryOperation — платформа сканирует registry на наличие пакетов/версий.
3. Результат сканирования — набор ApplicationPackageVersion, каждая описывает одну конкретную версию одного пакета: метаданные из его package.yaml, а также сами OpenAPI v3-схемы (status.packageSchemas.settingsSchema/valuesSchema), извлечённые платформой из релиз-образа пакета — именно по ним затем валидируются пользовательские настройки и effective-values.
4. Все версии одного и того же пакета агрегируются в единый ApplicationPackage — именно этот объект видит пользователь в каталоге marketplace как «одна карточка приложения» с выбором версии.
5. Когда пользователь решает установить конкретную версию — он создаёт Application в своём namespace, ссылаясь на конкретный ApplicationPackageVersion (через имя пакета и версию в spec); платформа валидирует spec.settings по settingsSchema из этой ApplicationPackageVersion, и только после успешной валидации Nelm (M4) реально разворачивает ресурсы в кластере.

Application CRD — полная схема

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

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: applications.deckhouse.io
spec:
  group: deckhouse.io
  names:
    kind: Application
    plural: applications
    singular: application
    shortNames:
      - app
  scope: Namespaced
  versions:
    - name: v1alpha1
      served: true
      storage: true

shortName: app — то, что позволяет писать сокращённо d8 k get app вместо полного d8 k get application (аналог po для pod, deploy для deployment из M1). Реальный пример объекта:

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

apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: umami-analytics
  namespace: team-alpha
spec:
  packageName: umami
  packageRepositoryName: my-registry
  packageVersion: "v1.0.1"
  settings:
    hostname: "analytics.example.com"
    replicas: 2

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

• Пытаться установить Application, указав несуществующую или не просканированную версию в packageVersion. Без соответствующего ApplicationPackageVersion, обнаруженного через PackageRepositoryOperation, платформа не сможет разрешить установку — сначала должно пройти сканирование registry.
• Путать ApplicationPackage (агрегат по всем версиям) с ApplicationPackageVersion (конкретная версия). Первый — это «карточка в каталоге», второй — «конкретный устанавливаемый релиз» этой карточки.
• Ожидать, что PackageRepository/ApplicationPackage/ApplicationPackageVersion можно создать в конкретном namespace. Это cluster-scoped ресурсы — единственный namespace-scoped объект в этой пятёрке — сам Application.
• Не находить эти CRD в старом кластере и списывать это на ошибку конфигурации. Marketplace-модель (все пять CRD) требует минимальной версии платформы, начиная с которой она появилась в DKP — если d8 k get crd | grep -E 'application|package' не находит их, вероятная причина именно в версии платформы, а не в настройках.

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

1. Изучите все пять CRD через d8 k explain:

1
2
3
4
5

d8 k explain packagerepository
d8 k explain packagerepositoryoperation
d8 k explain applicationpackageversion
d8 k explain applicationpackage
d8 k explain application

2. Если у вас настроен тестовый PackageRepository (из предыдущих модулей или созданный для практики курса), изучите цепочку от репозитория до конкретной версии:

1
2
3
4

d8 k get packagerepository -o yaml
d8 k get packagerepositoryoperation
d8 k get applicationpackageversion | grep umami
d8 k get applicationpackage umami -o yaml

3. Создайте Application для Umami (используя пакет, собранный и опубликованный в предыдущих уроках, или заготовку для проверки синтаксиса):

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

d8 k apply -n course-m5-umami -f - <<'EOF'
apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: umami-analytics
spec:
  packageName: umami
  packageRepositoryName: my-registry
  packageVersion: "v0.1.0"
  settings:
    hostname: "umami.local"
    replicas: 1
EOF
d8 k get app -n course-m5-umami

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

Практики разработки в этом уроке нет — фокус на изучении CRD как готовой платформенной модели.

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

1
2
3
4
5

d8 k get packagerepository|packagerepositoryoperation|applicationpackageversion|applicationpackage|application [-o yaml]
d8 k get app -n <ns>       # shortName Application
d8 k get apv               # shortName ApplicationPackageVersion
d8 k get pro               # shortName PackageRepositoryOperation
d8 k explain <crd-name>

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

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

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

• Deckhouse — Application и Module: концепции
• Deckhouse — Справочник CRD платформы

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

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

Книги

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

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

• Предыдущий урок: M5.05 — Ограничения Application.
• Следующий урок: M5.07 — Множественные инстансы одного пакета.
• Общая статусная модель платформы: M2 урок 3.

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