Отладка при неудачном деплое в Kubernetes c Helm Hook в GitLab CI
Используемое ПО: Gitlab CI, Helm, Docker, Kubernetes
Цель: в случае неудачного деплоя, получить информацию о проблеме в CI, а не ходить в k8s или Kibana руками и не смотреть логи подов
Вводная: для деплоя в кластер Kubernetes используется Helm версии 3 и Gitlab CI, отдельный сервер для сборки (не DinD), с которого доступен Kubernetes API. Данный вариант основан на ключе Helm --atomic, который осуществляет автоматический откат неудавшегося релиза. Идея в том, чтобы не запускать отдельно helm rollback, а использовать Hook с аннотацией pre-delete, которая перед удалением релиза запустит под и соберет логи с NOT READY подов, а далее с помощью after_script выведет данные логи в CI.
К реализации...
Helm 3 использует реквизиты подключения kubectl, соответственно Helm hook должен будет иметь следующие права Service Account в своем namespace:
kubelogin.sh - выполняем логин в кластер с токеном Service Account
hooklog.sh - запускаем выборку всех подов в состоянии NOT READY, берем первый под и выводим его логи
Собранный образ, готовый к работе: https://hub.docker.com/r/sfnagg/k8s-helm-logs
Helm hook создается в каталоге templates, для запуска ничего более не требуется, так как при ключе --atomic происходит именно удаление релиза, а не rollback, нужно использовать аннотацию "helm.sh/hook": pre-delete
Документация по хукам Helm: https://helm.sh/docs/topics/charts_hooks/
Пример деплоя Gitlab CI
Комментарии: в примере приведен деплой с gitlab-runner executor shell, правильнее использовать docker в этом варианте, но я решил показать более сложный вариант, возможно пригодится в других ситуациях. Переменная --timeout в продакшене обычно устанавливается от 100 до 300 секунд.
K8S_API_URL - Kubernetes API (kubectl get ep kubernetes)
K8S_CI_TOKEN - это токен Service Account, который хранится в переменных Gitlab