Реализация мониторинга Kubernetes в Xiaomi

В этой статье представлен процесс реализации высокодоступного, постоянного хранилища и динамически настраиваемого решения для мониторинга Kubernetes.
Обзор предыдущей статьи:Помните исключение кластера kubernetes: время ожидания подключения kubelet к apiserver истекло

Гибкая платформа планирования Xiaomi (Ocean) и контейнерная платформа в основном основаны на платформе управления автоматизацией контейнеров с открытым исходным кодом kubernetes (называемой k8s) для предоставления услуг, а полная система мониторинга является предпосылкой для повышения качества контейнерных услуг. В отличие от традиционных физических хостов, каждый контейнер эквивалентен хосту, что приводит к увеличению количества и стоимости системных показателей на физическом хосте, а общий масштаб показателей мониторинга достаточно велик (через онлайн-статистику каждый индикатор узла достигает 10 000+). Кроме того, во избежание повторного колесостроения, необходимо максимально использовать систему мониторинга и сигнализации компании, и в нее необходимо интегрировать мониторинг и сигнализацию k8s. В дополнение к существующей инфраструктуре Xiaomi реализовать этот мониторинг не составляет труда.

Для более удобного управления контейнерами k8s инкапсулирует контейнер и имеет множество понятий, таких как Pod, Deployment, Namespace и Service. По сравнению с традиционными кластерами мониторинг кластера k8s более сложен:

(1) Существует больше аспектов мониторинга.В дополнение к мониторингу традиционных физических кластеров он также включает мониторинг основных служб (apiserver, etcd и т. д.), мониторинг контейнеров, мониторинг Pod и мониторинг пространства имен.

(2) Объект мониторинга динамически изменчив, а уничтожение и создание контейнеров в кластере происходят очень часто и не могут быть заданы заранее.

(3) При взрывном росте масштабов контейнеров, как обрабатывать и отображать большой объем данных мониторинга.

(4) При динамическом росте кластера система мониторинга должна иметь возможность динамического масштабирования.

Помимо характеристик самого мониторинга кластера k8s, внедрение конкретных решений для мониторинга должно учитывать реальную ситуацию внутри компании:

(1) В настоящее время кластеры k8s, предоставляемые вычислительной платформой с эластичным планированием, включают: кластеры конвергентных облачных контейнеров, некоторые кластеры Ocean и кластеры CloudML с более чем десятью кластерами и более чем 1000 машинами. Методы развертывания, сетевые режимы и методы хранения разных кластеров k8s различаются, и схема мониторинга должна учитывать различные различия.

(2) Open-Falcon — это общая система мониторинга и сигнализации в компании с полным механизмом сбора данных, отображения и сигнализации, но Open-Falcon не поддерживает схему сбора данных k8s. Кроме того, различные ресурсы в k8s имеют естественную иерархическую взаимосвязь, которая определяет, что интеграция данных мониторинга требует сильных и гибких возможностей агрегирования, Falcon не может удовлетворить потребности в этих аспектах. Но мы не хотим изобретать велосипед, нам нужно максимально использовать существующую инфраструктуру компании, чтобы сократить расходы на разработку, эксплуатацию и техническое обслуживание.

(3) Для постоянного хранения данных мониторинга необходимо рассмотреть вопрос о том, как объединить базу данных в компании для реализации долгосрочного хранения данных мониторинга.

В существующей отрасли также есть несколько зрелых решений для мониторинга k8s:

(1)Heapster/Metrics-Server+ InfluxDB + Grafana

Heapster — нативное решение для мониторинга кластера для k8s (теперь заброшенное и превращенное в метрик-сервер), которое получает данные мониторинга, такие как вычисления, хранилище и сеть, из кадвизора на узле, а затем выводит данные во внешнее хранилище (бэкэнд). , такие как InfluxDB, и, наконец, И затем через соответствующий пользовательский интерфейс для визуального отображения, например графаны. Это решение простое в развертывании, но сбор данных один, что не подходит для общего мониторинга кластера k8s, а подходит только для мониторинга информации о ресурсах каждого контейнера в кластере, таких как источник отображения данных приборная панель k8s.

(2)Exporter+Prometheus+Adapter

Prometheus — это система с открытым исходным кодом для мониторинга и оповещения с многомерной моделью данных, гибкими и мощными операторами запросов и хорошей производительностью. Prometheus может собирать данные мониторинга метрик мониторинга через различные экспортеры, такие как node-exporter, kube-state-metrics, cadivsor и т. д. Кроме того, Prometheus может динамически обнаруживать такие объекты, как модули и узлы в кластере k8s. Собирайте данные различных размеров с помощью Prometheus, агрегируйте и выдавайте сигналы тревоги, а затем используйте адаптер для записи данных в удаленное хранилище (например, OpenTSDB, InfluxDB) для обеспечения постоянного хранения. Однако, поскольку сбор данных может быть потерян, Prometheus не подходит для ситуаций, когда собранные данные точны на 100%, например, для мониторинга в реальном времени.

На ранней стадии, чтобы реализовать внедрение k8s как можно скорее, система мониторинга использовала Falcon и внутреннего экспортера для сбора только основных данных мониторинга, таких как процессор Pod, память, сеть и другие ресурсы. использование. Конкретная архитектура показана на следующем рисунке.

Внедрив cadvisor-exporter для сбора данных мониторинга контейнеров cadvisor, kube-state-exporter для сбора ключевых индикаторов Pod k8s, Falcon-agent для сбора данных о физических узлах. Первоначальное решение собирает только данные основного мониторинга и изначально реализует мониторинг использования основных ресурсов, в нем отсутствует более полный мониторинг данных, такой как apiserver, etcd и т. д. Поскольку в настоящее время Falcon не поддерживает мониторинг контейнеров, необходимо вручную реализовать различные экспортеры, чтобы выполнить требования мониторинга k8s. Более того, данные мониторинга не реализуют постоянное хранение и не поддерживают долгосрочные запросы.

Из-за недостаточности первоначальной системы мониторинга Prometheus был окончательно выбран в качестве решения для мониторинга для k8s после изучения и сравнения, в основном по следующим причинам:

(1) Нативно поддерживает мониторинг k8s, имеет возможности обнаружения сервисов объектов k8s, а основные компоненты k8s предоставляют интерфейсы коллекций Prometheus.

(2) Высокая производительность: один Prometheus может собирать 100 000 метрик в секунду, что может удовлетворить требования мониторинга кластеров k8s в определенном масштабе.

(3) Хорошая возможность запросов: Prometheus предоставляет язык запросов данных PromQL. PromQL предоставляет большое количество функций расчета данных.В большинстве случаев пользователи могут напрямую запрашивать необходимые совокупные данные из Prometheus через PromQL.

Архитектура системы мониторинга k8s на базе Prometheus представлена ​​на следующем рисунке:

источник данных:node-exporter собирает метрики физических узлов; kube-state-metrics собирает метрики, связанные с k8s, включая использование ресурсов и информацию о состоянии различных объектов; cadvisor собирает метрики, связанные с контейнерами; apiserver, etcd, планировщик, k8s-lvm, gpu и другие ядра. Данные мониторинга компонента, другие пользовательские метрики, добавив prometheus.io/scrape: «true» в аннотации файла yaml pod, предоставленные метрики могут быть автоматически очищены.

Модуль обработки данных Prometheus:Prometheus развернут на k8s в режиме Pod, а Pod содержит Prometheus и Prom-Reloader. Prometheus отвечает за сбор агрегированных данных, prom-config — правило агрегации и захвата конфигурации для мониторинга, которая хранится в ConfigMap, Prom-Reloader реализует горячее обновление конфигурации мониторинга, отслеживает файлы конфигурации в режиме реального времени и динамически загружает последнюю конфигурацию без перезапуска приложения.

серверная часть хранилища: Сокол с OpenTSDB.

Open-Falcon — это унифицированная система мониторинга и сигнализации компании, которая обеспечивает полный сбор данных, сигнализацию, отображение, функции хранения исторических данных и функции авторизации. Из-за ранней разработки Falcon он не обеспечивает мониторинг индикаторов, связанных с контейнерами, в то время как prometheus изначально поддерживает k8s, но его функцию оповещения можно настроить только статически, и ее необходимо подключить к учетной записи, связанной с компанией, чтобы упростить настройку пользователя и мониторинга, а некоторые индикаторы k8s должны быть доступны пользователям контейнера. Основываясь на этом соображении, мы используем Falcon в качестве платформы сигнализации и внешнего дисплея для мониторинга k8s. Благодаря внедрению Falcon-Adapter данные мониторинга передаются в Falcon для сигнализации и отображения. В соответствии с сервисным объектом k8s цели мониторинга делятся на несколько уровней: кластер, узел, пространство имен, развертывание, модуль, а ключевые индикаторы сигналов тревоги отправляются в Falcon через Falcon-Agent.Пользователи могут настроить сигнал тревоги для просмотра индикаторов с помощью самих себя.

Данные мониторинга нативного Prometheus размещаются локально (с использованием базы данных часовых поясов tsdb), и по умолчанию данные сохраняются в течение 15 дней. Данные мониторинга используются не только для мониторинга и подачи аварийных сигналов.Последующий операционный анализ и уточненная эксплуатация и техническое обслуживание должны основываться на этих операционных данных, поэтому требуется постоянство данных. Некоторые решения для чтения и записи также предоставляются в сообществе Prometheus, например Influxdb, Graphite, OpenTSDB и т. д. И у Xiaomi есть команда OpenTSDB, OpenTSDB хранит данные временных рядов в HBase, и HBase нашей компании также имеет стабильную поддержку команды. Исходя из этого, он предоставляет удаленное хранилище для данных мониторинга через OpenTSDB. Реализован OpenTSDB-Adapter, и данные мониторинга пересылаются в базу данных временных рядов OpenTSDB для обеспечения постоянного хранения данных и удовлетворения потребностей в долгосрочных запросах и последующем анализе данных.

Все основные системы системного мониторинга развернуты в кластере k8s в виде Deployment/Daemonset для обеспечения надежности служб мониторинга. Все файлы конфигурации сохраняются с помощью ConfigMap и автоматически обновляются.

способ хранения
Хранилище Prometheus включает в себя локальное хранилище и удаленное хранилище.Локальное хранилище сохраняет только данные краткосрочного мониторинга.Согласно двум часам как временному окну, данные, сгенерированные в течение двух часов, хранятся в блоке (Блок), и каждый блок содержит все образцы данных (фрагменты), файлы метаданных (meta.json) и индексные файлы (index) в пределах этого временного окна. Из-за неспособности каждого кластера предоставить типы хранения, были развернуты различные методы хранения, включая pvc, lvm и локальные диски.

Удаленное хранилище реализует работу OpenTSDB за счет реализации интерфейса удаленного чтения и записи prometheus, удобного для долгосрочного запроса данных.

Чтобы сохранить простоту Prometheus, Prometheus не пытается решить вышеуказанные проблемы сам по себе, а определяет два стандартных интерфейса (remote_write/remote_read), позволяющих пользователям сохранять данные в любое стороннее хранилище на основе этих двух интерфейсов. службы, этот метод называется удаленным хранилищем в Promthues.

Как показано на рисунке выше, URL-адрес удаленной записи можно указать в файле конфигурации Prometheus.После установки этого элемента конфигурации Prometheus отправит собранные образцы данных адаптеру в форме HTTP. Пользователь может подключиться к любой внешней службе в адаптере. Внешние службы могут быть реальными системами хранения, общедоступными облачными службами хранения или любой формой, например очередями сообщений. Точно так же Remote Read от Promthues (удаленное чтение) также реализуется через адаптер. В процессе удаленного чтения, когда пользователь инициирует запрос запроса, Promthues инициирует запрос запроса (сопоставители, временные диапазоны) к URL-адресу, настроенному в remote_read, а адаптер получает данные ответа от стороннего сервиса хранения в соответствии с условия запроса. В то же время данные преобразуются в исходные образцы данных Promthues и возвращаются на сервер Prometheus. После получения демонстрационных данных Promthues локально использует PromQL для вторичной обработки демонстрационных данных. После включения параметра удаленного чтения он действителен только во время запроса данных.Обработка файлов правил и обработка API метаданных выполняются только на основе локального хранилища Prometheus.

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

В настоящее время решение для мониторинга на основе Prometheus развернуто в каждом кластере, но некоторые проблемы постепенно выявляются по мере роста масштаба кластера.

Во-первых, по мере роста контейнера показатели мониторинга растут, что оказывает определенное давление на Falcon-agent и передачу, что часто вызывает перегрузку Falcon-agent и задержки, а также потерю некоторых данных мониторинга. Онлайн-тест При отправке более 150000/м через одного Falcon-агента часто происходит потеря данных, а отправка некоторых данных мониторинга закрыта. Фундаментальная причина в том, что централизованная агрегация данных и push prometheuse сводит индикаторы, разбросанные по каждому кластеру, на один хост, что оказывает чрезвычайное давление.

Во-вторых, в крупномасштабном кластере Prometheus занимает много ресурсов процессора и памяти (в следующей таблице показана работа онлайн-кластера Prometheus), и иногда некоторые метрики невозможно зафиксировать, поэтому при масштабировании одного Prometheus возникнут узкие места в производительности.

Ввиду недостатков единого решения для мониторинга Prometheus его необходимо расширить, чтобы он соответствовал масштабному мониторингу кластера k8s и адаптировался к производительности системного агента Falcon. Исследования показали, что Prometheus поддерживает федерацию кластеров. Такой способ разделения увеличивает масштабируемость самого Prometheus и в то же время позволяет распределить нагрузку на одного агента Falcon.

Функция федерации — это специальный интерфейс запросов, который позволяет одному прометею сканировать метрики другого прометея с целью разделения. Следующее:

Существует два распространенных метода разделения:

Один - функциональное разделение, функция федеративного кластера может помочь пользователям настроить архитектуру развертывания Promthues в соответствии с различными масштабами мониторинга и может развертывать несколько экземпляров Prometheus Server в каждом центре обработки данных. Каждый экземпляр Prometheus Server отвечает только за сбор части задач (Job) в текущем центре обработки данных, например, разные задачи мониторинга могут быть назначены разным экземплярам Prometheus, а затем агрегированы центральным экземпляром Prometheus.

Второе — горизонтальное расширение., в крайних случаях количество целей одной задачи сбора становится очень большим. В настоящее время разделение функций просто выполняется через федеративный кластер, и сервер Prometheus не может с ним эффективно справиться. Эту ситуацию можно рассматривать только как продолжение функционального разделения на уровне инстанции. Разделите задачи сбора данных мониторинга разных экземпляров одной задачи на разные экземпляры Prometheus. С помощью параметра relabel мы можем гарантировать, что текущий сервер Prometheus собирает только индикаторы мониторинга части экземпляров текущей задачи сбора.

В соответствии с реальной ситуацией k8s, архитектура схемы разделов выглядит следующим образом:

Раздел Prometheus включает в себя главный Prometheus, подчиненный Prometheus и состояние куба Prometheus: поскольку большое количество индикаторов собирается из сервисов на узлах, таких как kubelet, node-exporter, cadvisor и т. д., собирается в узлах, поэтому разные задания делятся в соответствии для node nodes ведомый Prometheus собирает данные уровня node и pod в соответствии со слайсами node;

kube-state-metrics нельзя нарезать временно, и он используется только как kube-state Prometheus для сбора master Prometheus; другие etcd, apiserver, пользовательские метрики и т. д. могут собираться напрямую через master Prometheus.

Извлечение ведущим Prometheus других подчиненных устройств Prometheus можно настроить следующим образом:

- job_name: federate-slave  honor_labels: true  metrics_path: '/federate'  params:    'match[]':      - '{__name__=~"pod:.*|node:.*"}'  kubernetes_sd_configs:  - role: pod    namespaces:      names:      - kube-system  relabel_configs:  - source_labels:    - __meta_kubernetes_pod_label_app    action: keep    regex: prometheus-slave.*

Разделение подчиненного устройства Prometheus для захвата задач реализовано с помощью метода hashmod, предоставленного Prometheus:

- job_name: kubelet  scheme: https  kubernetes_sd_configs:  - role: node    namespaces:      names: []  tls_config:    insecure_skip_verify: true  relabel_configs:  - source_labels: []    regex: __meta_kubernetes_node_label_(.+)    replacement: "$1"    action: labelmap  - source_labels: [__meta_kubernetes_node_label_kubernetes_io_hostname]    modulus:       ${modulus}    target_label:  __tmp_hash    action:        hashmod  - source_labels: [__tmp_hash]    regex:         ${slaveId}    action:        keep

Метод развертывания

Мастер Prometheus и kube-state Prometheus развертываются посредством развертывания. Ведомый Prometheus может иметь несколько модулей, но поскольку конфигурация каждого модуля отличается (${slaveId} в конфигурации отличается), каждый подчиненный prometheus должен отражать номер раздела в конфигурации, а родной файл deploy/statefulset/daemonset делает это. не поддерживает Один и тот же шаблон Pod монтирует разные конфигурации ConfigMap. Чтобы облегчить управление ведомым устройством, Prometheus развертывает ведомое устройство через statefulset, потому что statefulset будет плавно нумеровать каждый модуль, такой как slave-0, slave-1 и т. д. Получите имя пода с помощью Prom-Reloader, постоянно отслеживайте изменения конфигурации Prometheus, а затем создавайте пронумерованную конфигурацию, чтобы различать разные модули разделов.

Тестовая проверка

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

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

По статистике более 95% ошибок сравнения временных рядов находятся в пределах 1%, а мгновенное колебание отдельных показателей (таких как использование сети) велико, но разница будет компенсироваться по мере увеличения времени.

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

Создайте 1000 виртуальных узлов в тестовом кластере и создайте различное количество модулей для проверки производительности разделов Prometheus:

Для Prometheus master и Prometheus kube-state максимум 8w pod могут поддерживаться в течение 1-минутного времени выборки.Основным узким местом является то, что с увеличением количества pod объем данных kube-state-metrics резко возрастает, а время требуемый для выборки, продолжает увеличиваться.

Для ведомого Prometheus из-за сбора частичных данных давление невелико, и один Prometheus может захватить более 400 узлов (60 pod/узел). Как показано на рисунке ниже, после включения удаленной записи время захвата продолжает увеличиваться, и производительность Remote-Storage-Adapter будет продолжать расти в будущем.

После проверки в тестовом кластере k8s архитектура мониторинга разделов Prometheus поддерживает модули до 8 Вт, что соответствует ожидаемым требованиям роста кластера.

В настоящее время решение для мониторинга разделов развернуто в некоторых кластерах и обладает такими характеристиками, как высокая доступность, постоянное хранилище и динамическая настройка. Кроме того, мы продолжим совершенствоваться в будущем: добиться автоматического расширения мониторинга, оптимизации производительности по kube-state-metrics (разделение на данный момент не поддерживается); в плане методов развертывания использовать prometheus-operator и helm для достижения более простого управление конфигурацией и развертывание При использовании данных мониторинга могут применяться специальные алгоритмы для глубокого анализа данных для предоставления ценной информации, например, использование данных мониторинга для прогнозирования расширения и поиска подходящих возможностей расширения. Благодаря постоянной оптимизации для обеспечения более стабильных, надежных и интеллектуальных услуг мониторинга для k8s.

Данная статья впервые опубликована в паблике «Облачные технологии Xiaomi», просьба указывать автора и источник для перепечатки.Нажмите, чтобы просмотреть исходный текст.