Включение мониторинга для кластеров 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 в другой подписке, Microsoft. 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:
    • Microsoft. ContainerService
    • Microsoft.Insights
    • Microsoft. AlertsManagement
    • Microsoft. Монитор
  • Следующие поставщики ресурсов должны быть зарегистрированы в подписке рабочей области Grafana:
    • Microsoft.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.

Managed Prometheus не собирает автоматически метрики плоскости управления AKS. Чтобы собрать их, также используйте параметр --enable-control-plane-metrics. Метрики плоскости управления отличаются от журналов плоскости управления.

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

### 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]"

### Enable AKS control plane metrics
az aks create --enable-azure-monitor-metrics --enable-control-plane-metrics --name <cluster-name> --resource-group <cluster-resource-group>

az aks update --enable-control-plane-metrics --name <cluster-name> --resource-group <cluster-resource-group>

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

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

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

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

Включает сбор метрик плоскости управления AKS с помощью управляемого Prometheus. Managed Prometheus уже должен быть включен, либо необходимо указать --enable-azure-monitor-metrics в этой же команде. AKS по умолчанию собирает метрики сервера API и etcd. Сведения о других целевых объектах и параметрах конфигурации см. в разделе Мониторинг метрик плоскости управления Служба Azure Kubernetes.
Ключи меток --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 с помощью команды --addon monitoring для нового кластера или команды az aks create для обновления существующего кластера.

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

### 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 для списка допустимых потоков и соответствующих таблиц.

По умолчанию: Microsoft-ContainerInsights-Group-Default

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

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

Примечание.

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

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

1 Не используйте одновременно Microsoft-ContainerLogV2 и Microsoft-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. К ним относится режим, специфичный для ресурса, для отправки журналов в определенные таблицы, перечисленные в поддерживаемых журналах ресурсов для Microsoft.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 поддерживается, начиная с версии 6.4.0-main-02-22-2023-3ee44b9e контейнера надстройки Managed Prometheus. После подключения надстройки метрик Azure Monitor поды Windows DaemonSet начинают выполняться в ваших пулах узлов. Поддерживаются Windows Server 2019 и Windows Server 2022. Выполните следующие действия, чтобы разрешить подам собирать метрики для своих пулов узлов Windows.

Примечание.

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

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

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

Чтобы получить метрики Windows, вручную установите windows-exporter на узлах кластера, развернув файл 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.

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

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

  • Если вы выполняете подключение с помощью CLI, укажите параметр --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

Количество подов должно соответствовать количеству узлов 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

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

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

Количество подов должно соответствовать количеству узлов 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