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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы перенаправить журналы плоскости управления в существующее решение для ведения журнала, используйте функцию экспорта данных рабочей области Log Analytics, как описано в разделе "Включение сбора журналов контейнеров".

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

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

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

Этот уровень охватывает узлы, составляющие кластер и их вычислительные ресурсы, хранилище и емкость сети.

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

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

Azure portal

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

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

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

Log Analytics

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

Troubleshooting

• Для сценариев устранения неполадок может потребоваться доступ к узлам непосредственно для обслуживания или немедленной коллекции журналов. В целях безопасности узлы AKS не предоставляются в Интернете. Команда kubectl debug создает привилегированный модуль pod на узле через API Kubernetes. Сведения об этом процессе и необязательном доступе SSH из привилегированного модуля pod см. в статье "Подключение к SSH для Azure Kubernetes Service (AKS) узлов кластера для обслуживания или устранения неполадок".

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

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

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

Этот уровень охватывает компоненты плоскости управления, управляемые Azure, такие как сервер API и kubelet.

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

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

Azure portal

• Используйте обозреватель метрик для просмотра счетчика запросов inflight для кластера.
• Используйте рабочую книгу Kubelet для просмотра работоспособности и производительности каждого kubelet.

Grafana

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

Log Analytics

• Используйте запросы журналов с журналами ресурсов для анализа журналов уровня управления, созданных компонентами AKS.

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

  AzureActivity
  | where CategoryValue == "Administrative"
  | where OperationNameValue == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/WRITE"
  | extend properties=parse_json(Properties_d)
  | where properties.message == "Upgrade Succeeded"
  | order by TimeGenerated desc
  

Troubleshooting

• Для устранения неполадок доступ к журналам kubelet с помощью процесса, описанного в статье Get kubelet logs from Azure Kubernetes Service (AKS) cluster nodes.

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

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

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

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

Azure portal

• Используйте представления узлов и контроллеров для просмотра работоспособности и производительности модулей pod, выполняемых на них, и детализации до работоспособности и производительности своих контейнеров.
• Используйте представление "Контейнеры", чтобы просмотреть работоспособность и производительность контейнеров. Дополнительные сведения об анализе работоспособности и производительности контейнеров см. в статье "Анализ данных кластера Kubernetes с помощью аналитики контейнеров".
• Используйте книгу "Развертывания" , чтобы просмотреть метрики развертывания. Дополнительные сведения см. в разделе "Метрики развертывания и HPA" с помощью аналитики контейнеров.

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

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

Служба переноса

• В сценариях устранения неполадок аналитика контейнеров предоставляет доступ к динамическим журналам контейнеров AKS (stdout/stderr), событиям и метрикам pod. Дополнительные сведения об этой функции см. в статье "Просмотр журналов Kubernetes", событий и метрик pod в режиме реального времени.

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

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

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

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

Рекомендуемые оповещения

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

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

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

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

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

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

Опыт использования Application Insights

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

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

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

Сервисная сетка

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

См. также

• См. раздел "Включение мониторинга для кластеров Kubernetes" чтобы включить Управляемый Prometheus и сбор журналов на вашем кластере.