Мониторинг Kubernetes с помощью Prometheus и Thanos

[Kate]

Типичный кластер Kubernetes​

На диаграмме ниже показано типичное развертывание с использованием Kubernetes.

Типичный кластер Kubernetes
Развертывание состоит из трех уровней:

1. Виртуальные машины: master-ноды и worker-ноды.
2. Инфраструктурные компоненты Kubernetes.
3. Пользовательские приложения.

Внутри кластера компоненты взаимодействуют друг с другом обычно через HTTP(s) (REST или gRPC), но некоторые из них предоставляют доступ к API снаружи (Ingress). Эти API в основном используются для следующего:

1. Управление кластером через Kubernetes API Server.
2. Взаимодействие с пользовательскими приложениями через Ingress Controller.

В некоторых сценариях приложения могут отправлять трафик за пределы кластера для использования сторонних сервисов, таких как Azure SQL, Azure Blob или любых других.

Что мониторить?​

Мониторинг Kubernetes должен включать в себя все три уровня, упомянутые выше.

Виртуальные машины. Для того чтобы убедиться, что виртуальные машины исправны, необходимо собирать следующие метрики:

• Количество узлов.
• Утилизация ресурсов на узле (процессор, память, диск, пропускная способность сети).
• Состояние узла (работает, не работает и т.п.).
• Количество подов, работающих на каждом узле.

Инфраструктура Kubernetes. Для того чтобы убедиться в работоспособности инфраструктуры Kubernetes необходимо собирать следующие метрики:

• Состояние подов — ready (сколько реплик доступно), status, restarts (количество рестартов), age (сколько времени приложение запущено).
• Статус развертываний (Deployments) — desired (целевое количество реплик), current (текущее количество реплик), up-to-date (сколько реплик обновлено), available (сколько реплик доступно), age (сколько времени приложение запущено).
• Статус StatefulSets.
• Статистика выполнения CronJobs.
• Использование ресурсов подом (процессор и память).
• Проверки работоспособности (Health checks).
• События Kubernetes.
• Запросы к API-серверу.
• Статистика Etcd.
• Статистика смонтированных томов.

Пользовательские приложения. Каждое приложение должно предоставлять собственные метрики, основанные на его функциональности. Однако для большинства приложений есть общие метрики, такие как:

• HTTP-запросы (общее количество, задержка, код ответа и т. д.).
• Количество исходящих соединений (например, с базой данных).
• Количество потоков.

Сбор метрик, упомянутых выше, позволит вам создавать осмысленные алерты и дашборды, о чем мы кратко поговорим далее.

Thanos​

Thanos — это проект с открытым исходным кодом, на основе которого можно построить высокодоступную систему сбора метрик с неограниченным размером хранилища, бесшовно интегрирующуюся с существующими экземплярами Prometheus.

Для хранения исторических данных Thanos использует формат хранения Prometheus и может хранить метрики в любом объектном хранилище. Кроме того, он обеспечивает global view для всех экземпляров Prometheus.

Основные компоненты Thanos:

• Sidecar. Подключается к Prometheus и использует его для запросов в реальном времени через Query Gateway и/или загружает его данные в облачное хранилище для длительного хранения.
• Query Gateway. Реализует Prometheus API для агрегирования данных из нижележащих компонент (таких как Sidecar или Store Gateway).
• Store Gateway. Предоставляет доступ к содержимому облачного хранилища.
• Compactor. Делает уплотнение и даунсэмплинг (downsampling) данных в облачном хранилище.
• Receiver. Получает данные из remote-write WAL Prometheus, предоставляет их и/или загружает в облачное хранилище.
• Ruler. Вычисляет recording rules и alerting rules для данных в Thanos.

В этой статье мы сосредоточимся на первых трех компонентах.

Деплой Thanos​

Мы начнем с развертывания Thanos Sidecar в тех же кластерах Kubernetes, которые мы используем для пользовательских приложений, Prometheus и Grafana.

Есть много способов установки Prometheus, но я предпочитаю использовать Prometheus-Operator, который предоставляет настройки для мониторинга сервисов и развертываний Kubernetes, а также для управления экземплярами Prometheus.

Самый простой способ установки Prometheus-Operator — это использовать его Helm чарт, у которого есть встроенная поддержка высокой доступности, Thanos Sidecar и множество преднастроенных алертов для мониторинга кластерных виртуальных машин, инфраструктуры Kubernetes и ваших приложений.

Перед развертыванием Thanos Sidecar нам нужен Kubernetes Secret с информацией о том, как подключиться к облачному хранилищу.

Для демонстрации я буду использовать Microsoft Azure.

Создайте account для blob-хранилища:

az storage account create --name <storage_name> --resource-group <resource_group> --location <location> --sku Standard_LRS --encryption blob
Затем создайте папку (она же container) для метрик:

az storage container create --account-name <storage_name> --name thanos
Получите ключи от хранилища:

az storage account keys list -g <resource_group> -n <storage_name>
Создайте файл с настройками хранилища (thanos-storage-config.yaml):

Создайте Kubernetes Secret:

kubectl -n monitoring create secret generic thanos-objstore-config --from-file=thanos.yaml=thanos-storage-config.yaml
Создайте файл prometheus-operator-values.yaml, в котором переопределите настройки по умолчанию для Prometheus-Operator.

И деплой:

helm install --namespace monitoring --name prometheus-operator stable/prometheus-operator -f prometheus-operator-values.yaml
Теперь у вас должен быть высокодоступный Prometheus вместе с Thanos Sidecar, который загружает ваши метрики в Azure Blob Storage с неограниченным сроком хранения.

Для того чтобы Thanos Store Gateway предоставить доступ к Thanos Sidecar, нужно выставить его наружу через Ingress. Я использую Nginx Ingress Controller, но вы можете использовать любой другой Ingress Controller, который поддерживает gRPC (возможно, Envoy будет лучшим вариантом).

Для защищенного соединения между Thanos Store Gateway и Thanos Sidecar мы будем использовать mutual TLS. То есть клиент будет аутентифицировать сервер и наоборот.

Если у вас есть .pfx-файл, то вы можете извлечь из него закрытый, открытый ключ и сертификат с помощью openssl:

# public key
openssl pkcs12 -in cert.pfx -nocerts -nodes | sed -ne '/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p' > cert.key
# private key
openssl pkcs12 -in cert.pfx -clcerts -nokeys | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert.cer
# certificate authority (CA)
openssl pkcs12 -in cert.pfx -cacerts -nokeys -chain | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cacerts.cer
Создайте из этого два Kubernetes Secrets.

# a secret to be used for TLS termination
kubectl create secret tls -n monitoring thanos-ingress-secret --key ./cert.key --cert ./cert.cer
# a secret to be used for client authenticating using the same CA
kubectl create secret generic -n monitoring thanos-ca-secret --from-file=ca.crt=./cacerts.cer
Убедитесь, что у вас есть домен, который резолвится в ваш кластер Kubernetes, и создайте два поддомена, которые будут использоваться для маршрутизации к каждому из Thaos SideCar:

thanos-0.your.domain
thanos-1.your.domain
Теперь мы можем создать правила Ingress (измените имя хоста):

Теперь у нас есть защищенный доступ к Thanos Sidecars снаружи кластера!

Кластер Thanos​

На диаграмме развертывания Thanos, приведенной выше, вы могли заметить, что я решил развернуть Thanos в отдельном кластере. Это потому что мне нужен выделенный кластер, который можно было бы при необходимости легко воссоздать и предоставить инженерам доступ к нему, а не к продакшену.

Для развертывания компонентов Thanos я решил использовать этот Helm чарт (он пока еще не официальный, но следите за обновлениями, когда примут мой PR).

Создайте файл thanos-values.yaml, чтобы переопределить настройки чарта по умолчанию.

Поскольку для Thanos Store Gateway требуется доступ к blob-хранилищу, мы также создадим секрет хранилища в этом кластере.

kubectl -n thanos create secret generic thanos-objstore-config --from-file=thanos.yaml=thanos-storage-config.yaml
Для развертывания этого чарта мы возьмем те же сертификаты, которые использовали ранее.

helm install --name thanos --namespace thanos ./thanos -f thanos-values.yaml --set-file query.tlsClient.cert=cert.cer --set-file query.tlsClient.key=cert.key --set-file query.tlsClient.ca=cacerts.cer --set-file store.tlsServer.cert=cert.cer --set-file store.tlsServer.key=cert.key --set-file store.tlsServer.ca=cacerts.cer
Это команда установит Thanos Query Gateway и Thanos Storage Gateway, настроив их на использование защищенного канала.

Валидация​

Чтобы проверить, все ли работает правильно, вы можете перенаправить порт в HTTP-службу Thanos Query Gateway следующим образом:

kubectl -n thanos port-forward svc/thanos-query-http 8080:10902
После этого откройте браузер по адресу http://localhost:8080, и вы должны увидеть Thanos UI!

Grafana​

Для дашбордов вы можете установить Grafana, используя Helm чарт.

Создайте grafana-values.yaml со следующим содержимым:

Обратите внимание, что я добавил к нему три дефолтных дашборда. Вы также можете добавить и свои дашборды (самый простой способ — это использовать ConfigMap).

Затем деплой:

helm install --name grafana --namespace thanos stable/grafana -f grafana-values.yaml
И опять port-forward:

kubectl -n thanos port-forward svc/grafana 8080:80
И… всё! Вы развернули на основе Prometheus высокодоступное решение для мониторинга с долгосрочным хранилищем и централизованным представлением нескольких кластеров!

Другие варианты​

Эта статья посвящена Prometheus и Thanos, но если вам не нужен global view для нескольких кластеров, то вы можете использовать только Prometheus с долговременным хранилищем.

Другим вариантом является Cortex — еще одна платформа с открытым исходным кодом, которая немного сложнее, чем Thanos, и использует другой подход.

Источник статьи: https://habr.com/ru/company/otus/blog/526618/