Инструкции (tutorials) по теме Managed Kubernetes - Страница 2 из 2

Введение Современный мир IT-технологий ставит перед разработчиками и администраторами высокие требования к надежности и доступности сервисов. Для достижения этих целей необходимо контролировать состояние инфраструктуры и быстро реагировать на возникающие проблемы. В качестве инструмента мониторинга часто используется Prometheus, который предоставляет средства сбора, хранения, визуализации и анализа метрик. Prometheus — это система мониторинга с открытым исходным кодом, созданная компанией SoundCloud для обеспечения мониторинга и оповещения об изменениях в приложениях и инфраструктуре. Он имеет гибкую архитектуру и может быть настроен для сбора метрик с различных источников, включая серверы, рабочие станции, коммутаторы и системы управления контейнерами, такие как Kubernetes. В данной статье мы рассмотрим основные компоненты Prometheus, задачи и сценарии его использования в Kubernetes и научимся разворачивать мониторинг кластера и приложения в нем. Также мы изучим процесс запуска Prometheus сервера в K8S, настройку мониторинга Kubernetes через Prometheus, установку Grafana и другие аспекты использования Prometheus. Основные компоненты Prometheus Основные компоненты Prometheus включают сервер Prometheus, Alertmanager и Prometheus экспортеры. Сервер Prometheus и его компоненты Сервер Prometheus состоит из нескольких основных компонентов, которые взаимодействуют между собой для обеспечения сбора, хранения и представления метрик. Первый компонент — это TSDB (Time-Series Database), который предназначен для хранения временных рядов метрик. В нем каждый временной ряд представлен в виде набора пар (timestamp, value), где timestamp — это временная метка, а value — значение метрики в этот момент времени. TSDB обеспечивает эффективное хранение метрик и быстрый доступ к ним для последующей обработки и анализа. Второй компонент — Retrieval worker, отвечает за сбор метрик. Prometheus собирает метрики с помощью механизма pull, который работает следующим образом: каждый определенный интервал времени Prometheus отправляет запрос к конечной точке метрик, чтобы получить последние значения метрик. Retrieval worker отвечает за выполнение этих запросов и получение метрик от целевых приложений. Третий компонент — HTTP server, представляет собой API для выполнения запросов к сохраненным в TSDB метрикам. С помощью HTTP сервера можно выполнить запрос на получение метрик за определенный период времени, а также применить функции агрегации, фильтрации и преобразования для полученных данных. Alertmanager Alertmanager — это компонент системы мониторинга, который отвечает за обработку и отправку оповещений на основе правил оповещения, заданных в конфигурации Prometheus. Alertmanager позволяет отправлять оповещения на различные каналы связи, такие как электронная почта, Slack, Telegram и т. д. Экспортеры Prometheus Экспортеры Prometheus — это компоненты, позволяющие собирать метрики с различных источников, которые не могут быть собраны непосредственно сервером Prometheus. Например, Node Exporter позволяет собирать метрики с операционной системы хоста, на котором запущены контейнеры, а Blackbox Exporter позволяет проверять доступность сервисов, работающих на удаленных хостах. В целом, Prometheus предоставляет широкие средства мониторинга, которые позволяют собирать и анализировать метрики с различных источников. Он имеет гибкую архитектуру и может быть настроен для сбора метрик с систем управления контейнерами, таких как Kubernetes. Давайте перейдем от слов к делу и развернем тестовый мониторинг для нашего кластера и приложения, развернутого в нем. Создание и настройка кластера Kubernetes Самым первым шагом для реализации мониторинга кластера будет создание самого кластера, если у вас еще его нет. Для создания кластера мы рекомендуем вам использовать статью из нашей официальной документации: там подробно описаны все способы создания кластера и подсказки для работы с ним. Отдельно обращаем ваше внимание на то, что для доступа к приложениям из внешней сети, вам потребуется создать Ingress-контроллер и настроить Ingress в кластере. Примеры настройки Ingress мы предоставим в одном из следующих шагов. Если у вас уже развернут кластер k8s, вы можете пропустить данный шаг и перейти к следующему. Установка Prometheus в кластер с помощью Helm В этой инструкции мы будем использовать Helm. Это менеджер пакетов для Kubernetes, который позволяет управлять установкой, обновлением и удалением приложений на Kubernetes-кластерах с помощью «установочных пакетов», называемых Helm-чарты. Использование Helm помогает упростить процесс управления приложениями в кластере. Для установки Prometheus в кластер с помощью Helm необходимо установить Helm на вашу локальную машину. Сделать это можно, выполнив команды: Для Debian/Ubuntu: Для RHEL/CentOS/Fedora: Для MacOS: Для Windows средствами Scoop: Для Windows средствами Chocolatey: Отдельно отметим, что всю актуальную информацию по установке Helm вы можете найти в официальной документации. После установки Helm, для установки актуальных версий чартов prometheus-community вам необходимо добавить в Helm официальный репозиторий разработчика. Это можно сделать, выполнив команды: После того как репозиторий будет подключен к Helm, вы можете выполнить поиск среди доступных вам чартов в нем. Для просмотра доступных пакетов в репозитории с именем prometheus-community, выполните команду: Для установки Prometheus в кластер k8s, нам потребуется установить чарт prometheus-community/kube-prometheus-stack. Подготовка к установке kube-prometheus-stack Для корректной установки готового к использованию чарта в кластер, нам необходимо создать конфигурационные файлы для приложений, которые будут развернуты в кластере. Начнем с настройки Alertmanager, компонента, ответственного за отправку уведомлений и алертов от нашего мониторинга. Для настройки конфигурации Alertmanager, создайте файл конфигурации: В этот файл необходимо ввести следующие данные: После этого сохраните файл. Теперь после развертывания в кластере Alertmanager будет отправлять оповещения в Telegram. Обращаем ваше внимание на то, что это далеко не единственный канал связи алертменеджера: уведомления можно отправлять в Slack, на почту, Rocket.Chat и десятки других каналов коммуникации. Подробнее о конфигурировании других каналов связи вы можете узнать в официальной документации. Установка kube-prometheus-stack в кластер После завершения заполнения дополнительных настроек чарта, мы можем приступить к установке kube-state-metrics в наш кластер Kubernetes. Для начала нам потребуется создать отдельный namespace для мониторинга, поэтому мы подключаемся к кластеру и выполняем команду: После этого, мы можем выполнять установку kube-prometheus-stack в наш кластер. Выполняем команду: После успешного завершения установки, вы увидите сообщение следующего вида: Это означает, что все установилось корректно. Проверить статус приложения вы можете, также, выполнив команду: helm status Проверяем, что все поды запустились, выполнив команду, которую нам предлагает helm: Убеждаемся, что все работает корректно и идем далее, к настройке Ingress, чтобы у нас была возможность зайти в веб-интерфейс Grafana из внешней сети. В случае нашей тестовой инсталляции, манифест Ingress выглядит так: Применяем манифест ингресса: После применения манифеста, вы сможете обращаться к Grafana через указанное вами доменное имя. В нашем случае это: grafana.selectel.site. Таким образом, чтобы получить доступ к Grafana, вы можете открыть веб-браузер и ввести адрес http://grafana.selectel.site. Обратите внимание, что для того, чтобы использовать доменные имена, вы должны настроить DNS-записи для указанных доменных имен, чтобы они указывали на IP-адрес вашего кластера Kubernetes. Если вы используете Managed Kubernetes Selectel, А-записи доменов должны указывать на внешний адрес Балансировщика, который создается вместе с Ingress-Controller. Создание и базовая настройка Ingress Controller подробно описаны в нашей документации. Переходим по домену, который указывает на сервис Grafana. Если все сконфигурировано правильно, то перед вами будет окно входа. Учетные данные для входа: Как вы могли заметить, из всех описанных в чарте сервисов, внешний доступ был настроен только для Grafana. Это, в первую очередь, обусловлено принципами информационной безопасности: мы не рекомендуем вам публиковать такие сервисы, как Prometheus и Alertmanager в открытом доступе. Для того чтобы получить доступ к веб-интерфейсам других сервисов, вы можете воспользоваться механизмом kubectl port-forward. Выполните команду: После выполнения данной команды, kubectl пробросит порт 9090 на локальный порт 8080 вашего компьютера. В командной строке вы увидите следующий вывод: Теперь вы можете перейти в браузер и зайти в веб-интерфейс Prometheus по адресу: Команда для port-forward к поду Alertmanager будет иметь следующий вид: Далее мы с вами развернем в нашем кластере базу данных Redis и настроим ее мониторинг в кластере Kubernetes. Мониторинг Redis в Kubernetes В этой части нашей статьи мы развернем кластер БД Redis в k8s и настроим его мониторинг. Redis – высокопроизводительная key-value база данных, которая широко используется для кеширования данных, управления сессиями и других приложений. Установка Redis в кластер k8s Первое, что нам потребуется сделать для развертывания кластера Redis в Kubernetes кластере, — подключить репозиторий bitnami для последующей установки через Helm. Выполняем команды: Создаем отдельный неймспейс для кластера Redis: После этого создаем сам кластер. Для этого необходимо выполнить команду: Эта команда запускает установку Redis в кластерном режиме. Заданные значения параметров определяют, что в этом кластере Redis будет работать с тремя репликами, а также отключает использование постоянного хранилища для мастера и реплик. Важно понимать: это сделано для целей демонстрации работы Redis, но на реальном проекте необходимо настроить постоянное хранилище для данных. Ждем какое-то время после выполнения команды и проверяем, что все поды запущены: Далее нам потребуется настроить взаимодействие между развернутым кластером Redis и Prometheus. Настройка redis-exporter для сбора метрик СУБД В развернутом нами чарте по умолчанию доступно создание дополнительных контейнеров в подах с СУБД — redis-exporter, специальной программы, собирающей показания с СУБД, чтобы Prometheus мог забрать метрики себе. Для того чтобы включить данную функциональность в нашем чарте, нам потребуется создать файл redis.yaml: nano redis.yaml. Этот файл потребуется заполнить следующими значениями: После сохранения файла выполняем команду: При ее выполнении helm выставит новые значения вместо значений по умолчанию в настройках чарта и выполнит обновление ревизии нашего приложения. Отдельно отметим, что узнать все стандартные значения чарта можно с помощью команды: Вы также можете найти новые чарты или посмотреть значения по умолчанию на сайте ArtifactHUB, где собрано огромное множество различных репозиториев и чартов: от крупных корпоративных репозиториев вроде bitnami, до чартов, которые разрабатываются энтузиастами. Поды, содержащие в себе мастер и реплики нашей СУБД должны перезапуститься через какое-то время после обновления чарта, и в них появится новый контейнер для сбора метрик. После того как все поды стали активны, нам потребуется выполнить обновление другого нашего чарта — kube-prometheus-stack, его мы разворачивали в первой части данной статьи. В данном случае нам потребуется немного изменить конфигурацию сервера Prometheus, чтобы он снимал метрики с экспортера, который мы развернули. Открываем файл values.yaml, в который мы ранее вносили изменения для корректной работы Alertmanager: В конец этого файла необходимо внести конфигурацию kubernetes_sd_configs, позволяющую динамически подключаться к новым подам и собирать метрики с них. Подробнее о механизме service discovery вы можете почитать в официальной документации. Заполняем файл значениями: Сохраняем файл и выполняем команду: После этого наше приложение для сбора метрик обновится и будет автоматически забирать метрики с подов Redis. Переходим в веб-интерфейс prometheus и проверяем, все ли метрики собираются корректно. Для примера можно использовать метрику redis_up: Когда мы убедились, что метрики собираются корректно, нам необходимо обновить правила алертинга для нашего чарта kube-prometheus-stack. Дополняем файл values.yaml следующим содержимым: Сохраняем файл и выполняем обновление чарта в кластере: Проверяем, что все наши правила добавились корректно: Если на своем экране вы видите такую же картину, то все сделано правильно. На этом этапе можно смело добавлять дашборд для Grafana. Переходим на http://grafana.your.domain.com/dashboard/import (вместо grafana.your.domain.com необходимо вставить доменное имя, которое используется вами для доступа в Grafana). Вводим в поле для ID дашборда номер 14091 и нажимаем Import. В этом блоке статьи мы рассмотрели установку Redis в кластер Kubernetes с помощью Helm, а также настройку мониторинга Redis с помощью Prometheus и Redis-exporter. Мы установили Redis и Redis-exporter в кластер с помощью Helm, настроили метрики Redis-exporter и добавили их в Prometheus. Теперь мы можем отслеживать работу Redis с помощью Prometheus и Grafana, а также использовать Alertmanager для получения уведомлений о возможных проблемах в работе Redis. Настройка Blackbox Exporter в кластере k8s В этой части статьи мы рассмотрим развертывание и настройку Blackbox Exporter для мониторинга домена example.org. Blackbox exporter 一 инструмент, предназначенный для мониторинга внешних систем и сервисов. Этот инструмент используется для проверки доступности и работоспособности этих систем через различные протоколы HTTP, DNS, TCP, ICMP и другие. В основном он используется для мониторинга внешних систем и сервисов, которые не могут быть обработаны через обычные инструменты мониторинга. Установка Blackbox Exporter в кластер Kubernetes Для установки Blackbox exporter в namespace monitoring с помощью helm нужно выполнить следующую команду: Проверяем, что поды работают корректно: Настройка Blackbox Exporter После того как мы убедились, что под с blackbox exporter запустился и работает, нам потребуется в очередной раз внести изменения в values.yaml для чарта kube-prometheus-stack, чтобы добавить blackbox-exporter в конфигурацию prometheus. Важно: добавлять новую конфигурацию необходимо в том же месте, где вы добавляли конфигурацию для Service Discovery, начав с нового job-name. Добавляем в файл следующие данные: Данные изменения описывают конфигурацию job_name в Prometheus для мониторинга с помощью Blackbox exporter. Разберем структуру файла немного подробнее: metrics_path указывает, что метрики будут доступны по пути /probe, а параметры module указывают, что мониторинг будет проводиться модулем http_2xx_check, который проверяет код ответа HTTP на равенство 200 и содержание определенного текста в теле ответа. В static_configs определен список целевых объектов, в данном случае объект будет только один 一 https://example.org. Список relabel_configs содержит правила перенаправления и замены меток. Первое правило указывает, что значение метки address будет использоваться как значение параметра target, второе правило 一 значение параметра target будет скопировано в метку instance. Третье правило заменяет значение метки address на адрес Blackbox exporter, который находится в кластере Kubernetes и будет использоваться для сбора метрик. Сохраняем данный файл и применяем изменения: Теперь нам потребуется изменить values для чарта blackbox-exporter. По аналогии с предыдущими чартами, создаем файл blackbox.yaml. nano blackbox.yaml Заполняем файл следующими значениями: Здесь задаются настройки для двух модулей, которые могут использоваться для проверки доступности и работоспособности системы через протокол HTTP. В параметрах модуля http_2xx указывается, что для проверки будет использоваться протокол HTTP, таймаут на проверку составляет 5 секунд, а также указывается, какие версии HTTP будут допустимы для проверки. Также задаются коды состояния HTTP, которые считаются успешными (в данном случае это только код 200). Модуль http_2xx_check также использует протокол HTTP для проверки, но в нем задается метод GET для запроса, а также регулярное выражение, которое должно соответствовать ответу сервера (в данном случае должно присутствовать слово Example Domain). Также указывается, что проверка должна выполняться только для HTTPS-серверов, и задаются допустимые версии HTTP и коды состояния, которые считаются успешными. Обновляем конфигурацию экспортера: helm upgrade blackbox-exporter prometheus-community/prometheus-blackbox-exporter -f blackbox.yaml -n monitoring Осталось только обновить правила алертинга в конфигурации Prometheus. Открываем файл values.yaml и добавляем следующие значения в список правил алертинга. Код, который мы будем добавлять выглядит так: Сохраняем файл и выполняем обновление kube-prometheus-stack: Чтобы проверить работу blackbox-exporter, можно изменить в файле blackbox.yaml значение текста, которое должен искать модуль http_2xx_check в теле ответа, а затем обновить сам blackbox-exporter. При успешном выполнении должны прийти уведомления в Slack. Заключение В данной статье мы рассмотрели основные принципы мониторинга кластера Kubernetes при помощи Prometheus, изучили основы мониторинга приложений в кластере при помощи экспортеров приложений и blackbox exporter. Мы настроили Service Discovery и правила алертинга, а также научились разворачивать приложения в кластере с помощью Helm. Надеемся, этот материал поможет вам в выстраивании надежной и эффективной системы мониторинга.

Managed Kubernetes

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