История, ревизии и статус релиза

Команды-«рентген»: посмотреть, что развёрнуто, в каком статусе и с какими значениями — без догадок.

Helm хранит для каждой ревизии полный снимок: отрендеренные манифесты, итоговые values и метаданные. Команды семейства helm get и helm status достают этот снимок из кластера.

Когда что-то идёт не так, главный навык — быстро восстановить картину: какие релизы есть, в каком они состоянии, что именно в них зашито. Разберём инструменты инспекции.

Важно сразу разделить два вопроса, которые новички часто путают. Первый: «что Helm намеревался развернуть?» — на него отвечают команды этого урока, читающие сохранённые снимки ревизий. Второй: «что фактически сейчас происходит в кластере?» — на него отвечает kubectl, опрашивающий живые объекты и поды. Helm-команды дёшевы и быстры, потому что не трогают рабочую нагрузку: они лишь распаковывают записанный снимок. Поэтому начинать диагностику удобно именно с Helm — получить карту намерения, — а затем спускаться к kubectl за фактами о конкретных подах. Расхождение между этими двумя картинами почти всегда и есть корень проблемы.

helm list — обзор всех релизов

helm list -n demo                 # релизы в namespace
helm list --all-namespaces        # по всему кластеру
helm list --all -n demo           # включая failed/uninstalled
helm list --pending -n demo       # зависшие в pending

Колонка STATUS — первое, на что смотреть. Возможные значения: deployed (норма), failed (апгрейд упал), pending-install/pending-upgrade (операция не завершилась — часто признак зависшего хука или недоступного образа).

По умолчанию helm list прячет всё, что не находится в нормальном состоянии: удалённые релизы с сохранённой историей и зависшие операции не показываются, пока вы не добавите --all. Это сделано ради чистого вывода в повседневной работе, но именно из-за этого диагностика без флага бывает обманчивой. Полезная привычка при разборе инцидента — сразу звать helm list --all --all-namespaces: так вы увидите полную картину по всему кластеру, включая релизы в чужих namespace и те, что застряли в pending. Вывод этой команды легко прогнать через стандартные фильтры или попросить в JSON через -o json, чтобы скормить скрипту мониторинга.

helm status — детали одного релиза

helm status my-web -n demo
helm status my-web -n demo --revision 2   # статус конкретной ревизии

status показывает текущую ревизию, время последнего деплоя, статус и NOTES — текстовую подсказку из чарта (например, как достучаться до сервиса). NOTES рендерятся из шаблона templates/NOTES.txt.

Особенно ценен флаг --revision: он позволяет посмотреть статус не текущей, а любой прошлой ревизии. Это незаменимо, когда нужно понять, в каком состоянии релиз был на момент конкретного апгрейда, — например, чтобы решить, на какую именно ревизию откатываться. NOTES, кстати, стоит читать не только при первой установке: авторы хороших чартов кладут туда команды для проверки здоровья, шаблоны строк подключения и предупреждения о ручных шагах после апгрейда. Если после установки база «недоступна», первым делом перечитайте NOTES — часто ответ уже там.

helm history — лента ревизий

helm history my-web -n demo

Вывод:

REVISION	UPDATED                 	STATUS    	CHART       	APP VERSION	DESCRIPTION
1       	Mon Jan  8 10:00:00 2024	superseded	nginx-15.4.1	1.25.2     	Install complete
2       	Mon Jan  8 11:30:00 2024	superseded	nginx-15.4.2	1.25.3     	Upgrade complete
3       	Mon Jan  8 12:15:00 2024	deployed  	nginx-15.4.2	1.25.3     	Rollback to 1

Колонка DESCRIPTION кратко поясняет каждое событие. Это карта для отката: видно, на какую ревизию имеет смысл откатиться.

Читать историю стоит как короткий рассказ о жизни релиза. Статус superseded означает «эта ревизия была актуальной, но её сменила следующая» — это нормальное прошлое, а не ошибка. Ровно одна ревизия в любой момент имеет статус deployed — это та, что сейчас «у руля». Если же в ленте мелькает failed, вы видите точку, где апгрейд не удался, и понимаете, какая предыдущая ревизия была последней рабочей. Имейте в виду, что Helm по умолчанию хранит ограниченное число последних ревизий (управляется флагом --history-max у апгрейда), поэтому очень старые ревизии со временем вытесняются — рассчитывать на бесконечную ленту не стоит.

helm get — точное содержимое ревизии

Самое мощное семейство для отладки. Оно достаёт сохранённый снимок:

helm get values my-web -n demo                  # итоговые values
helm get values my-web -n demo --revision 2     # values конкретной ревизии
helm get manifest my-web -n demo                # отрендеренные манифесты
helm get hooks my-web -n demo                   # хуки релиза
helm get notes my-web -n demo                   # текст NOTES
helm get all my-web -n demo                     # всё сразу

helm get manifest отвечает на вопрос «а что РЕАЛЬНО лежит в кластере от этого релиза». Если кто-то правил ресурсы руками, сравнение helm get manifest с kubectl get -o yaml покажет расхождение.

Связка helm get values --revision и helm get manifest --revision превращает инспекцию в полноценное расследование. Допустим, релиз внезапно сломался после апгрейда с ревизии 2 на ревизию 3. Вы вытаскиваете values обеих ревизий, прогоняете их через diff и мгновенно видите, какое именно значение изменилось и спровоцировало проблему. Это гораздо точнее, чем гадать по логам подов. По сути, история ревизий Helm даёт вам построчный «git blame» для развёрнутой инфраструктуры, и команды get — способ его читать.

Когда релиз «застрял»

Отдельно стоит разобрать статус pending-upgrade, потому что он блокирует дальнейшую работу. Если процесс Helm прервали в момент апгрейда (упал CI-раннер, потеряли соединение), запись о ревизии остаётся в подвешенном состоянии, и следующий upgrade откажется работать со словами вроде «another operation is in progress». Лечится это спокойно: helm history покажет реальную картину, а откат на последнюю заведомо рабочую ревизию через helm rollback обычно выводит релиз из тупика. Понимание, что за статусом стоит просто запись в Secret, а не «магия», снимает страх перед такими ситуациями.

Только заданные пользователем значения

helm get values по умолчанию показывает лишь то, что переопределил пользователь. Чтобы увидеть полную карту с дефолтами чарта, добавьте --all:

helm get values my-web -n demo --all   # дефолты + переопределения

Как это устроено под капотом

Все эти команды не обращаются к живым подам — они читают Secret-снимки ревизий (sh.helm.release.v1.<релиз>.v<N>). Поэтому helm get показывает намерение Helm (что он развернул), а не фактическое состояние подов прямо сейчас. Для фактического состояния используйте kubectl get. Расхождение между «get manifest» и «kubectl get» — главный сигнал ручного дрейфа конфигурации.

Частые ошибки

• Искать релиз не в том namespace. Пустой helm list часто значит «не тот namespace», а не «релизов нет». Пробуйте --all-namespaces.
• Думать, что get values показывает всё. Без --all вы видите только переопределения, дефолты скрыты.
• Игнорировать pending-статус. Релиз в pending-upgrade блокирует следующие операции; обычно виноват зависший хук или недоступный образ.

Итог

• list → обзор и STATUS; status → детали и NOTES; history → лента ревизий для отката.
• helm get manifest/values достаёт точный снимок ревизии — основа отладки.
• Helm показывает своё намерение из Secret-снимков; фактическое состояние подов смотрите через kubectl.