Мониторинг кластеров Kubernetes с помощью Azure Monitor и облачных собственных средств

Мониторинг Kubernetes в Azure Monitor используется для описания служб Azure Monitor, которые обеспечивают полный мониторинг вашей среды Kubernetes и всех работающих в ней нагрузок. В этой статье приведены рекомендации по использованию этих служб для мониторинга различных уровней среды Kubernetes на основе типичных ролей, которыми они управляют.

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

Схема слоев среды Kubernetes со связанными административными ролями.

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

Роли Описание
Разработчик Разработка и обслуживание приложения, работающего в кластере. Отвечает за конкретный трафик приложения, включая производительность приложения и сбои. Обеспечивает надежность приложения в соответствии с соглашениями об уровне обслуживания.
Инженер платформы Отвечает за кластер Kubernetes. Подготавливает и поддерживает платформу, используемую разработчиком.
Сетевой инженер Отвечает за трафик между рабочими нагрузками, а также входящий и исходящий трафик с кластером. Анализирует сетевой трафик и выполняет анализ угроз.

Сетевой инженер

Сетевой инженер отвечает за трафик между рабочими задачами и любой входящий/исходящий трафик в взаимодействии с кластером. Они анализируют сетевой трафик и выполняют анализ угроз.

Схема слоев среды Kubernetes для сетевого инженера.

Уровень монитора 1 — сеть

Ниже приведены распространенные сценарии мониторинга сети.

  • Создайте журналы flow с помощью Наблюдатель за сетями для записи сведений о трафике, который передается через группы безопасности сети, используемые кластером, а затем используйте traffic analytics для анализа и предоставления аналитических сведений об этих данных. Используйте ту же рабочую область Log Analytics для аналитики трафика, что и для журналов контейнеров и журналов управления.
  • Используя аналитику трафика, определите, передается ли какой-либо трафик из непредвиденных портов, используемых кластером, а также, если трафик передается по общедоступным IP-адресам, которые не должны предоставляться. Используйте эти сведения для определения необходимости изменения правил сети.
  • Для кластеров AKS используйте надстройку "Наблюдаемость сети" для AKS (предварительная версия) для мониторинга и наблюдения за доступом между службами в кластере (трафик на востоке запада).

Инженер платформы

Инженер платформы, также известный как администратор кластера, отвечает за сам кластер Kubernetes. Они подготавливают и поддерживают платформу, используемую разработчиками. Они должны понимать работоспособность кластера и его компонентов и иметь возможность устранять обнаруженные проблемы. Кроме того, они должны понимать затраты на работу кластера и, возможно, иметь возможность выделять затраты для разных команд.

Схема слоев среды Kubernetes для инженера платформы.

Крупные организации также могут иметь архитектор флота, который аналогичен инженеру платформы, но отвечает за несколько кластеров. Им необходимо иметь общий обзор всей ИТ-среды и выполнять административные задачи в большом масштабе. Рекомендации по масштабированию включены в руководства, приведенные ниже. Дополнительные сведения о создании ресурса Fleet для нескольких кластеров и сценариев масштабирования смотри в разделе Что такое Azure Kubernetes Fleet Manager?.

Настройка мониторинга для инженера платформы

В следующих разделах описаны действия по мониторингу среды Kubernetes с помощью служб Azure в уровнях Container. Функции и параметры интеграции предоставляются для каждого из них, чтобы определить, где может потребоваться изменить эту конфигурацию в соответствии с конкретными требованиями. Подключение управляемого Prometheus и логирование контейнеров может быть частью того же опыта, что и в разделе Включение мониторинга для кластеров Kubernetes. В следующих разделах описаны каждый отдельно, чтобы можно было рассмотреть все параметры подключения и конфигурации для каждого из них.

Включение очистки метрик Prometheus

Внимание

Чтобы использовать управляемую службу Azure Monitor для Prometheus, необходимо иметь рабочую область Azure Monitor. Сведения о проектировании конфигурации рабочей области см. в разделе архитектура рабочей области Azure Monitor.

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

Если у вас уже есть среда Prometheus, которую вы хотите использовать для кластеров AKS, включите Azure Monitor управляемую службу для Prometheus и используйте удаленную запись для отправки данных в существующую среду Prometheus. Вы также можете использовать удаленную запись для отправки данных из существующей самоуправляемой среды Prometheus в управляемую службу Azure Monitor для Prometheus.

См. Конфигурация метрик Prometheus по умолчанию в Azure Monitor для получения подробной информации о метриках, собираемых по умолчанию, и их частоте сбора. Если вы хотите настроить сбор метрик Prometheus, см. раздел Настройка сбора метрик Prometheus в управляемой службе Prometheus в Azure Monitor.

Включение Grafana для анализа данных Prometheus

Примечание.

Панели Azure Monitor с Grafana в настоящее время находятся в общедоступной предварительной версии и могут заменить Managed Grafana. Эта версия Grafana не имеет затрат, не требует настройки и предоставляет панели мониторинга на портале Azure. Используйте Управляемый Grafana, если вы хотите создать панели мониторинга, которые объединяют данные из нескольких источников данных или если вы хотите интегрировать с существующей средой Grafana.

Создайте экземпляр Managed Grafana и свяжите его с рабочей областью Azure Monitor, чтобы использовать данные Prometheus в качестве источника данных. Эту конфигурацию можно также выполнить вручную, добавив управляемую службу Azure Monitor для Prometheus в качестве источника данных. Для мониторинга кластеров Kubernetes доступны различные предварительно созданные панели мониторинга, включая несколько, которые представляют аналогичную информацию в виде представлений аналитики контейнеров.

Если у вас есть существующая среда Grafana, вы можете продолжать её использовать, добавив управляемую службу Azure Monitor для Prometheus в качестве источника данных. Вы также можете добавить источник данных Azure Monitor в Grafana для использования данных, собранных аналитикой контейнеров, на пользовательских панелях мониторинга Grafana. Выполните эту конфигурацию, если вы хотите сосредоточиться на панелях мониторинга Grafana, а не с помощью представлений и отчетов аналитики контейнеров.

Включение сбора журналов контейнеров

Внимание

Чтобы использовать управляемую службу Azure Monitor для Prometheus, необходимо иметь рабочую область Log Analytics. Сведения об учтении факторов проектирования конфигурации рабочей области см. в разделе архитектура рабочей области Azure Monitor.

При включении сбора журналов контейнеров для кластера Kubernetes, Azure Monitor развертывает контейнерную версию агента Azure Monitor, которая отправляет журналы stdout/stderr и инфраструктуры в рабочую область Log Analytics в Azure Monitor, где их можно анализировать с помощью языка запросов Kusto Query Language (KQL).

См. раздел "Включение мониторинга для кластеров AKS", чтобы ознакомиться с предварительными требованиями и параметрами конфигурации для подключения кластеров Kubernetes. Подключение с помощью Политика Azure для обеспечения согласованности конфигурации всех кластеров.

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

  • Если вы используете только журналы для случайного устранения неполадок, попробуйте настроить эту таблицу как базовые журналы.
  • Используйте предустановки затрат, описанные в разделе "Включение параметров оптимизации затрат в аналитике контейнеров", чтобы сократить затраты на прием данных аналитики контейнеров, уменьшая объем собранных данных. Отключите сбор метрик, настроив аналитику контейнеров так, чтобы она собирала только журналы и события, поскольку многие из тех же значений метрик уже собираются с помощью Prometheus.

Если у вас есть готовое решение для сбора логов, следуйте инструкциям для этого инструмента или активируйте сбор логов с помощью Azure Monitor и воспользуйтесь функцией экспорта данных рабочей области Log Analytics для отправки данных в Центры событий Azure для дальнейшей пересылки в альтернативные системы.

Сбор журналов плоскости управления для кластеров AKS

Журналы для компонентов контрольной плоскости AKS реализуются в Azure как журналы ресурсов. Создайте настройку диагностики для каждого кластера AKS, чтобы отправлять журналы ресурсов в рабочую область Log Analytics. Используйте Политика Azure для обеспечения согласованной конфигурации в нескольких кластерах.

Существует стоимость отправки журналов ресурсов в рабочую область, поэтому следует собирать только те категории журналов, которые вы планируете использовать. Описание категорий, доступных для AKS, см. в Журналах ресурсов. Начните со сбора данных для минимального числа категорий, а затем измените параметр диагностики, чтобы собрать данные для дополнительных категорий по мере роста потребностей и оценить связанные с ними затраты. Журналы можно отправлять в учетную запись хранения Azure, чтобы сократить затраты, если необходимо сохранить информацию по соображениям соответствия требованиям. Дополнительные сведения о стоимости сбора и хранения данных журнала см. в разделе Подробности о ценах на журналы Azure Monitor Logs.

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

Категория Включить? Назначение
kube-apiserver Включить Рабочая область Log Analytics
kube-audit Включить Azure хранилище. Позволяет свести к минимуму затраты, сохраняя при этом журналы аудита на случай, если они потребуются аудитору.
kube-audit-admin Включить Рабочая область Log Analytics
kube-controller-manager Включить Рабочая область Log Analytics
kube-scheduler Отключить
автоматическое масштабирование кластера Включите, если включено автомасштабирование Рабочая область Log Analytics
охранник Включить, если включена Microsoft Entra ID Рабочая область Log Analytics
ВсеМетрики Отключить, так как метрики собираются в Управляемом Prometheus Рабочая область Log Analytics

Если у вас есть решение для сбора журналов, выполните инструкции по этому инструменту или включите сбор журналов с Azure Monitor и используйте функцию экспорта data рабочей области Log Analytics для отправки данных в концентратор событий Azure для пересылки в альтернативную систему.

Сбор журнала действий для кластеров AKS

Изменения конфигурации кластеров AKS хранятся в журнале действий. Создайте параметр диагностики для отправки этих данных в рабочую область Log Analytics для анализа с другими данными мониторинга. Сбор этих данных бесплатен, и вы можете анализировать их или настраивать оповещения с помощью Log Analytics.

Мониторинг уровня 2. Компоненты уровня кластера

Уровень кластера включает следующие компоненты:

Компонент Требования к мониторингу
Узел Изучите состояние готовности и производительность ЦП, памяти, диска и IP-адреса для каждого узла и заранее отслеживайте тенденции их использования перед развертыванием любых рабочих нагрузок.

Ниже приведены распространенные сценарии мониторинга компонентов уровня кластера.

портал Azure

  • Используйте единую панель мониторинга на портале Azure для просмотра производительности узлов в кластере, включая использование ЦП и памяти.
  • Используйте представление "Узлы", чтобы просмотреть работоспособность каждого узла, а также состояние и производительность подов, работающих на них. Дополнительные сведения об анализе работоспособности и производительности узлов см. в разделе Производительность кластера Kubernetes в Azure portal..
  • В разделе "Отчеты" используйте книги мониторинга узлов для анализа емкости диска, операций ввода-вывода диска и использования GPU. Дополнительные сведения об этих рабочих тетрадях см. в разделе мониторинга узлов.
  • В разделе "Мониторинг" выберите Рабочие книги, а затем Использование IP-адресов подсети, чтобы просмотреть выделение и распределение IP-адресов на каждом узле для выбранного диапазона времени.

Панели мониторинга Grafana

  • Используйте предустановленную панель мониторинга в Managed Grafana для Kubelet, чтобы увидеть здоровье и производительность каждой компоненты.
  • Используйте панели мониторинга Grafana со значениями метрик Prometheus, связанными с диском, например node_disk_io_time_seconds_total и windows_logical_disk_free_bytes для мониторинга подключенного хранилища.
  • Несколько панелей мониторинга Kubernetes доступны для визуализации производительности и работоспособности узлов на основе данных, хранящихся в Prometheus.

Log Analytics

  • Выберите категорию Containers в диалоговом окне queries в рабочей области Log Analytics, чтобы получить доступ к предварительно созданным запросам журнала для вашего кластера, включая запрос журнала Image inventory, который извлекает данные из таблицы ContainerImageInventory, заполненной аналитикой контейнеров.

Устранение неполадок

Анализ затрат

  • Настройте OpenCost, который является нейтральным к поставщикам проектом CNCF в песочнице с открытым исходным кодом для понимания затрат на Kubernetes, чтобы поддержать анализ ваших затрат на кластер. Он экспортирует подробные данные о затратах в Azure хранилище.
  • Используйте данные из OpenCost для разбивки относительного использования кластера различными командами в организации, чтобы можно было выделить затраты между ними.
  • Используйте данные из OpenCost, чтобы убедиться, что кластер использует полную емкость своих узлов путем плотной упаковки рабочих нагрузок, используя меньше больших узлов в отличие от множества небольших узлов.

Мониторинг уровня 3 - компоненты управляемого Kubernetes

Управляемый уровень Kubernetes включает следующие компоненты:

Компонент Наблюдение
Сервер API Отслеживайте состояние сервера API и определите любое увеличение нагрузки запроса и узкие места, если служба отключена.
kubelet Отслеживайте Kubelet, чтобы помочь устранить неполадки управления подами, когда поды не запускаются, узлы не готовы или поды убиваются.

Ниже приведены распространенные сценарии мониторинга управляемых компонентов Kubernetes.

портал Azure

Grafana

  • Используйте предварительно созданную панель мониторинга в управляемой Grafana для Kubelet, чтобы увидеть работоспособность и производительность каждого kubelet.
  • Используйте панель мониторинга, например сервер API Kubernetes, для полного представления производительности сервера API. Здесь можно получить такие значения, как задержка запросов и время обработки рабочих очередей.

Log Analytics

Устранение неполадок

Мониторинг уровня 4 - объектов и рабочих нагрузок Kubernetes

Уровень объектов и рабочих нагрузок Kubernetes включает следующие компоненты:

Компонент Требования к мониторингу
Развертывания Отслеживайте фактическое состояние развертывания по сравнению с желаемым, а также статус и использование ресурсов модулей Pods, работающих на них.
Поды Отслеживайте состояние и использование ресурсов модулей Pod, работающих в кластере AKS, в том числе их ЦП и памяти.
Контейнеры Мониторинг использования ресурсов, включая ЦП и память, контейнеров, работающих в кластере AKS.

Ниже приведены распространенные сценарии мониторинга объектов и рабочих нагрузок Kubernetes.

портал Azure

Панели мониторинга Grafana

  • Используйте предварительно созданные панели мониторинга в Управляемой Grafana для узлов и подов, чтобы просмотреть их работоспособность и производительность.
  • Несколько панелей мониторинга Kubernetes доступны для визуализации производительности и работоспособности узлов на основе данных, хранящихся в Prometheus.

Динамические данные

Оповещения для инженера платформы

Уведомления в Azure Monitor заранее уведомляют вас об интересных данных и паттернах в ваших данных мониторинга. Они позволяют выявлять и устранять проблемы в системе до того, как ваши клиенты заметят их. Если у вас есть существующее решение ITSM для оповещений, вы можете интегрировать его с Azure Monitor. Вы также можете экспортировать данные рабочей области, чтобы отправить их из рабочей области Log Analytics в другое местоположение, которое поддерживает ваше текущее решение для оповещений.

Типы оповещений

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

Тип оповещения Описание
Оповещения Prometheus оповещения Prometheus написаны на языке запросов Prometheus (Prom QL) и применяются к метрикам Prometheus, хранящимся в управляемых службах Azure Monitor для Prometheus. Рекомендуемые оповещения уже включают наиболее распространенные оповещения Prometheus, и при необходимости можно создавать дополнительные правила генерации оповещений.
Правила оповещений о метриках Правила оповещений о метриках используют те же значения метрик, что и Metrics Explorer. На самом деле можно создать правило генерации оповещений непосредственно из обозревателя метрик с данными, которые вы сейчас анализируете. Правила оповещений метрик могут быть полезны для оповещения о производительности AKS с использованием любых значений в эталонных показателях данных AKS.
Правила оповещения при поиске по журналам Используйте правила поиска по журналам для генерации оповещений, чтобы создать оповещение из результатов запроса журнала. Дополнительные сведения см. в статьях "Как создать оповещения поиска по журналам в Container Insights" и "Как выполнять запросы журналов в Container Insights".

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

разработчик.

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

Схема слоев среды Kubernetes для разработчика.

Монитор уровня 5. Приложение

Реализуйте Azure Monitor Дистрибутив OpenTelemetry для включения Application Insights и настройки sampling для управления затратами.

Опыт работы с Application Insights

Журналы приложений

  • Аналитика контейнеров отправляет журналы stdout/stderr в рабочую область Log Analytics. См. журналы ресурсов для описания разных журналов и службы Kubernetes для списка таблиц, в которые они отправляются.

Сетка служб

  • Для кластеров AKS разверните надстройку сетевого сервиса с использованием Istio, которая обеспечивает наблюдаемость вашей архитектуры микросервисов. Istio — это сетка службы с открытым исходным кодом, которая прозрачно распространяется на существующие распределенные приложения. Надстройка помогает в развертывании и управлении Istio для AKS.

См. также