Поделиться через

Включение мониторинга для кластеров Azure Kubernetes Service (AKS)

Как описано в мониторинге Kubernetes в Azure Monitor, несколько функций Azure Monitor совместно работают, чтобы обеспечить полноценный мониторинг кластеров Azure Kubernetes Service (AKS). В этой статье описывается, как включить следующие функции для кластеров AKS:

  • Метрики Prometheus
  • Управляемая платформа Grafana
  • Ведение журнала контейнеров
  • Журналы контрольной плоскости

Предварительные условия

Это важно

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

Создание рабочих областей

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

Функция Рабочая область Примечания.
Управляемый Prometheus рабочая область Azure Monitor Если при подключении не указать существующую рабочую область Azure Monitor, используется рабочая область по умолчанию для группы ресурсов. Если рабочая область по умолчанию еще не существует в регионе кластера, одна с именем в формате DefaultAzureMonitorWorkspace-<mapped_region> создается в группе ресурсов с именем DefaultRG-<cluster_region>.

Этого разрешения Contributor достаточно для включения надстройки, чтобы отправлять данные в рабочую область Azure Monitor. Для того чтобы связать рабочую область Azure Monitor и просматривать метрики в Управление Azure для Grafana, требуется разрешение уровня Owner. Это необходимо, так как пользователь, выполняющий шаг подключения, должен иметь возможность предоставить роль Управление Azure для Grafana System Identity Monitoring Reader в рабочей области Azure Monitor для запроса метрик.
Ведение журнала контейнеров
Журналы контрольной плоскости
Аналитика контейнеров		 рабочая область Log Analytics Кластер можно подключить к рабочей области Log Analytics в другой подписке Azure в том же клиенте Microsoft Entra, но необходимо использовать Azure CLI или шаблон Azure Resource Manager. В настоящее время эту конфигурацию нельзя выполнить с помощью портала Azure.

Если вы подключаете существующий кластер к рабочей области Log Analytics в другой подписке, Майкрософт. ContainerService поставщик ресурсов должен быть зарегистрирован в подписке в рабочей области Log Analytics. Дополнительные сведения см. в разделе Регистрация поставщика ресурсов.

Если вы не указываете существующую рабочую область Log Analytics, используется рабочая область по умолчанию для группы ресурсов. Если рабочая область по умолчанию еще не существует в регионе кластера, она создается с именем в формате DefaultWorkspace-<GUID>-<Region>.

Список поддерживаемых пар сопоставлений, используемых для рабочей области по умолчанию, см. в разделе Сопоставление регионов, поддерживаемое Container Insights. Чтобы получить руководство по настройке рабочей области с использованием периметра безопасности сети, см. Настройка Azure Monitor с периметром безопасности сети.
Управляемая платформа Grafana Пространство Управление Azure для Grafana Link your Grafana workspace to your Azure Monitor workspace, чтобы сделать метрики Prometheus, собранные из кластера, доступными для панелей мониторинга Grafana.

Метрики Prometheus и аналитика контейнеров

Примечание.

Использование Application Insights для мониторинга приложений, работающих в вашем кластере AKS, с использованием протокола OpenTelemetry (OTLP) для инструментирования и сбора данных теперь находится в общедоступной предварительной версии. См. раздел "Мониторинг приложений AKS" с помощью ограниченной предварительной версии протокола OpenTelemetry (OTLP).

При включении аналитики Prometheus и аналитики контейнеров в кластере устанавливается версия агента Azure Monitor в контейнере. Эти функции можно настроить одновременно в новом или существующем кластере или включить каждую функцию отдельно.

Включите управляемую Grafana для кластера параллельно с включением сбора метрик Prometheus. Сведения о подключении рабочей области Azure Monitor и рабочей области Управление Azure для Grafana см. в статье Link a Grafana workspace.

Предварительные условия

  • Кластер должен использовать аутентификацию с использованием управляемой учётной записи.
  • Следующие поставщики ресурсов должны быть зарегистрированы в подписке кластера и рабочей области Azure Monitor:
    • Майкрософт. ContainerService
    • Майкрософт. Идеи
    • Майкрософт. AlertsManagement
    • Майкрософт. Монитор
  • Следующие поставщики ресурсов должны быть зарегистрированы в подписке рабочей области Grafana:
    • Майкрософт.Dashboard
  • Проверка подлинности управляемого удостоверения по умолчанию используется в CLI версии 2.49.0 или более поздней.
  • Расширение aks-preview необходимо удалить из кластеров AKS с помощью команды az extension remove --name aks-preview.

Включение метрик Prometheus в кластере AKS

Включите метрики Prometheus в кластере AKS, используя опцию --enable-azure-monitor-metrics с командой az aks create для нового кластера или командой az aks update для существующего кластера. Этот параметр использует конфигурацию, описанную в конфигурации метрик по умолчанию Prometheus в Azure Monitor. Чтобы изменить эту конфигурацию, см. раздел Настройка сбора метрик Prometheus в управляемой службе Azure Monitor для Prometheus.

Команды для примера:

### Use default Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group>

### Use existing Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <azure-monitor-workspace-name-resource-id> --grafana-resource-id  <grafana-workspace-name-resource-id>

### Use optional parameters
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --ksm-metric-labels-allow-list "namespaces=[k8s-label-1,k8s-label-n]" --ksm-metric-annotations-allow-list "pods=[k8s-annotation-1,k8s-annotation-n]"

Необязательные параметры

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

Параметр Имя и описание
Ключи аннотаций --ksm-metric-annotations-allow-list

Список разделенных запятыми ключей аннотаций Kubernetes, используемых в метрике ресурса kube_resource_annotations. Например, kube_pod_annotations — это метрика заметок для ресурса pod. По умолчанию эта метрика содержит только метки имени и пространства имен. Чтобы включить дополнительные заметки, укажите список имён ресурсов в их множественном числе и ключи заметок Kubernetes, разрешённые для них. Для каждого ресурса можно предоставить только один *, чтобы допускать любые аннотации, но это серьезно влияет на производительность. Например, pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
Ключи меток --ksm-metric-labels-allow-list

Разделенный запятыми список дополнительных ключей меток Kubernetes, используемых в метрике kube_resource_labels ресурса. Например, kube_pod_labels — это метрика меток для ресурса pod. По умолчанию эта метрика содержит только метки имени и пространства имен. Для включения дополнительных меток предоставьте список имен ресурсов во множественном числе и ключи меток Kubernetes, которые вы хотите разрешить для них. Для каждого ресурса можно предоставить отдельный *, чтобы разрешить любые метки, но это может вызвать серьёзные проблемы с производительностью. Например, pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],....
Правила записи --enable-windows-recording-rules

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

Примечание.

Набор параметров с использованием --ksm-metric-annotations-allow-list и --ksm-metric-labels-allow-list может быть переопределен или альтернативно задан с помощью ama-metrics-settings-configmap.

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

Включите аналитику контейнеров и ведение журнала контейнеров в кластере AKS с помощью команды az aks create для нового кластера или команды az aks enable-addon для обновления существующего кластера.

Команды для примера:

### Use default Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name>

### Use existing Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id>

### Use custom log configuration file
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --data-collection-settings dataCollectionSettings.json

Файл конфигурации журнала

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

{
  "interval": "1m",
  "namespaceFilteringMode": "Include",
  "namespaces": ["kube-system"],
  "enableContainerLogV2": true, 
  "streams": ["Microsoft-Perf", "Microsoft-ContainerLogV2"]
}

В следующей таблице описаны все параметры в файле конфигурации журнала:

Имя Описание
interval Определяет частоту сбора данных агентом. Допустимые значения равны 1 млн - 30 млн в интервалах 1 млн , если значение выходит за пределы допустимого диапазона, то по умолчанию значение по умолчанию составляет 1 млн.

Значение по умолчанию: 1 м.
namespaceFilteringMode Включить: собирает только данные из значений в поле пространств имен.
Исключить: Собирает данные из всех пространств имен, за исключением значений в поле пространств имен.
Off: игнорирует выбранные пространства имен и собирает данные во всех пространствах имен.

Значение по умолчанию: выключение
namespaces Массив пространств имен Kubernetes, разделенных запятыми, для сбора данных об инвентаризации и производительности на основе namespaceFilteringMode.
Например, пространства имен = ["kube-system", "default"] с параметром Include собирают только эти два пространства имен. С параметром Исключить агент собирает данные из всех других пространств имен, за исключением kube-system и default. С параметром Off агент собирает данные из всех пространств имен, включая kube-system и по умолчанию. Недопустимые и неопознанные пространства имен игнорируются.

Нет.
enableContainerLogV2 Логический флаг для активации схемы ContainerLogV2. Если задано значение true, отправляются журналы stdout/stderr в таблицу ContainerLogV2. В противном случае журналы контейнеров отправляются в таблицу ContainerLog , если иное не указано в ConfigMap. При указании отдельных потоков необходимо включить соответствующую таблицу для ContainerLog или ContainerLogV2.

Значение по умолчанию: True
streams Массив потоков таблиц для сбора. Ознакомьтесь со значениями Stream для списка допустимых потоков и соответствующих таблиц.

По умолчанию: Майкрософт-ContainerInsights-Group-Default

Потоковые значения

При указании таблиц для сбора с помощью CLI или BICEP/ARM необходимо указать имена потоков, соответствующие определенным таблицам в рабочей области Log Analytics. В следующей таблице перечислены имена потоков и соответствующая таблица.

Примечание.

Если вы знакомы со структурой правила сбора данных, имена потоков в этой таблице указываются в разделе потоков данных DCR.

Stream Таблица аналитики контейнеров
Майкрософт-ContainerInventory ContainerInventory
Майкрософт-ContainerLog ContainerLog
Майкрософт-ContainerLogV2 ContainerLogV2
Майкрософт-ContainerLogV2-HighScale ContainerLogV2 (режим высокой шкалы)1
Майкрософт-ContainerNodeInventory Инвентарь контейнерного узла
Майкрософт-InsightsMetrics InsightsMetrics
Майкрософт-KubeEvents KubeEvents
Майкрософт-KubeMonAgentEvents KubeMonAgentEvents
Майкрософт-KubeNodeInventory KubeNodeInventory
Майкрософт-KubePodInventory KubePodInventory
Майкрософт-KubePVInventory KubePVInventory
Майкрософт-KubeServices KubeServices
Майкрософт-Perf Перф
Майкрософт-ContainerInsights-Group-Default Группировать поток, включающий все перечисленные выше потоки. 2

1 Не используйте одновременно Майкрософт-ContainerLogV2 и Майкрософт-ContainerLogV2-HighScale. Это приведет к тому, что данные будут повторяться. 2 Используйте поток группы в качестве сокращения, чтобы указать всех отдельных потоков. Если вы хотите собрать определенный набор потоков, укажите каждый поток отдельно вместо использования группового потока.

Применимые таблицы и метрики

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

Имя таблицы Интервал? Пространство имен? Замечания
ContainerInventory Да Да
Инвентарь контейнерного узла Да нет Параметр сбора данных для пространств имен не применяется, так как узел Kubernetes не является ресурсом с областью действия пространства имен
KubeNodeInventory Да нет Параметр сбора данных для пространств имен неприменим, так как узлы Kubernetes не являются ресурсами с областью видимости пространства имен.
KubePodInventory Да Да
KubePVInventory Да Да
KubeServices Да Да
KubeEvents нет Да Параметр сбора данных для интервала не применим для событий Kubernetes
Перф Да Да Настройка сбора данных для пространств имен неприменима к метрикам, связанным с узлом Kubernetes, так как узел Kubernetes не является объектом с областью имен.
InsightsMetrics Да Да Параметры сбора данных применимы только для метрик, собирающих следующие пространства имен: container.azm.ms/kubestate, container.azm.ms/pvи container.azm.ms/gpu.

Примечание.

Фильтрация пространства имен не применяется к записям агента ama-logs. В результате, даже если пространство имен kube-system указано в числе исключенных пространств имен, записи, связанные с контейнером агента ama-logs, по-прежнему принимаются.

Пространство имен метрик Интервал? Пространство имен? Замечания
Взаимосвязи.контейнер/узлы Да нет Узел не является ресурсом, имеющим область действия в рамках пространства имён
Insights.Контейнер/Подсистемы Да Да
Insights.контейнер/контейнеры Да Да
Insights.container/persistentvolumes Да Да

Специальные сценарии

Используйте следующие ресурсы для требований к конфигурации для определенных сценариев:

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

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

Используйте команду az monitor diagnostic-settings create для создания параметра диагностики с помощью Azure CLI. См. документацию по этой команде для описания его параметров.

В следующем примере создается параметр диагностики, который отправляет все категории Kubernetes в рабочую область Log Analytics. К ним относится режим, специфичный для ресурса, для отправки журналов в определенные таблицы, перечисленные в поддерживаемых журналах ресурсов для Майкрософт.ContainerService/fleets.

az monitor diagnostic-settings create \
--name 'Collect control plane logs' \
--resource  /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ContainerService/managedClusters/<cluster-name> \
--workspace /subscriptions/<subscription ID>/resourcegroups/<resource group name>/providers/microsoft.operationalinsights/workspaces/<log analytics workspace name> \
--logs '[{"category": "karpenter-events","enabled": true},{"category": "kube-audit","enabled": true},
{"category": "kube-apiserver","enabled": true},{"category": "kube-audit-admin","enabled": true},{"category": "kube-controller-manager","enabled": true},{"category": "kube-scheduler","enabled": true},{"category": "cluster-autoscaler","enabled": true},{"category": "cloud-controller-manager","enabled": true},{"category": "guard","enabled": true},{"category": "csi-azuredisk-controller","enabled": true},{"category": "csi-azurefile-controller","enabled": true},{"category": "csi-snapshot-controller","enabled": true},{"category": "fleet-member-agent","enabled": true},{"category": "fleet-member-net-controller-manager","enabled": true},{"category": "fleet-mcs-controller-manager","enabled": true}]'
--metrics '[{"category": "AllMetrics","enabled": true}]' \
--export-to-resource-specific true

Включение метрик Windows (предварительная версия)

Сбор метрик Windows включен для кластеров AKS, начиная с версии 6.4.0-main-02-22-2023-3ee44b9e контейнера надстройки управляемого Prometheus. Подключение надстройки Azure Monitor Metrics позволяет Windows DaemonSet модулям pod запускаться в ваших пулах узлов. Поддерживаются Windows Server 2019 и Windows Server 2022. Выполните следующие действия, чтобы разрешить подам собирать метрики для своих пулов узлов Windows.

Примечание.

В windows-exporter-daemonset.yaml нет ограничений по ЦП/памяти, поэтому он может перегрузить узлы Windows. Дополнительные сведения см. в разделе "Резервирование ресурсов"

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

Установка экспортера Windows

Вручную установите windows-exporter на узлы AKS, чтобы получить доступ к метрикам Windows, развернув файл windows-exporter-daemonset YAML. Включите следующие сборщики. Дополнительные сведения о сборщиках см. в разделе Экспортер Prometheus для метрик Windows.

  • [defaults]
    • container
    • memory
    • process
    • cpu_info

Разверните файл windows-exporter-daemonset YAML. Если в узле применены какие-либо пятна, необходимо применить соответствующие терпимости.

kubectl apply -f windows-exporter-daemonset.yaml

Включение метрик Windows

Установите логические значения windowsexporter и windowskubeproxy в true в параметрах конфигурации метрик ConfigMap и примените его к кластеру. См . раздел "Настройка коллекции метрик Prometheus" из кластера Kubernetes с помощью ConfigMap.

Включение правил записи

Включите правила записи, необходимые для встроенных панелей мониторинга:

  • При подключении с помощью командной строки добавьте опцию --enable-windows-recording-rules.
  • При подключении с помощью шаблона ARM, Bicep или Политика Azure задайте enableWindowsRecordingRules на true в файле параметров.
  • Если кластер уже подключен, используйте шаблон ARM this ARM и файл параметров this для создания групп правил. Это добавляет необходимые правила записи и не является операцией ARM в кластере и не влияет на текущее состояние мониторинга кластера.

Проверка развертывания

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

Управляемый Prometheus

Убедитесь, что daemonSet был развернут правильно в пулах узлов Linux

kubectl get ds ama-metrics-node --namespace=kube-system

Количество podов должно быть равно количеству узлов Linux в кластере. Выходные данные должны выглядеть примерно так:

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-node   1         1         1       1            1           <none>          10h

Убедитесь, что Windows узлы развернуты правильно

kubectl get ds ama-metrics-win-node --namespace=kube-system

Число модулей pod должно быть равно числу узлов Windows в кластере. Выходные данные должны выглядеть примерно так:

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME                   DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-win-node   3         3         3       3            3           <none>          10h

Убедитесь, что два ReplicaSets были развернуты для Prometheus

kubectl get rs --namespace=kube-system

Выходные данные должны выглядеть примерно так:

User@aksuser:~$kubectl get rs --namespace=kube-system
NAME                            DESIRED   CURRENT   READY   AGE
ama-metrics-5c974985b8          1         1         1       11h
ama-metrics-ksm-5fcf8dffcd      1         1         1       11h

Аналитика контейнеров и ведение журнала

Убедитесь, что daemonSets были развернуты правильно в пулах узлов Linux

kubectl get ds ama-logs --namespace=kube-system

Количество podов должно быть равно количеству узлов Linux в кластере. Выходные данные должны выглядеть примерно так:

User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-logs   2         2         2         2            2           <none>          1d

Проверьте, что узлы Windows были развернуты правильно

kubectl get ds ama-logs-windows --namespace=kube-system

Число модулей pod должно быть равно числу узлов Windows в кластере. Выходные данные должны выглядеть примерно так:

User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR     AGE
ama-logs-windows           2         2         2         2            2       <none>            1d

Проверка развертывания решения для ведения журнала контейнеров

kubectl get deployment ama-logs-rs --namespace=kube-system

Выходные данные должны выглядеть примерно так:

User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d

Просмотр конфигурации с помощью CLI

Используйте команду aks show, чтобы узнать, включена ли решение, идентификатор ресурса рабочей области Log Analytics и сводная информация о кластере.

az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>

Команда возвращает данные в формате JSON о решении. Этот addonProfiles раздел должен содержать сведения о omsagent как в следующем примере.

"addonProfiles": {
    "omsagent": {
        "config": {
            "logAnalyticsWorkspaceResourceID": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
            "useAADAuth": "true"
        },
        "enabled": true,
        "identity": null
    },
}

Связанный контент

  • Last updated on