🛠 Кейс из жизни: почему пайплайн деплоя может "висеть" на step'е helm install

Недавно заметил, что пайплайн деплоя зависает на шаге helm install. Логи — тишина. Время ожидания — в никуда. Проблема оказалась интересной и довольно редкой: зависание происходило из-за недоступности webhook'а Kubernetes admission controller'а, а не из-за самого Helm.

Что происходило под капотом:

Helm создаёт ресурсы через kubectl apply, но в кластере был установлен ValidatingWebhookConfiguration, который ожидал ответ от стороннего admission webhook'а. А тот лежал — под был удалён, сервис не восстановился, ingress не поднялся… В итоге API-сервер ждал ответа, который никогда не придёт, и не возвращал ошибку Helm'у.

Решение:

▫️Проверить список webhook'ов:

  kubectl get validatingwebhookconfigurations
  

▫️Найти подозрительный и посмотреть, куда он указывает.
▫️Если сервис не работает и не критичен — удалить/отключить webhook.
▫️Альтернатива: установить timeout'ы на webhook'и, чтобы не зависало вечно:

  timeoutSeconds: 5
  

📌 Совет: если helm install висит без логов — не всегда виноват Helm. Иногда виноваты "умные" валидаторы, которые сломались.

Подпишись 👉@devopslib

Сегодня поговорим о том, как облегчить жизнь при масштабировании инфраструктуры с помощью Terraform и GitLab CI/CD. Если вы еще не пробовали объединять возможности инфраструктурного кода и конвейера сборки, самое время начать!

➡️ 1. Почему Terraform + GitLab CI?

🔵Terraform позволяет описать состояние вашей инфраструктуры в виде кода. Это не просто создание ресурсов, а контроль версий, ревью изменений и откат к любому предыдущему состоянию.
🔵GitLab CI/CD же отвечает за автоматизацию. Каждый коммит в ветку может запускать планирование изменений (terraform plan), согласование и применение (terraform apply) без участия человека. В итоге – стабильность и предсказуемость.

➡️ 2. Структура проекта:

🔵В корне репозитория размещаем директорию infra/, где храним модули Terraform для разных сред (staging, production).
🔵Создаем файл .gitlab-ci.yml, который запускает этапы в этом порядке:

1. terraform:init – инициализация рабочего каталога.
2. terraform:validate – проверка синтаксиса и форматирование.
3. terraform:plan – составление плана изменений.
4. По результатам plan – ручной approval (при необходимости) и terraform:apply для production.

➡️ 3. Пример простого конвейера на скрине

В этом примере при каждом мердж-реквесте проверится валидность и отформатированность кода Terraform, а также будет сформирован план. Чтобы внести изменения в production, нужно вручную нажать “Play” на этапе apply.

➡️ 4. Секреты безопасности и best practices:

🔵Храните состояние (state) в надежном бекенде. Лучше всего – в S3 (или аналогах) с включенным шифрованием и версионированием. GitLab CI переменными задайте AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY, а файлы с учетными данными не храните в репозитории.
🔵Use workspaces для параллельных проверок: если у вас одно и то же окружение нужно тестировать для нескольких веток, включите поддержку разных Terraform workspaces (например, terraform workspace select feature-xyz).
🔵Разбейте инфраструктуру на модули. Один модуль – один кластер Kubernetes, другой – базы данных, третий – сеть. Это упростит поддержку и переиспользование кода.
🔵Политики и проверки. Интегрируйте с Terraform Sentinel или подобными инструментами (например, Open Policy Agent) для проверки соответствия стандартам (тэги, размеры инстансов и т. д.) перед применением.

➡️ 5. Переезд в Kubernetes под защитой Terraform

Если вы используете EKS/GKE/AKS, можно описать кластер как ресурс Terraform, а потом — Helm-релизы через Terraform-Helm-провайдер. Тогда при пуше манифестов в репозиторий вы не только строите образ и пушите его в реестр, но и обновляете Helm-релиз в кластере. Конвейер превращается в единый источник правды для всего стека.

➡️ 6. Мониторинг и оповещения

Не забудьте о интеграции с Prometheus и Alertmanager. Как только кластер Terraform появится, автоматизируйте развертывание необходимых Exporter’ов и настройку Alertmanager (через Terraform). В результате – сразу готовая к работе система мониторинга.

➡️ 7. Советы для ускорения CI/CD:

🔵Кешируйте плагины Terraform с помощью cache:key: files(...), чтобы избежать повторного скачивания провайдеров.
🔵Параллелите проверки: валидация, форматирование и статический анализ (такие инструменты, как tfsec) можно запускать в отдельных job’ах.
🔵Для крупных коммитов разбивайте apply на несколько этапов: сначала создаете ресурсы инфраструктуры (СУБД, сеть), потом — аппликацию, чтобы быстрее получить feedback.

💡 Совет от профи:

При масштабировании команды заведите отдельный GitLab-проект только для Terraform-модулей. В нем реализуйте строгие правила merge request’ов (например, обязательное ревью от тимлида и автоматический запуск tfsec). После этого подключайте эти модули как module в основном репозитории с приложением. Так вы централизуете контроль и снижаете риск несанкционированных правок.

Надеюсь, эти советы помогут вам выстроить надежный, безопасный и быстрый процесс управления инфраструктурой. Пробуйте, тестируйте и не бойтесь экспериментировать!

Подпишись 👉@devopslib

🛳️ Канареечные релизы в Kubernetes: безопасный путь к обновлениям

В мире SRE и DevOps стремительные релизы — это не просто плюс, а необходимость. Но как выкатывать новые версии сервисов без риска «сломать» продакшн? Ответ — канареечные релизы.

Что такое канареечный релиз?
Это поэтапный rollout, при котором новая версия приложения сначала попадает на небольшой процент трафика. Если всё OK — долю постепенно увеличивают до 100 %, а при проблемах быстро «откатываются» к старому состоянию.

Почему это круто?

🟢 🔍 Минимизируем риски: ошибки затронут лишь небольшой сегмент пользователей.
🟢 ⚡ Быстрый фидбек: метрики сразу покажут, как новая версия ведёт себя под нагрузкой.
🟢 ⏪ Моментальный откат: rollback проще и безопаснее, чем при монолитном апгрейде.

Как настроить канареечный релиз в Kubernetes с Argo Rollouts?

1. Установите CRD и контроллер:

   kubectl apply -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
   

2. Описываем Rollout-манифест:

   apiVersion: argoproj.io/v1alpha1
   kind: Rollout
   metadata:
     name: my-app
   spec:
     replicas: 5
     strategy:
       canary:
         steps:
         - setWeight: 10
         - pause: {duration: 60s}
         - setWeight: 50
         - pause: {duration: 60s}
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: my-app
           image: myregistry/my-app:v2
   

3. Запустите Rollout:

   kubectl apply -f rollout.yaml
   argo rollouts get rollout my-app --watch
   

4. Мониторинг и автоматизация:
Подключите Prometheus и Grafana — настройте метрики (латентность, ошибки) для автоматической паузы или отката.

Советы по продвинутому использованию

🟢 Используйте Webhooks в Argo Rollouts для интеграции с внешними системами тестирования.
🟢 Настройте AnalysisTemplates для автоматической оценки качества релиза по набору SLO.
🟢 Применяйте TrafficRouting через Istio или NGINX Ingress для более гибкого управления трафиком.

Такой подход поможет вам выкатывать фичи без лишнего стресса и без полунощных тревог от неожиданного падения сервисов.

Подпишись 👉@devopslib

🚀 Как настроить мониторинг SLO/SLA с Prometheus и Grafana

В любой современной инфраструктуре важно не просто собирать метрики, а строить на их основе понятные цели уровня обслуживания (SLO) и соглашения об уровне обслуживания (SLA). Вот несколько ключевых шагов:

1. Определите ключевые сервисные метрики

🟢Время отклика API
🟢Доля успешных запросов (error rate)
🟢Задержки базы данных
Сфокусируйтесь на показателях, которые прямо влияют на пользовательский опыт.

2. Собирайте метрики в Prometheus

🟢Используйте node_exporter для базового мониторинга хостов.
🟢Внедрите client_golang или client_python в ваши сервисы для экспорта бизнес-метрик.
🟢Настройте alertmanager для уведомлений при выходе за пороговые значения.

3. Проектируйте дашборды в Grafana

🟢Создайте отдельные панели для каждой SLO-метрики.
🟢Используйте графики «Burn rate» для визуализации скорости деградации системы.
🟢Настройте плагины для вычисления ошибок в процентах и «time in state».

4. Устанавливайте целевые уровни и оповещения

🟢Определите допустимую ошибку, например, 99.9% успешных запросов в месяц.
🟢Настройте алерты на 85% и 95% пороги, чтобы предупредить о приближении к SLA-линии.
🟢Включите эскалацию в случае длительных нарушений.

5. Периодически пересматривайте SLO

🟢Анализируйте реальные данные и корректируйте пороги.
🟢Обсуждайте результаты с командой разработки и бизнес-стейкхолдерами.

Хорошо выстроенный мониторинг SLO/SLA позволяет увидеть узкие места до того, как они станут инцидентами, и обеспечить стабильность пользователей на нужном уровне.

Подпишись 👉@devopslib

🚀 MEETUPxSPRINT OFFER для инженеров технической поддержки от YADRO

Хочешь узнать, как устроена техническая поддержка в одной из ведущих технологических компаний России? Приходи на онлайн-митап от YADRO! Расскажем, покажем, ответим на любые вопросы — и дадим возможность попасть в команду всего за 3 дня!

🔥 Программа митапа:

✔️ Сервисная служба YADRO: основные ресурсы и направления
Василий Бронников, Руководитель отдела техподдержки решений

✔️ Наши продукты: уникальные характеристики и возможности
Андрей Антоненко, Ведущий инженер техподдержки TATLIN

✔️ Реальные кейсы: как команды решают сложные задачи
Дмитрий Сафонов, Руководитель группы L1-поддержки TATLIN.UNIFIED

🔥 Что тебя ждёт:

➖ Реальные кейсы и инсайты из практики техподдержки
➖ Доклады от инженеров YADRO: продукты, процессы, особенности
➖ Живое общение с командой и ответы на вопросы о работе и технологиях

👨‍💻 А если ты задумываешься о новой работе — у тебя есть возможность быстро попасть в команду YADRO и получить оффер за 3 дня. Для этого нужно пройти короткий тест. Сделать это можно уже сейчас, а также во время или после митапа — выбирай, как тебе удобно (но заявки принимаем до 6 июля).

📌 Тест можно пройти по ссылке.

➖➖➖

🗓 26 июня, начало в 19:00 мск, четверг

🌐 ОНЛАЙН

✅ Регистрация на мероприятие

Реклама. ООО "ЭВРОНЕ.РУ". ИНН 3663057399. erid: 2VtzqvK4SaS