Tracking-аннотации: как Nelm ждёт готовности

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

M7 урок 3 — модель Apply-стадии. M1 урок 6 — Probes, готовность которых отслеживают tracking-аннотации. Этот урок разбирает все аннотации, управляющие тем, как долго и как именно Nelm ждёт готовности ресурсов на Apply.

Теория

werf.io/track-termination-mode — блокирует ли ресурс весь деплой

Значения: WaitUntilResourceReady (по умолчанию — Nelm ждёт полной готовности ресурса перед тем, как считать шаг DAG завершённым) и NonBlocking (Nelm запускает создание ресурса, но не блокирует остальной процесс деплоя ожиданием его готовности).

werf.io/fail-mode — что делать при неудаче

Значения: FailWholeDeployProcessImmediately (по умолчанию — любая неудача немедленно проваливает весь деплой) и IgnoreAndContinueDeployProcess (неудача этого конкретного ресурса не блокирует остальной процесс).

Комбинация для некритичных компонентов

1
2
3
4
5
6
7
8

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: {{.Application.Instance.Name}}-metrics-agent
  annotations:
    werf.io/fail-mode: IgnoreAndContinueDeployProcess
    werf.io/track-termination-mode: NonBlocking
spec: ...

Классический use case — вспомогательный компонент вроде агента сбора метрик: его неготовность или сбой не должны блокировать весь релиз, поэтому обе аннотации ослабляют дефолтное строгое поведение Nelm.

werf.io/failures-allowed-per-replica и werf.io/no-activity-timeout

1
2
3
4
5
6
7
8
9

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: elasticsearch
  annotations:
    werf.io/no-activity-timeout: 20m
    werf.io/failures-allowed-per-replica: "3"
    werf.io/show-service-messages: "true"
spec: ...

no-activity-timeout — продлевает окно ожидания готовности для ресурсов с длительным стартом (медленная загрузка большого образа, долгая инициализация StatefulSet вроде Elasticsearch). failures-allowed-per-replica — допускает указанное число рестартов на реплику, прежде чем Nelm посчитает деплой проваленным (полезно, если приложение при старте естественным образом падает N раз, ожидая готовности зависимостей, прежде чем стабилизироваться). show-service-messages — включает вывод Kubernetes Events рядом с логами контейнеров в вывод команды деплоя, что критично для диагностики сложных сценариев старта.

Сводная таблица дефолтов

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

• Использовать NonBlocking для критичных компонентов (например, основной базы данных). Это уберёт гарантию, что деплой дождётся готовности БД, прежде чем перейти к следующему шагу — крайне опасно для ресурсов, от которых реально зависит остальное приложение.
• Не увеличивать no-activity-timeout для StatefulSet с большими образами. Дефолтный таймаут может быть недостаточным для реального времени старта — деплой будет ошибочно считаться проваленным при том, что приложение просто ещё загружается.
• Игнорировать show-service-messages при отладке зависших деплоев. Без этой аннотации вывод Nelm может не содержать критичную информацию из Kubernetes Events (например, FailedScheduling, ImagePullBackOff), что сильно затрудняет диагностику.

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

1
2
3
4

d8 k annotate deployment umami-metrics-agent -n course-m6-umami \
  werf.io/fail-mode=IgnoreAndContinueDeployProcess \
  werf.io/track-termination-mode=NonBlocking --overwrite
nelm release install -n course-m6-umami -r umami .

Смоделируйте намеренный сбой некритичного компонента (например, укажите несуществующий образ для вспомогательного DaemonSet) и убедитесь, что при указанных аннотациях основной деплой всё равно завершается успешно.

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

Добавьте werf.io/no-activity-timeout: 10m и werf.io/show-service-messages: "true" к главному Deployment Umami для более комфортной диагностики в CI, где типовые таймауты часто слишком малы для холодного старта контейнеров.

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

Полная таблица tracking-аннотаций — 📋 nelm .

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

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

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

• Deckhouse — Nelm-аннотации для Application

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

• Вышла werf 2.0: новый движок развёртывания Nelm — Flant на Habr.
• Представляем werf 1.0 stable: GitOps и Helm — Flant на Habr.
• GitLab + K8s + Werf — Habr.

Книги

• Matt Butcher, Matt Farina, Josh Dolitsky. Learning Helm. 2019. ISBN 978-1492036781.

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

• Предыдущий урок: M7.03 — Lifecycle-аннотации целиком.
• Следующий урок: M7.05 — Log-аннотации.

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