Мониторинг Kubernetes

Если вы какое-то время используете в своей работе Kubernetes, то почти наверняка задумывались о выборе инструмента для отслеживания состояния узлов кластера. Эта статья как раз об этом: расскажем о доступных инструментах и способах работы с ними. Рассмотрим, как выполнять мониторинг Kubernetes с помощью VictoriaMetrics, а также решения Prometheus + Grafana, и покажем, как можно избежать распространенных проблем.

Особенности мониторинга Kubernetes

Любой кластер Kubernetes состоит из узлов или нод (worker nodes), которые представляют собой отдельные серверы с приложениями. Узлы работают под управлением мастер-сервера Kubernetes Control Plane. Мониторинг включает отслеживание состояния самого мастер-сервера и различных системных компонентов. Однако проблема заключается в том, что нет коробочных решений для мониторинга состояния отдельных нод, составляющих кластер. А разработчикам порой важно знать об использовании процессорных мощностей и памяти серверов и, конечно, о нагрузке и работоспособности приложений.

Правда, в составе Kubernetes Control Plane есть модуль Kubelet, который дает информацию о состоянии API-сервера, главного узла Kubernetes Control Plane, а также о потреблении CPU и оперативной памяти контейнерами. Но сбор метрик с пользовательских приложений сопряжен с определенными трудностями. Дело в том, что приложения постоянно обновляются, что влечет за собой и необходимость обновления конфигурационных файлов. Понятно, что это затратно по времени, а для крупных приложений едва ли возможно. Поэтому приходится пользоваться сторонними инструментами, о которых и пойдет речь дальше.

Мониторинг кластера Kubernetes при помощи VictoriaMetrics

VictoriaMetrics — это СУБД временных рядов, совместимая с API Kubernetes. Она работает по принципу подписки, реагируя на изменения подов (под — это набор контейнеров, объединенных общим пространством имен).

Чтобы установить свежую версию VictoriaMetrics, откройте эту страницу на GitHub, пролистайте вниз и выберите подходящую версию для вашей операционной системы. Далее распакуйте архив в формате .gz, после чего можно приступать к запуску. Параметров запуска довольно много, поэтому рекомендуем ознакомиться с официальной документацией. Теперь изучим главные инструменты VictoriaMetrics, которые помогут нам с мониторингом Kube. 

Для контроля состояния пода используется relabel_config — набор последовательных правил. relabel_config состоит из 6 следующих строк:

• source_labels — здесь задается список элементов (labels), над которыми требуется провести определенные операции;
• action — выполняемое действие над labels (например, replace, keep, drop);
• modulus — редко используемое значение модуля для hashmod, требуется для работы с целями, собираемыми в результате мониторинга (например, для их масштабирования);
• regex — регулярное выражение для сопоставления (matching), а также значения, указанные в этой строке, могут использоваться для замены значения label;
• separator — разделитель для source_labels;
• target_label — последняя запись для указания имени label, в который будет записан результат действия (action).

Указанный выше набор правил используется для действий с labels (например, их можно добавлять, удалять, а также изменять их названия и значения) и фильтрации обнаруженных целей.

Что касается действий (actions), то VictoriaMetrics поддерживает все действия, доступные для Prometheus (об этом инструменте речь пойдет ниже). Помимо уже упомянутых выше replace, keep, drop, это также:

• labelmap
• labelkeep
• labeldrop
• hashmod

А кроме того, у VictoriaMetrics есть и набор собственных уникальных actions:

• replace_all
• keep_metrics
• drop_metrics
• labelmap_all
• keep_if_equal
• drop_if_equal

Пример того, как это работает:

scrape_configs:
- job_name: k8s-pods
  kubernetes_sd_configs:
  - role: pod
  relabel_config: 
  - source_labels: [_meta_kubernetes_pod_namespace]
  - action: keep
  - regex: ^default$

Эта запись означает, что мы сохраняем только поды, которые находятся в дефолтном пространстве имен, на что указывает выражение в строке regex.

Также VictoriaMetrics поддерживает выбор объектов из API Kubernetes в соответствии с их ролью, которая, опять же, может быть назначена средствами СУБД. В качестве ролей могут выступать:

• Pod. Используется для возвращения списка с labels для каждого порта контейнера с IP пода.
• Service. Объекты с этой ролью представляют собой подписки на изменения конкретных сервисов. Для каждого порта определенного сервиса создается свой label c метаданными вида server_name.namespace.svc и номером порта.
• Endpoints. Объект, используемый для связи сервисов и подов, отображающий состояние последних. Кроме того, Endpoints направляют трафик только на те поды, которые в данный момент работоспособны.
• Endpointslice. То же, что и Endpoints, но с измененными названиями префиксов labels. Endpointslice используется при значительном количестве endpoints (более тысячи), чтобы Kube не обрезал их.
• Node. Здесь всё понятно — это нода с соответствующей информацией.
• Ingress. Эта роль используется только для мониторинга. Она записывает в адрес имя хоста (host name), а путь (path) идет в отдельную переменную.

Данные роли назначаются при помощи строки role (пример с такой строкой также представлен в коде выше).

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

Как настроить мониторинг через Prometheus + Grafana

Строго говоря, Prometheus — это целый набор утилит, в комплекте с которым нередко идет и Grafana — веб-интерфейс, визуализирующий то, что собирает Prometheus. Установить этот набор можно разными способами. Например, при помощи helm. После клонирования репозитория введите следующую инструкцию:

cd charts/stable/prometheus-operator
helm dependency update

И затем:

chelm install --name prometheus --namespace monitoring prometheus-operator

• В поде Prometheus содержатся два полезных плагина: config-reloader используется для отслеживания изменений и перезагрузки конфигурационного файла prometheus.yaml, а rules-configmap-reloader предназначен для отслеживания изменений правил Прометеуса.
• В поде Alertmanager находится сам менеджер, предназначенный для автоматического создания уведомлений по указанным правилам, а также config-reloader — плагин для перезагрузки менеджера в случае изменений в конфигурационном файле.
• В поде Grafana вы найдете тот самый веб-интерфейс, который будет брать данные для отображения из TSBD (это база данных Прометеуса), и вдобавок Grafana-sc-dashboard для описания ресурсов ConfigMap и генерации json-ов.

После запуска подов вводим следующую инструкцию:

kubectl port-forward prometheus-prometheus-prometheus-oper-prometheus-0 9090:9090

И открываем в браузере http://localhost:9090. Для просмотра списка собираемых метрик вводим:

kubectl get servicemonitors.monitoring.coreos.com

В предыдущей главе мы писали, что Prometheus помогает фильтровать поды. Для этого в наборе правил в scrape_config.yaml нам нужно прописать следующие инструкции:

relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
  action: keep
  regex: true
- source_labels: [__meta_kubernetes_namespace]
  action: replace
  target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_pod_name]
  action: replace
  target_label: kubernetes_pod_name

Кроме того, понадобится указать номер порта, создав строку вида:

prometheus.io/port: <port_number>

А также путь, по которому будут забираться метрики, что делается добавлением строки вида:

prometheus.io/path: <path>

Добавим, что при помощи Prometheus нетрудно отслеживать практически любые объекты, в том числе серверы, причем установленная ОС (Windows или Linux) не имеет значения. Среди отслеживаемых параметров отметим, например, использование оперативной памяти, CPU и дискового пространства, а если речь о приложениях — число ошибок, уровень запросов, а также время их исполнения.

При этом для получения метрик от ряда сервисов не требуется никаких дополнительных настроек, а для экспорта с остальных используются специальные скрипты, которые так и называются: exporters. Они уже настроены, поэтому единственное, что вам нужно будет сделать — просто найти и установить нужный вот отсюда. Все метрики хранятся в TSDB, а визуализируются через Grafana при помощи API, который отправляет запросы в TSDB. Разумеется, Grafana не единственный способ визуализации метрик Прометеуса, но, пожалуй, самый наглядный и удобный.

Решение проблемы одного порта

При необходимости сбора метрик с нескольких портов с конфигурацией Prometheus, приведенной в предыдущей главе, может возникнуть проблема, поскольку prometheus.io/port способен возвращать только один порт. Здесь можно использовать разные обходные пути. Например, те, которые предлагает уже упомянутая выше СУБД VictoriaMetrics.

Там есть инструмент под названием VictoriaMetrics Operator, использующий Custom Resource Definitions, при помощи которых и выполняется расширение API Kubernetes. У этого инструмента обширная документация, ознакомиться с которой можно на Гитхабе — там подробнейшим образом описываются все Custom Resources. Нас же интересует VMPodScrape, который запускается следующим образом:

apiVersion: operator.victoriametrics.com/v1beta1
kind: VMPodScrape
metadata:
  name: vm
  namespace: monitoring
spec:
  podMetricsEndpoints:
  - port: http
  - port: backup-metrics
  selector:
    matchLabels:
      app.kubernetes.io/name: vm

Обратите внимание, что мы указали два порта. Но можно включить сбор с нескольких портов и по-другому, используя уже знакомые нам наборы правил:

scrape configs
- job name: apiserver/0
  kubernetes_sd_configs:
  - role: endpoints
  scheme: http
  relabel_configs:
 …
  - action: keep
    source_labels:
    - __meta_kubernetes_service_label_component
    regex: apiserver
  - action: keep
    source_labels:
  - __meta_kubernetes_endpoint_port_name
    regex: https

- job name: coredns/0
  kubernetes_sd_configs:
  - role: endpoints
  relabel_configs:
 …
  - action: keep
    source_labels:
    - __meta_kubernetes_service_label_app
    regex: coredns
  - action: keep
    source_labels:
  - __meta_kubernetes_endpoint_port_name
    regex: http-metrics

Такой подход с созданием отдельных блоков под приложения в конфиг. файле тоже вполне рабочий. Поэтому выбирайте то решение, которое вам больше по вкусу. А в завершение полезная информация для разработчиков с ограниченным бюджетом: сравним оптимизацию двух рассмотренных инструментов.

Prometheus vs VictoriaMetrics

Как видим, и VictoriaMetrics (VM), и Prometheus — довольно удобные инструменты для работы с метриками. Но какой из них более экономичный? Такие тесты были проведены на Google Compute Engine в конце 2020 года, и оказалось, что:

• VM в 7 раз экономичнее по занимаемому месту хранимых данных;
• всплески при чтении с диска в 6,3 раза выше у Prometheus;
• по использованию RAM VM оказывается экономичнее в 5,3 раза (4,3 против аж 23 Гб у Прометеуса, которые требуются ему для стабильной работы).

Получается, что VictoriaMetrics позволяет существенно экономить на железе, что говорит о хорошей оптимизации данной СУБД. Впрочем, свежая (на момент написания статьи) версия Prometheus (2.42.0) датируется 31 января этого года. Да и разработчики VM, выкатившие свежий релиз 1.87.0 2 февраля, тоже не отстают, так что соотношение сил вполне могло измениться: ждём новых тестов.