Статусная модель Application целиком

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

M2 урок 3 — общая модель conditions/status.summary.{state,message,tip} платформы. M5 урок 8 — как settingscheck влияет на ConfigurationApplied. Здесь — полная, финальная картина всех condition Application и практика обновления/отката.

Теория

Все шесть conditions Application

Ready — это не независимое условие, а следствие всех остальных: приложение готово, только если установлено/обновлено, настройки применены, все реплики масштабированы и платформа корректно управляет объектом. Такая иерархия conditions напоминает уже знакомую логику из M1 урока 2 (готовность Deployment зависит от готовности его Pod‘ов через ReplicaSet) — только на уровне модели Application, а не голого Kubernetes.

status.summary — практический пример

1
2
3
4
5

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: Updating — понятное человеку состояние; message — точная причина, почему обновление не завершилось мгновенно (ожидание согласования зависимых Module — прямая связь с M6, где requirements.modules.mandatory может тормозить обновление, если зависимый Module сам находится в процессе изменения); tip — прямая инструкция, что происходит и что делать (в данном случае — просто подождать, вмешательство не требуется). Также обратите внимание на важную деталь UX: предыдущая версия продолжает обслуживать трафик, пока обновление не завершится — обновление Application не означает мгновенный простой.

Troubleshooting по таблице «condition → типичная причина → диагностика»

Диагностика всегда идёт «сверху вниз» по этой цепочке: если Ready = False, не имеет смысла сразу глубоко копать логи контейнеров — сначала проверьте, какое именно из предыдущих условий (Installed/ConfigurationApplied/Scaled/Managed) стало причиной, и уже затем переходите к специфичной для этого условия диагностике.

Обновление: d8 k patch

1

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

Обновление Application — всегда ручное: изменение spec.packageVersion (напрямую через patch, edit или переприменением полного манифеста с новым значением) инициирует переход. Во время обновления UpdateInstalled временно False с reason: Pending — это нормальное промежуточное состояние, а не ошибка (см. таблицу выше). Если указанная версия не существует — UpdateInstalled станет False с reason: UpdateFailed, но текущая (предыдущая) версия остаётся активной и продолжает работать — неудачное обновление не приводит к простою уже работающего приложения.

Откат: разрешён, но без автоматических миграций

Даунгрейд (откат на более старую packageVersion) технически разрешён тем же механизмом patch spec.packageVersion — но DKP не предоставляет автоматической логики миграции данных при откате. Если ваше приложение хранит состояние в БД (как Umami — веб-аналитика с PostgreSQL) и новая версия вносила несовместимые изменения схемы данных, откат на Kubernetes-уровне (снова тот же образ/чарт) не отменяет уже применённые изменения схемы — ответственность за обратную совместимость данных или ручные шаги миграции при откате лежит полностью на разработчике пакета, а не на платформе.

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

• Паниковать при виде UpdateInstalled: False, reason: Pending во время обновления. Это ожидаемое промежуточное состояние, особенно если у пакета есть requirements.modules.mandatory — platform ждёт согласования зависимых модулей, а не сообщает об ошибке.
• Начинать диагностику с чтения логов контейнеров вместо проверки цепочки conditions. Правильный порядок — сверху вниз по иерархии Installed/ConfigurationApplied/Scaled/Managed/Ready, находя первое False-условие, и только затем углубляться в специфичную для него диагностику.
• Ожидать автоматической миграции данных при откате версии. Откат меняет только версию развёрнутого пакета (образы/чарт), но не откатывает изменения, уже внесённые в персистентные данные (БД, файлы) — это ответственность разработчика пакета, которую нужно явно продумывать и документировать.

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

1. Установите Umami (используя пакет, собранный в M5 уроке 9) и понаблюдайте за прохождением всех условий последовательно:

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

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

d8 k get app umami-status-demo -n course-m5-umami -w

2. После перехода в Ready, изучите полный статус:

1
2

d8 k get app umami-status-demo -n course-m5-umami -o jsonpath='{.status.conditions}' | jq
d8 k get app umami-status-demo -n course-m5-umami -o jsonpath='{.status.summary}'; echo

3. Выполните обновление на новую версию (собранную аналогично v0.1.1 в M5 уроке 9) и понаблюдайте за UpdateInstalled:

1
2

d8 k patch app -n course-m5-umami umami-status-demo --type=merge -p '{"spec":{"packageVersion":"v0.1.1"}}'
d8 k get app umami-status-demo -n course-m5-umami -w

4. Смоделируйте ошибку обновления, указав несуществующую версию, и убедитесь, что предыдущая версия продолжает работать:

1
2
3

d8 k patch app -n course-m5-umami umami-status-demo --type=merge -p '{"spec":{"packageVersion":"v99.99.99"}}'
d8 k get app umami-status-demo -n course-m5-umami -o jsonpath='{.status.conditions[?(@.type=="UpdateInstalled")]}'
d8 k get pods -n course-m5-umami   # убедитесь, что старые Pod'ы всё ещё Running

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

Практики разработки в этом уроке нет — это финальная практика наблюдения за статусной моделью уже собранного и опубликованного в предыдущих уроках M5 пакета.

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

1
2
3
4

d8 k get app <name> -n <ns> -w
d8 k get app <name> -n <ns> -o jsonpath='{.status.conditions}'
d8 k get app <name> -n <ns> -o jsonpath='{.status.summary}'
d8 k patch app -n <ns> <name> --type=merge -p '{"spec":{"packageVersion":"<version>"}}'

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

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

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

• Deckhouse — Работа с Application
• Deckhouse — Troubleshooting Application

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

• Разворачиваем приложение в кластере 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.09 — Жизненный цикл через d8 package.
• Следующий модуль: M6 — Application ↔ Module ↔ K8s: связи и зависимости, урок 1 — requirements.modules.mandatory целиком.
• Общая статусная модель платформы: M2 урок 3.
• Общий troubleshooting: M10 урок 10.

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