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

Включение мониторинга для кластеров Kubernetes

  • Статья

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

С помощью портал Azure можно включить все функции одновременно. Вы также можете включить их по отдельности с помощью Azure CLI, шаблона Azure Resource Manager, Terraform или Политика Azure. Каждый из этих методов описан в этой статье.

Внимание

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

Поддерживаемые кластеры

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

Необходимые компоненты

Разрешения

Предварительные требования для управляемого prometheus

  • Кластер должен использовать проверку подлинности управляемого удостоверения.
  • Следующие поставщики ресурсов должны быть зарегистрированы в подписке кластера AKS и рабочей области Azure Monitor:
    • Microsoft.ContainerService
    • Microsoft.Insights
    • Microsoft.AlertsManagement
    • Microsoft.Monitor
  • Следующие поставщики ресурсов должны быть зарегистрированы в подписке подписки рабочей области Grafana:
    • Microsoft.Dashboard

Предварительные требования для кластеров Kubernetes с поддержкой Arc

Примечание.

Расширение Kubernetes с поддержкой Managed Prometheus Arc не поддерживает следующие конфигурации:

  • Дистрибутивы Red Hat Openshift, включая Azure Red Hat OpenShift (ARO)
  • Узлы Windows

Рабочие области

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

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

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

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

Включение Prometheus и Grafana

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

Примечание.

Если у вас есть один ресурс Azure Monitor, связанный с частным, включение Prometheus не будет работать, если кластер AKS и рабочая область Azure Monitor находятся в разных регионах. Конфигурация, необходимая для надстройки Prometheus, недоступна в разных регионах из-за ограничения приватного канала. Чтобы устранить эту проблему, создайте новый DCE в расположении кластера AKS и новую DCRA (ассоциацию) в том же регионе кластера AKS. Свяжите новый DCE с кластером AKS и назовите новую ассоциацию (DCRA) в качестве configurationAccessEndpoint. Полные инструкции по настройке контроллеров домена, связанных с рабочей областью Azure Monitor, для использования Приватный канал для приема данных, см. в статье "Включение приватного канала для мониторинга Kubernetes в Azure Monitor".

Включение с помощью интерфейса командной строки

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

Необходимые компоненты

  • Требуется az CLI версии 2.49.0 или более поздней.
  • Расширение aks-preview должно быть удалено из кластеров AKS с помощью команды az extension remove --name aks-preview.
  • Расширение k8s-extension должно быть установлено с помощью команды az extension add --name k8s-extension.
  • Требуется расширение k8s версии 1.4.1 или более поздней.

Кластер AKS

-enable-azure-monitor-metrics Используйте параметр az aks create az aks update или (в зависимости от того, создаете ли вы новый кластер или обновляете существующий кластер), чтобы установить надстройку метрик, которая удаляет метрики 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]"

Кластер с поддержкой Arc

### Use default Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics

## Use existing Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id>

### Use optional parameters
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id> AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList="pods=[k8s-annotation-1,k8s-annotation-n]" AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist "namespaces=[k8s-label-1,k8s-label-n]"

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

  • AKS: --ksm-metric-annotations-allow-list
    Дуга: --AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList
    Разделенный запятыми список ключей заметок Kubernetes, используемых в метрике kube_resource_annotations ресурса. Например, kube_pod_annotations — это метрика заметок для ресурса pod. По умолчанию эта метрика содержит только метки имени и пространства имен. Чтобы включить дополнительные заметки, укажите список имен ресурсов в их форме множественного числа и ключи заметок Kubernetes, которые необходимо разрешить для них. Один * из них можно предоставить для каждого ресурса, чтобы разрешить любые заметки, но это имеет серьезные последствия для производительности. Например, pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
  • AKS: --ksm-metric-labels-allow-list
    Дуга: --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist
    Разделенный запятыми список дополнительных ключей меток Kubernetes, используемых в метрике kube_resource_labels ресурса kube_resource_labels метрике. Например, kube_pod_labels — это метрика меток для ресурса pod. По умолчанию эта метрика содержит только метки имени и пространства имен. Чтобы включить дополнительные метки, укажите список имен ресурсов в их форме множественного числа и ключи меток Kubernetes, которые необходимо разрешить для них один ресурс * , чтобы разрешить любые метки, но у меня это имеет серьезные последствия для производительности. Например, pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],....
  • AKS: --enable-windows-recording-rules позволяет включить группы правил записи, необходимые для правильного функционирования панелей мониторинга Windows.

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

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

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

Необходимые компоненты

  • Azure CLI версии 2.43.0 или более поздней
  • Проверка подлинности управляемого удостоверения по умолчанию используется в CLI версии 2.49.0 или более поздней.
  • Расширение Azure k8s версии 1.3.7 или более поздней
  • Проверка подлинности управляемого удостоверения — это по умолчанию в k8s-extension версии 1.43.0 или более поздней.
  • Проверка подлинности управляемого удостоверения не поддерживается для кластеров Kubernetes с поддержкой Arc с помощью ARO (Azure Red Hat Openshift) или узлов Windows. Используйте устаревшую проверку подлинности.
  • Для ИНТЕРФЕЙСА командной строки версии 2.54.0 или выше схема ведения журнала будет настроена для ContainerLogV2 с помощью ConfigMap.

Примечание.

Схему ContainerLogV2 для кластера можно включить с помощью правила сбора данных кластера (DCR) или ConfigMap. Если оба параметра включены, ConfigMap будет иметь приоритет. Журналы Stdout и stderr будут приема только в таблицу ContainerLog, если DCR и ConfigMap явно настроены.

Кластер AKS

### 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 legacy authentication
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --enable-msi-auth-for-monitoring false

Пример

az aks enable-addons --addon monitoring --name "my-cluster" --resource-group "my-resource-group" --workspace-resource-id "/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Кластер с поддержкой Arc

### Use default Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers

### Use existing Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID=<workspace-resource-id>

### Use managed identity authentication (default as k8s-extension version 1.43.0)
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=true

### Use advanced configuration settings
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings  amalogs.resources.daemonset.limits.cpu=150m amalogs.resources.daemonset.limits.memory=600Mi amalogs.resources.deployment.limits.cpu=1 amalogs.resources.deployment.limits.memory=750Mi

### With custom mount path for container stdout & stderr logs
### Custom mount path not required for Azure Stack Edge version > 2318. Custom mount path must be /home/data/docker for Azure Stack Edge cluster with version <= 2318
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.logsettings.custommountpath=<customMountPath>

См. раздел "Запросы и ограничения ресурсов" диаграммы Helm для доступных параметров конфигурации.

Пример

az k8s-extension create --name azuremonitor-containers --cluster-name "my-cluster" --resource-group "my-resource-group" --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID="/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Кластер с поддержкой Arc с прокси-сервером с поддержкой Arc

Если кластер настроен с помощью перенаправленного прокси-сервера, то параметры прокси-сервера автоматически применяются к расширению. В случае кластера с AMPLS +proxy следует игнорировать конфигурацию прокси-сервера. Подключение расширения с параметром amalogs.ignoreExtensionProxySettings=trueконфигурации.

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.ignoreExtensionProxySettings=true

Кластер с поддержкой Arc с узлами ARO или OpenShift или Windows

Проверка подлинности управляемого удостоверения не поддерживается для кластеров Kubernetes с поддержкой Arc с помощью ARO (Azure Red Hat OpenShift) или Узлов Windows или OpenShift. Используйте устаревшую проверку подлинности, указав amalogs.useAADAuth=false в следующем примере.

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=false

Удаление экземпляра расширения

Следующая команда удаляет только экземпляр расширения, но не удаляет рабочую область Log Analytics. Данные в ресурсе Log Analytics остаются нетронутыми.

az k8s-extension delete --name azuremonitor-containers --cluster-type connectedClusters --cluster-name <cluster-name> --resource-group <resource-group>

Включение полного мониторинга с помощью портал Azure

Новый кластер AKS (Prometheus, аналитика контейнеров и Grafana)

При создании кластера AKS в портал Azure можно включить Prometheus, аналитику контейнеров и Grafana на вкладке "Мониторинг". Убедитесь, что вы проверьте метрики "Включить контейнеры", "Включить метрики Prometheus" и "Включить флажки Grafana".

Снимок экрана: вкладка

Существующий кластер (Prometheus, аналитика контейнеров и Grafana)

  1. Перейдите к своему кластеру AKS на портале Azure.
  2. В меню службы в разделе "Мониторинг" выберите "Настройка мониторинга Аналитики>".
  3. Аналитика контейнеров уже включена. Установите флажки "Включить Prometheus" и установите флажки Grafana. Если у вас есть рабочая область Azure Monitor и рабочая область Grafana, они будут выбраны для вас.
  4. Выберите дополнительные параметры , если вы хотите выбрать альтернативные рабочие области или создать новые. Параметр предустановок затрат позволяет изменять сведения о коллекции по умолчанию, чтобы снизить затраты на мониторинг. Дополнительные сведения см. в разделе "Включение параметров оптимизации затрат" в аналитике контейнеров.
  5. Выберите Настроить.

Существующий кластер (только Prometheus)

  1. Перейдите к своему кластеру AKS на портале Azure.
  2. В меню службы в разделе "Мониторинг" выберите "Настройка мониторинга Аналитики>".
  3. Установите флажок "Включить метрики Prometheus".
  4. Выберите дополнительные параметры , если вы хотите выбрать альтернативные рабочие области или создать новые. Параметр предустановок затрат позволяет изменять сведения о коллекции по умолчанию, чтобы снизить затраты на мониторинг.
  5. Выберите Настроить.

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

Примечание.

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

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

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

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

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

    Дополнительные сведения о сборщиках см. в статье "Экспортер Prometheus" для метрик Windows.

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

        kubectl apply -f windows-exporter-daemonset.yaml

  2. Примените к кластеру карту ama-metrics-settings-configmap . Задайте для trueлогических значений .windowsexporter windowskubeproxy Дополнительные сведения см. в разделе Metrics add-on settings configmap.

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

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

Убедитесь, что два набора реплик были развернуты для 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/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
            "useAADAuth": "true"
        },
        "enabled": true,
        "identity": null
    },
}

Ресурсы подготовлены

При включении мониторинга в подписке создаются следующие ресурсы:

Имя ресурса Тип ресурса Группа ресурсов Регион или расположение Description
MSCI-<aksclusterregion>-<clustername> Правило сбора данных То же, что и кластер То же, что и рабочая область Log Analytics Это правило сбора данных предназначено для сбора журналов агентом Azure Monitor, который использует рабочую область Log Analytics в качестве назначения и связан с ресурсом кластера AKS.
MSPROM-<aksclusterregion>-<clustername> Правило сбора данных То же, что и кластер То же, что и рабочая область Azure Monitor Это правило сбора данных предназначено для сбора метрик prometheus с помощью надстройки метрик, которая имеет выбранную рабочую область Azure Monitor в качестве назначения, а также связана с ресурсом кластера AKS
MSPROM-<aksclusterregion>-<clustername> Конечная точка сбора данных То же, что и кластер То же, что и рабочая область Azure Monitor Эта конечная точка сбора данных используется приведенным выше правилом сбора данных для приема метрик Prometheus из надстройки метрик

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

Имя ресурса Тип ресурса Группа ресурсов Регион или расположение Description
<azuremonitor-workspace-name> Правило сбора данных <MA_azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed То же, что и рабочая область Azure Monitor DCR, созданный при использовании сервера OSS Prometheus для удаленной записи в рабочую область Azure Monitor.
<azuremonitor-workspace-name> Конечная точка сбора данных <MA_azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed То же, что и рабочая область Azure Monitor DCE, созданный при использовании сервера OSS Prometheus для удаленной записи в рабочую область Azure Monitor.

Различия между кластерами Windows и Linux

Ниже приведены основные отличия мониторинга кластера Windows Server от мониторинга кластера Linux.

  • Windows не имеет метрики RSS памяти. В результате он недоступен для узлов и контейнеров Windows. Доступна метрика рабочего набора.
  • Сведения о емкости хранилища диска недоступны для узлов Windows.
  • Отслеживаются только среды Pod, а не среды DOCKER.
  • В предварительной версии поддерживается не более 30 контейнеров Windows Server. Это ограничение не распространяется на контейнеры Linux.

Примечание.

Поддержка аналитики контейнеров для операционной системы Windows Server 2022 доступна в предварительной версии.

Контейнерный агент Linux (pod реплики) вызывает API ко всем узлам Windows в безопасном порту Kubelet (10250) в кластере для сбора метрик производительности узлов и контейнеров. Безопасный порт Kubelet (:10250) должен быть открыт в виртуальной сети кластера как для входящих, так и исходящих подключений для сбора метрик, связанных с производительностью узлов Windows и контейнеров.

Если у вас есть кластер Kubernetes с узлами Windows, просмотрите и настройте группу безопасности сети и политики сети, чтобы убедиться, что безопасный порт Kubelet (:10250) открыт для входящего и исходящего трафика в виртуальной сети кластера.

Следующие шаги

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