Чем больше чартов в кластере Kubernetes, тем тяжелее проверить актуальность их релизов. Поэтому важно настроить мониторинг состояния чартов, чтобы своевременно планировать и выполнять новые обновления.
О том, как мы мониторим актуальные Helm-релизы и какие инструменты для этого используем, рассказывает Александр, ведущий системный администратор в Selectel. Подробнее — под катом.
Дисклеймер. В статье сконцентрировались на нашем опыте мониторинга Helm-релизов. Начиная с поиска утилиты для проверки актуальных версий и заканчивая визуализацией данных. Надеемся, этот материал поможет вам выстроить надежную и эффективную систему мониторинга Helm-релизов.
Развертывание приложений в Kubernetes может быть сложной задачей. Например, если в приложении есть несколько независимых ресурсов k8s — подов, служб, наборов реплик — и для каждого из них требуется детализированный манифест YAML.
Конечно, можно задеплоить их вручную, но это отнимет много времени и сил. А если таких файлов больше десятка и все они с измененными параметрами? Каждый раз создавать новый файл, редактировать переменные и деплоить заново? Для решения этой проблемы разработчики используют Helm, пакетный менеджер для Kubernetes.
Helm значительно упрощает развертывание приложений, предоставляя единый метод упаковки ПО — чарты (charts). Они содержат описания ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes. Часто один chart может быть установлен много раз в одном и том же кластере, при этом иметь разные переменные. Поэтому для каждого чарта Helm создает новый релиз.
Зная эти понятия, объяснить работу Helm можно так:
В нашей инфраструктуре мы используем два способа доставки Helm chart-ов: GitLab CI/CD и Flux CD.
GitLab CI/CD. При помощи него мы доставляем приложения департамента разработки и эксплуатации продуктов. Поскольку задача этого департамента — постоянно добавлять новые фичи и продукты, там не столь актуален мониторинг версий. К тому же в продакшн попадают только те версии, которые запускаются Continuous Integration.
Flux CD. С этим GitOps-оператором ситуация иная. Через него мы доставляем чарты, которые разворачиваются в нашей инфраструктуре крайне редко — в основном это stateful-приложения. Например, инстансы ELK, базы данных MongoDB, Redis и различные Kubernetes-операторы. Их переменные или версии чартов часто не обновляются и работают в фоновом режиме.
Однако многие приложения в Flux CD могут быть развернуты через чарты из сторонних репозиториев. И чтобы они корректно работали, необходимо знать новые версии чартов и проверять актуальные инсталляции. Именно для этого нужен мониторинг Helm-чартов. Он проверяет их актуальность через встроенный Helm Operator.
Мы провели поиск, какие утилиты могут нам подойти для проверки актуальности. Больше всего по параметрам приглянулась Nova (не путать с компонентом OpenStack). Остальные утилиты были в составе больших инфраструктурных пакетов и инсталляций.
Nova проверяет все установленные Helm-релизы в кластере и смотрит доступные версии на апстримах, сторонних Helm-репозиториях. С помощью этой информации разработчик может узнать, какие релизы устарели, и обновить их до последней версии. После проверки Nova выводит всю информацию в JSON-формате по каждому Helm-релизу.
Под Nova мы построили воркфлоу для проверки актуальности версий.
Процесс проверки актуальности Helm-релизов.
Для этого процесса мы написали Docker Image с Python-скриптом. Добавили утилиту Nova и запустили HTTP-сервер через его образ. А чтобы было проще реализовать мониторинг и доставить контейнер в качестве пода в Kubernetes-кластер, мы написали новый chart.
В нем стандартный набор манифестов — деплоймент для развертывания пода, configmap для Nova, Service, Service Account и RBAC. Последний необходим для доступа к списку Helm-репозиториев внутри кластера, чтобы передавать его Nova. Опционально можно поднять Service Monitor, чтобы мониторинг (например, Prometheus или Victoria Metrics) смог автоматически собирать метрики с актуальных версий чартов.
Компоненты Helm chart-а ↓
nova_helm_release_status{chart="consul",deprecated="False",installed_version="0.36.0",latest_version="0.36.0",nova_helm_release_status="True",outdated="False",release="consul-sre",relese_namespace="consul-sre"} 1.0
nova_helm_release_status{chart="consul",deprecated="False",installed_version="0.36.0",latest_version="0.36.0",nova_helm_release_status="False",outdated="False",release="consul-sre",relese_namespace="consul-sre"} 0.0
Prometheus-метрики.
После проверки актуальности Helm-чартов мы получаем Prometheus-метрики со встроенного HTTP-сервера. В них — название чарта, deprecated-статус, последняя версия доступа, установленная версия и namespace, где развернут chart. Поверх всех метрик можно написать алерты, которые реагируют на устаревание релиза, а именно — стандартный Prometheus-мониторинг.
Grafana Dashboard.
Для более удобной визуализации данных мы перенесли Prometheus-метрики в дашборд Grafana. В дашборде можно выбрать контекст, один из наших кластеров и увидеть весь список Helm-релизов с Prometheus-метриками. Отдельно есть поля под outdated- и deprecated-статус. Это позволяет сразу видеть текущии версии релизов и обновлять устаревшие, когда есть вся картина развернутых чартов в кластере. Дополнительно можно отфильтровать метрики: например, исключить Helm-чарты Selectel, которые деплоятся через CI/CD.
Конечно, такой подход не решает проблемы обновления релизов на новые версии автоматически, поскольку это все еще ручная работа. Однако, благодаря этому инструменту, можно не тратить много времени на обработку устаревших чартов. И вместо этого своевременно планировать список новых обновлений для инсталляции Helm-чартов.
habr.com
О том, как мы мониторим актуальные Helm-релизы и какие инструменты для этого используем, рассказывает Александр, ведущий системный администратор в Selectel. Подробнее — под катом.
Дисклеймер. В статье сконцентрировались на нашем опыте мониторинга Helm-релизов. Начиная с поиска утилиты для проверки актуальных версий и заканчивая визуализацией данных. Надеемся, этот материал поможет вам выстроить надежную и эффективную систему мониторинга Helm-релизов.
Для чего нужен Helm в Kubernetes
Развертывание приложений в Kubernetes может быть сложной задачей. Например, если в приложении есть несколько независимых ресурсов k8s — подов, служб, наборов реплик — и для каждого из них требуется детализированный манифест YAML.
Конечно, можно задеплоить их вручную, но это отнимет много времени и сил. А если таких файлов больше десятка и все они с измененными параметрами? Каждый раз создавать новый файл, редактировать переменные и деплоить заново? Для решения этой проблемы разработчики используют Helm, пакетный менеджер для Kubernetes.
Helm значительно упрощает развертывание приложений, предоставляя единый метод упаковки ПО — чарты (charts). Они содержат описания ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes. Часто один chart может быть установлен много раз в одном и том же кластере, при этом иметь разные переменные. Поэтому для каждого чарта Helm создает новый релиз.
Зная эти понятия, объяснить работу Helm можно так:
Деплой Helm-чартов
В нашей инфраструктуре мы используем два способа доставки Helm chart-ов: GitLab CI/CD и Flux CD.
GitLab CI/CD. При помощи него мы доставляем приложения департамента разработки и эксплуатации продуктов. Поскольку задача этого департамента — постоянно добавлять новые фичи и продукты, там не столь актуален мониторинг версий. К тому же в продакшн попадают только те версии, которые запускаются Continuous Integration.
Flux CD. С этим GitOps-оператором ситуация иная. Через него мы доставляем чарты, которые разворачиваются в нашей инфраструктуре крайне редко — в основном это stateful-приложения. Например, инстансы ELK, базы данных MongoDB, Redis и различные Kubernetes-операторы. Их переменные или версии чартов часто не обновляются и работают в фоновом режиме.
Однако многие приложения в Flux CD могут быть развернуты через чарты из сторонних репозиториев. И чтобы они корректно работали, необходимо знать новые версии чартов и проверять актуальные инсталляции. Именно для этого нужен мониторинг Helm-чартов. Он проверяет их актуальность через встроенный Helm Operator.
Поиск утилиты для проверки актуальных версий
Мы провели поиск, какие утилиты могут нам подойти для проверки актуальности. Больше всего по параметрам приглянулась Nova (не путать с компонентом OpenStack). Остальные утилиты были в составе больших инфраструктурных пакетов и инсталляций.
Nova проверяет все установленные Helm-релизы в кластере и смотрит доступные версии на апстримах, сторонних Helm-репозиториях. С помощью этой информации разработчик может узнать, какие релизы устарели, и обновить их до последней версии. После проверки Nova выводит всю информацию в JSON-формате по каждому Helm-релизу.
Как выглядит процесс мониторинга Helm-релизов
Под Nova мы построили воркфлоу для проверки актуальности версий.
- На первом этапе при помощи Kubernetes API вытаскиваем список всех Helm-репозиториев, которые находятся у нас в текущем кластере, и их URL. Для этого мы используем клиентскую Python библиотеку Kubernetes.
- Далее запускаем Nova и передаем ей список всех сторонних репозиториев, с которых необходимо проверить версии. Она смотрит установленные в кластере релизы и доступные версии чартов. И в конце операции отправляет нам файл в JSON-формате.
- После этого мы собираем Prometheus-метрики с помощью публичной Python библиотеки — prometheus_client, который преобразует JSON в Prometheus-формат. Далее вешаем лейблы и пушим на HTTP-сервер, а тот, в свою очередь, отдает нам актуальные метрики — установленные релизы, чарты и их версии.
Процесс проверки актуальности Helm-релизов.
Для этого процесса мы написали Docker Image с Python-скриптом. Добавили утилиту Nova и запустили HTTP-сервер через его образ. А чтобы было проще реализовать мониторинг и доставить контейнер в качестве пода в Kubernetes-кластер, мы написали новый chart.
В нем стандартный набор манифестов — деплоймент для развертывания пода, configmap для Nova, Service, Service Account и RBAC. Последний необходим для доступа к списку Helm-репозиториев внутри кластера, чтобы передавать его Nova. Опционально можно поднять Service Monitor, чтобы мониторинг (например, Prometheus или Victoria Metrics) смог автоматически собирать метрики с актуальных версий чартов.
Компоненты Helm chart-а ↓
- Deployment,
- Nova configmap,
- Service (for HTTP-server),
- Service Account,
- RBAC (for get Helm repos list),
- Service Monitor (optional).
Результаты мониторинга
nova_helm_release_status{chart="consul",deprecated="False",installed_version="0.36.0",latest_version="0.36.0",nova_helm_release_status="True",outdated="False",release="consul-sre",relese_namespace="consul-sre"} 1.0
nova_helm_release_status{chart="consul",deprecated="False",installed_version="0.36.0",latest_version="0.36.0",nova_helm_release_status="False",outdated="False",release="consul-sre",relese_namespace="consul-sre"} 0.0
Prometheus-метрики.
После проверки актуальности Helm-чартов мы получаем Prometheus-метрики со встроенного HTTP-сервера. В них — название чарта, deprecated-статус, последняя версия доступа, установленная версия и namespace, где развернут chart. Поверх всех метрик можно написать алерты, которые реагируют на устаревание релиза, а именно — стандартный Prometheus-мониторинг.
Grafana Dashboard.
Для более удобной визуализации данных мы перенесли Prometheus-метрики в дашборд Grafana. В дашборде можно выбрать контекст, один из наших кластеров и увидеть весь список Helm-релизов с Prometheus-метриками. Отдельно есть поля под outdated- и deprecated-статус. Это позволяет сразу видеть текущии версии релизов и обновлять устаревшие, когда есть вся картина развернутых чартов в кластере. Дополнительно можно отфильтровать метрики: например, исключить Helm-чарты Selectel, которые деплоятся через CI/CD.
Полезные материалы по теме
Заключение
Конечно, такой подход не решает проблемы обновления релизов на новые версии автоматически, поскольку это все еще ручная работа. Однако, благодаря этому инструменту, можно не тратить много времени на обработку устаревших чартов. И вместо этого своевременно планировать список новых обновлений для инсталляции Helm-чартов.
Как организовать мониторинг актуальности Helm-релизов в кластерах Kubernetes
Чем больше чартов в кластере Kubernetes , тем тяжелее проверить актуальность их релизов. Поэтому важно настроить мониторинг состояния чартов, чтобы своевременно планировать и выполнять новые...
habr.com