Просмотр доступных версий пакетов

Для получения списка всех доступных версий пакетов выполните следующую команду (можно использовать сокращённое имя — apv):

d8 k get apv

Пример вывода:

NAME                        PACKAGE   REPOSITORY    TRANSITIONTIME   METADATALOADED   USEDBY
my-registry-redis-v7.2.0    redis     my-registry   2d               True             1
my-registry-redis-v7.3.0    redis     my-registry   5h               True
my-registry-pg-v15.0.0      postgres  my-registry   2d               True             2

Для фильтрации по имени пакета используйте следующую команду (в примере фильтруются версии пакета redis):

d8 k get apv -l package=redis

Для просмотра реестров, в которых доступен пакет, используйте следующую команду (можно использовать сокращённое имя — ap):

d8 k get ap redis \
  -o jsonpath='{.status.availableRepositories}'

Устанавливать можно только версии с MetadataLoaded=True. Это означает, что OpenAPI-схема пакета, описание и требования успешно загружены из реестра. Пакет с MetadataLoaded=False не может быть установлен до получения метаданных.

Установка приложения

Для установки приложения создайте объект Application в нужном неймспейсе.

Пример манифеста для установки Redis из пакета redis версии v7.2.0 с настройкой maxmemory:

apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: redis-cache
  namespace: my-app
spec:
  packageName: redis
  packageVersion: "v7.2.0"
  # Если подключён только один репозиторий с этим пакетом, можно не указывать
  packageRepositoryName: my-registry
  settings:
    replicas: 3
    maxmemory: "256mb"

spec.settings проверяется по OpenAPI-схеме, определённой в пакете. Если схема отклонила настройки, Application не будет создан. Детали схемы можно посмотреть в соответствующем ApplicationPackageVersion.

Ограничения на имена

Имя Application (metadata.name) должно быть не более 24 символов. Это обязательно, поскольку все поды получают префикс из имени экземпляра: 24 символа имени экземпляра + 24 символа имени ресурса + 15 символов суффикса Deployment укладываются в ограничение Kubernetes на имя пода в 63 символа.

Проверка статуса приложения

Для получения краткой информации о статусе приложения выполните (можно использовать сокращённое имя — app):

d8 k get app -n <NAMESPACE> <APPLICATION_NAME>

Пример вывода:

NAME          PACKAGE   VERSION   INSTALLED   READY   MESSAGE
redis-cache   redis     v7.2.0    True        True

Для получения полного статуса, включая условия (conditions), выполните:

d8 k get app -n <NAMESPACE> <APPLICATION_NAME> -o yaml

Условия (Conditions)

Состояние приложения детально описывается через набор условий:

Условие Значение
Installed Пакет скачан, манифесты и хуки применены при первичной установке
UpdateInstalled Новая версия скачана, манифесты и хуки применены при обновлении
ConfigurationApplied Пользовательские настройки успешно применены
Scaled Все реплики подов находятся в состоянии Ready
Managed Приложение корректно управляется DKP
Ready Приложение полностью готово к работе

Для быстрого просмотра всех условий используйте следующую команду:

d8 k get app -n <NAMESPACE> <APPLICATION_NAME> \
  -o jsonpath='{range .status.conditions[*]}{.type}: {.status} ({.reason}){"\n"}{end}'

Пример вывода:

Installed: True (Installed)
UpdateInstalled: False (Pending)
ConfigurationApplied: True (ConfigurationApplied)
Managed: True (Managed)
Scaled: True (Scaled)
Ready: True (Ready)

Summary

Поле status.summary содержит краткое описание текущего состояния приложения — его удобно смотреть в первую очередь при диагностике:

status:
  summary:
    state: Updating
    message: "Update is waiting for dependent modules to converge; previous version is still serving"
    tip: "Waiting until DKP processes all dependent modules to start the update."
  • state — текущее общее состояние приложения.
  • message — объясняет, почему приложение находится в этом состоянии.
  • tip — что нужно сделать для решения проблемы или чего ожидает DKP.

Несколько экземпляров

Один и тот же пакет можно установить несколько раз в одном или разных неймспейсах — каждый с отдельным именем и настройками. Например, можно создать два экземпляра Redis — один для кеширования, другой для сессий:

# Экземпляр для кеширования
apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: redis-cache
  namespace: team-alpha
spec:
  packageName: redis
  packageRepositoryName: my-registry
  packageVersion: "v7.2.0"
  settings:
    maxmemory: "512mb"
---
# Экземпляр для сессий
apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: redis-sessions
  namespace: team-alpha
spec:
  packageName: redis
  packageRepositoryName: my-registry
  packageVersion: "v7.2.0"
  settings:
    maxmemory: "128mb"

Все объекты Kubernetes, создаваемые приложением, получают префикс из имени экземпляра — например, redis-cache-deployment и redis-sessions-deployment — что исключает конфликты имён.

Обновление приложения

Обновление выполняется вручную: измените значение spec.packageVersion на нужную версию и примените изменение:

d8 k patch app -n <NAMESPACE> <APPLICATION_NAME> --type=merge -p '{"spec":{"packageVersion":"v7.3.0"}}'

Пока обновление выполняется, условие UpdateInstalled будет иметь значение False с reason: Pending. После успешного завершения оно станет True. До завершения обновления продолжает работать предыдущая версия.

Если указанная версия не существует в репозитории, UpdateInstalled становится False с reason: UpdateFailed, а текущая версия продолжает работу.

Указание более ранней версии приложения (downgrade) допускается, но DKP не применяет никакую логику миграции при откате. Убедитесь в совместимость настроек с целевой версией перед применением изменения, при необходимости.

Удаление приложения

Для удаления приложения удалите объект Application. Например:

d8 k delete app -n <NAMESPACE> <APPLICATION_NAME>

При удалении Application, все созданные им объекты Kubernetes (если они не защищены аннотациями helm.sh/resource-policy: keep или werf.io/ownership: anyone в шаблонах пакета), будут удалены.

FAQ

Можно ли обновлять приложение автоматически?

Нет. В текущей реализации обновления требуют ручного изменения spec.packageVersion. Автоматические обновления через release channels запланированы на будущие версии.

Может ли Application зависеть от другого Application?

Нет. Application может объявлять зависимости только от модулей (через requirements.modules в package.yaml). Это архитектурное ограничение, обеспечивающее изоляцию экземпляров.

Можно ли установить одно приложение в разных неймспейсах?

Да. Создайте объекты Application с одинаковыми packageName и packageVersion в разных неймспейсах — каждый будет полностью независимым экземпляром.

Дополнительные ресурсы