Инструкции (tutorials) по теме Managed Kubernetes

Мониторинг служебных компонентов Kubernetes в пространстве kube-system часто остается за пределами первоначальной настройки кластера. Однако стабильность таких компонентов как kube-apiserver, kube-scheduler и kube-controller-manager напрямую определяет работоспособность всей системы. Сбор метрик с этих подов требует точной настройки механизма обнаружения и безопасного доступа к их эндпоинтам. Здесь нам поможет vmagent. База: что такое Kubernetes, зачем нужен мониторинг и из чего состоит VictoriaMetrics Cluster Kubernetes (k8s) — это оркестратор контейнеров, упрощающий развертывание, масштабирование и управление приложениями. Мониторинг — процесс сбора и анализа метрик, логов и событий для оценки состояния системы. В Kubernetes важно настроить мониторинг и observability компонентов внутри самого кластера, вплоть до контейнеров. Метрики и вся информация, которую можно получить из графиков, помогает выявлять проблемы до сбоев, оптимизировать ресурсы и обеспечивать стабильность кластера. Особое внимание стоит уделять служебным компонентам в kube-system, так как их деградация или отказ влияет на всю инфраструктуру. kube-system — один неймспейсов, предназначенный исключительно для системных компонентов, которые управляют работой самого кластера. Неймспейс (namespace) — это механизм изоляции группы ресурсов, в частности, в кластере Kubernetes. В статье рассмотрим мониторинг основных компонентов мастер-нод, таких как API-сервер (kube-apiserver), контроллер-менеджер (kube-controller-manager) и планировщик, который распределяет поды по физическим нодам (kube-scheduler). В данной статье я не затрагиваю etcd (распределённая, согласованная база данных типа «ключ-значение») — ее мониторинг требует отдельного разбора из-за особенностей работы распределенного хранилища. VictoriaMetrics Cluster — это база данных временных рядов, альтернатива Prometheus, но с оптимизациями для масштабируемости и долгосрочного хранения. В рамках предыдущей статьи мы развернули VictoriaMetrics в режиме single-node, то есть у нас уже была виртуальная машина, готовая снимать (скрейпить) метрики с нашего кластера Kubernetes. Это нам еще пригодится далее. Схема реализации сбора метрик со служебных ресурсов в кластере Kubernetes У VictoriaMetrics есть разные компоненты, которые стоят в стороне и не входят в состав VictoriaMetrics Cluster. Нас интересует vmagent — сборщик метрик (аналог Prometheus agent mode). Если говорить иными словами, vmagent идет на ресурс (в нашем случае, под или эндпоинт) и снимает с него метрики, которые ресурс сам отдает. Далее, в зависимости от настроек, vmagent либо сохраняет метрики локально, либо отправляет на удаленный VIctoriaMetrics кластер. В нашем случае, метрики будут отправляться на удаленный ресурс. Вот схема, которую мы реализуем в статье: Сбор метрик Подготовка инфраструктуры Итак, у нас уже есть кластер K8s с системными компонентами, которые мы планируем мониторить. Напомню, что это поды из неймспейса kube-system: kube-apiserver, kube-scheduler, kube-controller-manager. А vmagent развернем внутри K8s-кластера через Helm. Я не просто так акцентирую внимание на таком компоненте как vmagent, поскольку он несет в себе конфигурацию, благодаря которой мы получим интересующие нас метрики с интересующих нас ресурсов. Например, мы сможем рассмотреть поднят ли под, зависшее/ошибочное состояние пода (Pending, Backoff, Gated, Unschedulable), потребление памяти, CPU, время запросов к apiserver, количество запросов разного типа к API и другое. Что ж, приступим. Шаг 1. Разворачиваем vmagent в существующем Kubernetes-кластере Приложение vmagent в кластере развернем через Helm. Это менеджер пакетов для Kubernetes, который позволяет установить сложное приложение одной командой, а не десятками ручных настроек. Он уже содержит все нужные базовые настройки «из коробки», что экономит достаточное количество времени и избавляет от ошибок. Нам остается только дополнить правила снятия метрик. Чтобы развернуть приложение в кластере через Helm, у нас должен быть файл с нужной информацией (values). Соберем его по кусочкам. Шаг 2. Собираем основу файла values.yaml Обозначаем chart, как и всегда при развертывании любого приложения через Helm в кластере K8s. Здесь указывается информация об источнике пакета, его версии и namespace, в которое это приложение будет установлено в кластере K8s. Актуальную версию можно найти в репозитории. Далее разворачиваем под в единственном экземпляре. Для небольших кластеров этого достаточно. Кластер Kubernetes сам позаботится о бесшовном перезапуске пода, если будет нужно обновить конфигурацию vmagent, так как под управляется такой сущностью K8s как Deployment. Это инструкция, которая описывает, какой образ приложения запустить, сколько его копий создать и как обновлять их без простоя. Проще говоря, это автопилот для вашего приложения, который следит, чтобы оно всегда было запущено и работало в нужном состоянии. Указываем, из какого образа разворачиваем контейнер в поде, и скачиваем образ в том случае, если он не существует локально. Указываем, в какое хранилище будем отправлять метрики. Тут указывается внешний IP-адрес того сервера (или доменное имя, если есть), на котором поднимался VictoriaMetrics Cluster в рамках предыдущей статьи. Указываем данные для подключения к этому удаленному хранилищу (по умолчанию, они отсутствуют): Далее указываем максимальное количество данных, которые можно получить за один скрейпинг метрик, чтобы не перегружать как локально ноду, так и удаленное хранилище. Указываем ресурсы для пода vmagent: Шаг 3. Пишем джобу для снятия метрик для файла values.yaml Пишем саму конфигурацию скрейпа метрик с подов kube-apiserver. В ней обозначается, какие именно метрики и для чего vmagent будет собирать.По умолчанию в K8s-кластере есть сущность service с именем kubernetes. У нее есть эндпоинт — поды kube-apiserve, поэтому в качестве role указываются эндпоинты. Сбор метрик происходит через https со всех подов, поэтому часть ниже будет в каждой джобе: И, наконец, самое важное — конфигурация того, с чего мы хотим снимать метрики: Данной конфигурацией мы выбираем, с каких ресурсов будем собирать все метрики, которые отдает непосредственно сам ресурс. По конфигурации выше выбираются все ресурсы endpoints в кластере по лейблам __meta_kubernetes_namespace, __meta_kubernetes_service_name и __meta_kubernetes_endpoint_port_name. Их значения описаны в строке “regex”, где: __meta_kubernetes_namespace default, __meta_kubernetes_service_name kubernetes, __meta_kubernetes_endpoint_port_name https. В данном случае они отфильтрованы таким образом, чтобы мы получили только те endpoints, которыми являются поды kube-apiserver. Далее скрейп конфиг для подов kube-scheduler выглядит так: Забираем все поды с неймспейса kube-system: Отфильтровываем поды так, чтобы в имени содержалось «kube-scheduler» и переделываем адрес для сбора метрик. В данной конфигурации vmagent будет идти на https:// :10259/metrics. Точно такой же конфиг создаем для подов kube-controller-manager. Единственное изменение — заменить порт 10259 на 10257. Итого файл values.yaml для vmagent будет выглядеть следующим образом: Шаг 4. Деплоим vmagent в кластер Приступим к разворачиванию vmagent с конфигурацией выше в кластере K8s. Дальнейшие команды можно выполнять на хосте, с которого выполнялась установка кластера. Это хост с Ansible, вне кластера. Установим Helm. Добавим репозиторий. Обновим список репозиториев. Так как мы хотим установить приложение в кластер Kubernetes с хоста, который не является частью этого кластера, нам необходимо найти kubeconfig для подключения к конкретному кластеру. Так как кластер мы разворачивали через Kubespray по первой статье, то этот файл будет под названием super-admin.conf на мастере по пути /etc/kubernetes/super-admin.conf. Затем на локальном хосте выполняем экспорт: Проверка, что удалось подключиться к кластеру: Сервисы мониторинга рекомендуется разворачивать в отдельном неймспейсе, поэтому одной командой мы и создадим неймспейс с именем «victoria-metrics-agent», и развернем там vmagent. Файл values.yaml сгенерирован выше, его необходимо сохранить на хосте, с которого будете выполнять команду: Смотрим, что получилось: Идем в VMCluster по адресу *IP-адрес*:8428, заходим в vmui (веб-интерфейс) → Explore → Explore Prometheus Metrics. Тут видим наши джобы по их имени, для которых мы писали конфигурацию по снятию метрик: Посмотрим, например, метрики, по поду kube-apiserver: Например, результат за последние 15 минут по метрике на количество запросов к api серверу. Линий несколько — это на разные типы запросов к серверу (GET, POST, PATCH и т. д.). Итог Мы разобрали, как построить эффективный мониторинг Kubernetes с помощью vmagent и VictoriaMetrics Cluster, сосредоточившись на ключевых компонентах kube-system. Но собранные метрики — лишь сырые данные. В следующей статье я покажу, как выделить самые важные метрики для подов (CPU, память, сеть, готовность пода к работе) и превратить их в наглядные Grafana-дашборды.

Managed Kubernetes

Зарегистрируйтесь в панели управления