Troubleshooting по статусной модели

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

M5 урок 10 — полная статусная модель Application. Этот заключительный урок модуля M10 формализует общий алгоритм диагностики проблем в production и проясняет роль Upmeter.

Теория

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."

Как разобрано в M5 уроке 10, status.summary — это спроектированная как первая точка входа диагностики агрегированная сводка: state (машиночитаемое состояние), message (объяснение причины текущего состояния для человека), tip (конкретная подсказка о том, что нужно сделать или чего ожидает система). В примере выше видно, что Deckhouse осознанно ожидает готовности зависимых Module (M6), сохраняя предыдущую рабочую версию приложения в работе — это не ошибка, а штатное, безопасное поведение процесса обновления.

Общий алгоритм диагностики: от общего к частному

Систематический подход, применимый к подавляющему большинству проблем Application в production:

1. status.summary.tip — первый шаг: часто здесь уже содержится точный ответ на вопрос «что делать дальше» без необходимости идти глубже.
2. status.conditions (M5 урок 10) — если tip недостаточно конкретен, разбор шести условий (Installed, UpdateInstalled, ConfigurationApplied, Scaled, Managed, Ready) построчно — какое из них False, и что говорит его reason/message.
3. Логи целевого пода — если условия указывают, что ресурсы созданы, но приложение не готово (Ready: False, но Installed: True) — переход к d8 k logs конкретного контейнера, потенциально с log-regex-фильтрацией (M7 урок 5) для выделения релевантной части.
4. События кластера (d8 k get events) — если логи самого контейнера не проясняют ситуацию (например, под вообще не запускается) — события часто содержат информацию уровнем ниже приложения: FailedScheduling, ImagePullBackOff, FailedMount (для PVC), недоступную ни в status.summary, ни в логах контейнера, который ещё не успел запуститься.

Upmeter — SLA всего кластера, а не мониторинг конкретного Application

Ключевое разграничение уровней ответственности, завершающее логику модуля M10: Upmeter — это модуль Deckhouse, измеряющий доступность самого кластера как инфраструктуры — проб control-plane (доступность API-сервера, планировщика и т.д.) и smoke-mini (пять StatefulSet с периодической миграцией между узлами, проверяющих сетевую связность между узлами и обнаруживающих сетевые разделения/проблемы маршрутизации). Upmeter отправляет порядка ста показаний метрик каждые пять минут, формируя агрегированный показатель SLA кластера.

Важно не путать уровни ответственности: Upmeter отвечает на вопрос «жив ли кластер как инфраструктура в целом?», а не «работает ли конкретное Application-приложение прямо сейчас?». Мониторинг конкретного Application — это PodMonitor/Probe/алерты, разобранные в M10 уроках 1–2, полностью независимые от Upmeter. Здоровый Upmeter (100% SLA кластера) не гарантирует, что конкретное приложение работает корректно — приложение может упасть из-за собственной ошибки конфигурации при полностью здоровой инфраструктуре кластера, и наоборот.

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

• Начинать диагностику сразу с логов контейнера, пропуская status.summary. tip часто уже содержит точный ответ значительно быстрее, чем анализ сырых логов — алгоритм «от общего к частному» экономит время диагностики.
• Интерпретировать state: Updating как ошибку. Как показывает пример из теории, это может быть штатным, ожидаемым состоянием (ожидание готовности зависимостей), а не проблемой, требующей вмешательства.
• Путать Upmeter с инструментом диагностики конкретного приложения. Проверка «здоров ли Upmeter» не заменяет проверку status.summary/PodMonitor конкретного Application — это ответы на принципиально разные вопросы разных уровней стека.
• Игнорировать события кластера (d8 k get events) при проблемах на этапе, предшествующем запуску контейнера. Логи контейнера просто не существуют, если под ещё не смог запуститься — единственный источник диагностической информации в этом случае — события.

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

1
2
3
4

d8 k get application umami -n course-m10-umami -o jsonpath='{.status.summary}' | jq
d8 k get application umami -n course-m10-umami -o jsonpath='{.status.conditions}' | jq
d8 k get events -n course-m10-umami --sort-by='.lastTimestamp'
d8 k get statefulset -n d8-upmeter | grep smoke-mini

Смоделируйте намеренную проблему (например, некорректный образ в values.yaml) и пройдите весь алгоритм диагностики из теории построчно, от status.summary.tip до событий кластера, документируя каждый шаг.

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

Составьте для пакета Umami итоговую страницу документации docs/troubleshooting.md, формализующую типичные проблемные сценарии (недоступность зависимого Module, нехватка ресурсов, ошибка конфигурации) с соответствующими tip-сообщениями и шагами диагностики — это финальная веха перед переходом к капстоуну M11.

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

1
2
3
4

d8 k get application <name> -n <namespace> -o jsonpath='{.status.summary}'
d8 k get application <name> -n <namespace> -o jsonpath='{.status.conditions}'
d8 k get events -n <namespace> --sort-by='.lastTimestamp'
d8 k logs <pod> -n <namespace> --previous   # логи предыдущего (упавшего) экземпляра контейнера

Полная сводная таблица kubectl/d8 k — 📋 kubectl .

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

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

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

• Deckhouse — Troubleshooting Application
• Deckhouse — Работа с Application
• Deckhouse — Мониторинг (админ)

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

• Deckhouse Prom++: оптимизация Prometheus — Flant на Habr.
• Deckhouse Prom++: как мы посадили Prometheus на RAM-диету — Flant на Habr.
• Kubernetes на базе Deckhouse: встроенный мониторинг и логирование — обзор возможностей DKP на Habr.

Книги

• Brendan Burns, David Oppenheimer. Designing Distributed Systems. 2018. ISBN 978-1491983645.
• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

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

• Предыдущий урок: M10.09 — Security для Application.
• Следующий модуль: M11 — Капстоун.

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