С помощью портал Azure можно включить все функции одновременно. Вы также можете включить их по отдельности с помощью Azure CLI, шаблона Azure Resource Manager, Terraform или Политика Azure. Каждый из этих методов описан в этой статье.
Важно!
Кластеры Kubernetes создают большое количество данных журнала, что может привести к значительным затратам, если вы не выборочно о собираемых журналах. Прежде чем включить мониторинг кластера, ознакомьтесь со следующими статьями, чтобы убедиться, что среда оптимизирована для затрат и что вы ограничиваете сбор журналов только нужными данными:
Оптимизация затрат в Azure Monitor Рекомендации по настройке всех функций Azure Monitor для оптимизации затрат и ограничения объема собираемых данных.
Поддерживаемые кластеры
В этой статье приводятся рекомендации по подключению для следующих типов кластеров. Все различия в процессе каждого типа отмечаются в соответствующих разделах.
Если вы ранее настроили мониторинг для AKS, обязательно отключите его перед продолжением, чтобы избежать проблем во время установки расширения.
Если вы ранее установили мониторинг в кластере с помощью скрипта без расширений кластера, выполните инструкции по отключению мониторинга кластера Kubernetes, чтобы удалить эту диаграмму Helm.
Примечание
Расширение Kubernetes с поддержкой Arc с поддержкой Managed Prometheus (предварительная версия) не поддерживает следующие конфигурации:
Дистрибутивы Red Hat Openshift, включая Azure Red Hat OpenShift (ARO)
Узлы Windows
Рабочие области
В следующей таблице описаны рабочие области, необходимые для поддержки управляемого prometheus и аналитики контейнеров. Вы можете создать каждую рабочую область как часть процесса подключения или использовать существующую рабочую область. См. инструкции по созданию и расположению рабочих областей в архитектуре рабочей области Log Analytics.
Contributor достаточно разрешений, чтобы добавить надстройку для отправки данных в рабочую область Azure Monitor. Вам потребуется Owner разрешение уровня для связывания рабочей области Azure Monitor для просмотра метрик в Управляемой Grafana Azure. Это необходимо, так как пользователь, выполняющий шаг подключения, должен иметь возможность предоставить роль управляемого удостоверения системы Monitoring Reader Grafana в рабочей области Azure Monitor для запроса метрик.
Кластер AKS можно подключить к рабочей области Log Analytics в другой подписке Azure в том же клиенте Microsoft Entra, но необходимо использовать Azure CLI или шаблон Azure Resource Manager. В настоящее время эту конфигурацию невозможно выполнить с помощью портал Azure.
Если вы подключаете существующий кластер AKS к рабочей области Log Analytics в другой подписке, поставщик ресурсов Microsoft.ContainerService должен быть зарегистрирован в подписке в рабочей области Log Analytics. Дополнительные сведения см. в разделе Регистрация поставщика ресурсов.
Используйте один из следующих методов, чтобы включить очистку метрик 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 createaz aks update или (в зависимости от того, создаете ли вы новый кластер или обновляете существующий кластер), чтобы установить надстройку метрик, которая удаляет метрики Prometheus.
Примеры команд
Azure CLI
### Use default Azure Monitor workspaceaz aks create/update --enable-azure-monitor-metrics--name<cluster-name>--resource-group<cluster-resource-group>### Use existing Azure Monitor workspaceaz 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 workspaceaz 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 parametersaz 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 (предварительная версия)
Azure CLI
### Use default Azure Monitor workspaceaz 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 workspaceaz 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 workspaceaz 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 parametersaz 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.
Включение с помощью шаблонов ARM
Необходимые компоненты
Рабочая область Azure Monitor и экземпляр Azure Managed Grafana уже должны быть созданы.
Шаблон должен быть развернут в той же группе ресурсов, что и экземпляр Управляемой Grafana Azure.
Если экземпляр Azure Managed Grafana находится в подписке, отличной от подписки рабочей области Azure Monitor, зарегистрируйте подписку рабочей области Azure Monitor с Microsoft.Dashboard поставщиком ресурсов, используя рекомендации по регистрации поставщика ресурсов.
Пользователи с User Access Administrator ролью в подписке кластера AKS могут включить Monitoring Reader роль непосредственно путем развертывания шаблона.
Примечание
В настоящее время в Bicep нет способа явно ограничить Monitoring Reader назначение роли строковым параметром "идентификатор ресурса" для рабочей области Azure Monitor, как в шаблоне ARM. Bicep ожидает значение типа resource | tenant. Для рабочей области Azure Monitor не существует спецификации REST API.
Таким образом, определение области по умолчанию для Monitoring Reader роли находится в группе ресурсов. Роль применяется в той же рабочей области Azure Monitor по наследованию, что является ожидаемым поведением. После развертывания этого шаблона Bicep экземпляр Grafana получает Monitoring Reader разрешения для всех рабочих областей Azure Monitor в этой группе ресурсов.
Получение необходимых значений для ресурса Grafana
Если экземпляр Управляемой Grafana Azure уже связан с рабочей областью Azure Monitor, необходимо включить этот список в шаблон. На странице "Обзор" для экземпляра Azure Managed Grafana в портал Azure выберите представление JSON и скопируйте значениеazureMonitorWorkspaceIntegrations, которое будет выглядеть примерно так же, как в примере ниже. Если он не существует, экземпляр не связан с рабочей областью Azure Monitor.
Измените следующие значения в файле параметров. Один и тот же набор значений используется как для шаблонов ARM, так и для Bicep. Получите идентификатор ресурса ресурсов из представления JSON страницы обзора .
Параметр
Значение
azureMonitorWorkspaceResourceId
Идентификатор ресурса для рабочей области Azure Monitor. Получите из представления JSON на странице обзора рабочей области Azure Monitor.
azureMonitorWorkspaceLocation
Расположение рабочей области Azure Monitor. Получите из представления JSON на странице обзора рабочей области Azure Monitor.
clusterResourceId
Идентификатор ресурса для кластера AKS. Получите из представления JSON на странице обзора кластера.
clusterLocation
Расположение кластера AKS. Получите из представления JSON на странице обзора кластера.
metricLabelsAllowlist
Разделенный запятыми список ключей меток Kubernetes, используемых в метрике меток ресурса.
metricAnnotationsAllowList
Разделенный запятыми список дополнительных ключей меток Kubernetes, используемых в метрике заметок ресурса.
grafanaResourceId
Идентификатор ресурса для управляемого экземпляра Grafana. Извлекается из представления JSON на странице обзора экземпляра Grafana.
grafanaLocation
Расположение управляемого экземпляра Grafana. Извлекается из представления JSON на странице обзора экземпляра Grafana.
grafanaSku
SKU для управляемого экземпляра Grafana. Извлекается из представления JSON на странице обзора экземпляра Grafana. Используйте sku.name.
Откройте файл шаблона и обновите grafanaIntegrations свойство в конце файла со значениями, полученными из экземпляра Grafana. Это будет выглядеть примерно так, как показано в следующих примерах. В этих примерах full_resource_id_1 и full_resource_id_2 уже находились в json ресурса Azure Managed Grafana. Последняя azureMonitorWorkspaceResourceId запись уже находится в шаблоне и используется для ссылки на идентификатор ресурса рабочей области Azure Monitor, указанный в файле параметров.
Разверните шаблон с помощью файла параметров с помощью любого допустимого метода для развертывания шаблонов Resource Manager. Примеры различных методов см. в разделе "Развертывание примеров шаблонов".
Включение с помощью Terraform
Необходимые компоненты
Рабочая область Azure Monitor и рабочая область Azure Managed Grafana уже должны быть созданы.
Шаблон необходимо развернуть в той же группе ресурсов, что и рабочая область Azure Managed Grafana.
Пользователи с ролью администратора доступа пользователей в подписке кластера AKS могут включить роль средства чтения мониторинга непосредственно путем развертывания шаблона.
Если экземпляр Azure Managed Grafana находится в подписке, отличной от подписки на рабочие области Azure Monitor, зарегистрируйте подписку рабочей области Azure Monitor в Microsoft.Dashboard поставщике ресурсов, следуя этой документации.
Получение необходимых значений для ресурса Grafana
На странице "Обзор" для экземпляра Azure Managed Grafana в портал Azure выберите представление JSON.
Если вы используете существующий экземпляр Azure Managed Grafana, который уже связан с рабочей областью Azure Monitor, вам потребуется список интеграции Grafana. Скопируйте значение azureMonitorWorkspaceIntegrations поля. Если он не существует, экземпляр не был связан с какой-либо рабочей областью Azure Monitor. azure_monitor_workspace_integrations Обновите блок в main.tf списке интеграции grafana.
Измените переменные в файле variables.tf с правильными значениями параметров.
Выполните, terraform init -upgrade чтобы инициализировать развертывание Terraform.
Выполните, terraform plan -out main.tfplan чтобы инициализировать развертывание Terraform.
Выполните команду terraform apply main.tfplan , чтобы применить план выполнения к облачной инфраструктуре.
Примечание. Передайте переменные и annotations_allowedlabels_allowed ключи в main.tf только в том случае, если эти значения существуют. Это необязательные блоки.
Примечание
Перед запуском шаблона terraform измените файл main.tf соответствующим образом. Добавьте все существующие значения azure_monitor_workspace_integrations в ресурс grafana перед запуском шаблона. Кроме того, старые значения удаляются и заменяются тем, что есть в шаблоне во время развертывания. Пользователи с ролью "Администратор доступа пользователей" в подписке кластера AKS могут включить роль "Читатель мониторинга" непосредственно путем развертывания шаблона. Измените параметр grafanaSku, если вы используете нестандартный номер SKU и, наконец, запустите этот шаблон в группе ресурсов Grafana.
Включение с использованием Политики Azure
Скачайте файлы шаблонов и параметров Политика Azure.
После создания определения политики в портал Azure выберите "Политика" и "Определения". Выберите созданное определение политики.
Выберите "Назначить" и введите сведения на вкладке "Параметры". Выберите "Рецензирование и создание".
Если вы хотите применить политику к существующему кластеру, создайте задачу исправления для этого ресурса кластера из назначения политики.
После назначения политики подписке всякий раз, когда вы создаете новый кластер без поддержки Prometheus, политика будет запускаться и развертываться для включения мониторинга Prometheus.
Включение службы аналитики контейнеров
Используйте один из следующих методов, чтобы включить аналитику контейнеров в кластере. Когда эта операция будет завершена, ознакомьтесь с разделом Настройка сбора данных агента для аналитики контейнеров, чтобы скорректировать свою конфигурацию и предотвратить сбор лишних данных.
Используйте одну из следующих команд, чтобы включить мониторинг кластеров с поддержкой 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
Azure CLI
### Use default Log Analytics workspaceaz aks enable-addons --addon monitoring --name<cluster-name>--resource-group<cluster-resource-group-name>### Use existing Log Analytics workspaceaz aks enable-addons --addon monitoring --name<cluster-name>--resource-group<cluster-resource-group-name>--workspace-resource-id<workspace-resource-id>### Use legacy authenticationaz aks enable-addons --addon monitoring --name<cluster-name>--resource-group<cluster-resource-group-name>--workspace-resource-id<workspace-resource-id>--enable-msi-auth-for-monitoringfalse
Пример
Azure CLI
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
Azure CLI
### Use default Log Analytics workspaceaz 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 workspaceaz 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 settingsaz 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 <= 2318az 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>
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конфигурации.
Azure CLI
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 в следующем примере.
Azure CLI
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 остаются нетронутыми.
Azure CLI
az k8s-extension delete --name azuremonitor-containers--cluster-type connectedClusters --cluster-name<cluster-name>--resource-group<resource-group>
Шаблоны ARM и Bicep представлены в этом разделе.
Необходимые компоненты
Шаблон должен быть развернут в той же группе ресурсов, что и кластер.
Измените следующие значения в файле параметров. Один и тот же набор значений используется как для шаблонов ARM, так и для Bicep. Получите идентификатор ресурса ресурсов из представления JSON страницы обзора .
Идентификатор ресурса рабочей области Log Analytics.
Дуга: workspaceRegion
Регион рабочей области Log Analytics.
Дуга: workspaceDomain
Домен рабочей области Log Analytics. opinsights.azure.com для общедоступного облака Azure opinsights.azure.us для AzureUSGovernment.
AKS: resourceTagValues
Значения тегов, указанные для существующего правила сбора данных расширения Container Insights (DCR) кластера и имени DCR. Имя будет MSCI-<clusterName>-<clusterRegion> и этот ресурс создается в группе ресурсов кластеров AKS. При первом подключении можно задать произвольные значения тегов.
Разверните шаблон с помощью файла параметров с помощью любого допустимого метода для развертывания шаблонов Resource Manager. Примеры различных методов см. в разделе "Развертывание примеров шаблонов".
Новый кластер AKS
Скачайте файл шаблона Terraform в зависимости от того, нужно ли включить коллекцию Syslog.
azurerm_kubernetes_cluster Настройте ресурс в main.tf на основе параметров кластера.
Обновление параметров в variables.tf для замены значений в "<>"
Параметр
Описание
aks_resource_group_name
Используйте значения на странице обзора AKS для группы ресурсов.
resource_group_location
Используйте значения на странице обзора AKS для группы ресурсов.
cluster_name
Определите имя кластера, которое вы хотите создать.
workspace_resource_id
Используйте идентификатор ресурса рабочей области Log Analytics.
workspace_region
Используйте расположение рабочей области Log Analytics.
resource_tag_values
Сопоставляет существующие значения тегов, указанные для существующего правила сбора данных расширения Container Insights (DCR) кластера и имени DCR. Имя будет совпадать MSCI-<clusterName>-<clusterRegion> , и этот ресурс создается в той же группе ресурсов, что и кластеры AKS. При первом подключении можно задать произвольные значения тегов.
enabledContainerLogV2
Задайте для этого значения параметра значение true, чтобы использовать рекомендуемый контейнер ContainerLogV2 по умолчанию.
Копирование ресурсов DCR и DCRA из шаблонов Terraform
Выполните terraform plan -out main.tfplan и убедитесь, что изменение добавляет свойство oms_agent. Примечание. Если определенный ресурс отличается во время плана terraform, существующий azurerm_kubernetes_cluster кластер будет уничтожен и воссоздаен.
Выполните команду terraform apply main.tfplan , чтобы применить план выполнения к облачной инфраструктуре.
Совет
Измените main.tf файл соответствующим образом перед запуском шаблона terraform
Данные начнут поступать через 10 минут, так как кластер должен быть готов сначала
Идентификатор рабочей области должен соответствовать формату /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/example-resource-group/providers/Microsoft.OperationalInsights/workspaces/workspaceValue
Если группа ресурсов уже существует, выполните команду terraform import azurerm_resource_group.rg /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name> до плана terraform
Портал Azure
На вкладке "Определения" меню "Политика" в портал Azure создайте определение политики со следующими сведениями.
Расположение определения: подписка Azure, в которой должно храниться определение политики.
Имя: AKS-Monitoring-Addon
Описание. Настраиваемая политика Azure для включения надстройки мониторинга в кластеры Azure Kubernetes.
Категория. Выберите "Использовать существующий ", а затем Kubernetes из раскрывающегося списка.
После назначения политики подписке всякий раз, когда вы создаете новый кластер без поддержки Prometheus, политика будет запускаться и развертываться для включения мониторинга Prometheus.
Включение полного мониторинга с помощью портал Azure
Новый кластер AKS (Prometheus, аналитика контейнеров и Grafana)
При создании кластера AKS в портал Azure можно включить Prometheus, аналитику контейнеров и Grafana на вкладке "Мониторинг". Убедитесь, что вы проверьте метрики "Включить контейнеры", "Включить метрики Prometheus" и "Включить флажки Grafana".
Существующий кластер (Prometheus, аналитика контейнеров и Grafana)
Перейдите к своему кластеру AKS на портале Azure.
В меню службы в разделе "Мониторинг" выберите "Настройка мониторинга Аналитики>".
Аналитика контейнеров уже включена. Установите флажки "Включить Prometheus" и установите флажки Grafana. Если у вас есть рабочая область Azure Monitor и рабочая область Grafana, они будут выбраны для вас.
Выберите дополнительные параметры , если вы хотите выбрать альтернативные рабочие области или создать новые. Параметр предустановок затрат позволяет изменять сведения о коллекции по умолчанию, чтобы снизить затраты на мониторинг. Дополнительные сведения см. в разделе "Включение параметров оптимизации затрат" в аналитике контейнеров.
Выберите Настроить.
Существующий кластер (только Prometheus)
Перейдите к своему кластеру AKS на портале Azure.
В меню службы в разделе "Мониторинг" выберите "Настройка мониторинга Аналитики>".
Установите флажок "Включить метрики Prometheus".
Выберите дополнительные параметры , если вы хотите выбрать альтернативные рабочие области или создать новые. Параметр предустановок затрат позволяет изменять сведения о коллекции по умолчанию, чтобы снизить затраты на мониторинг.
Выберите Настроить.
Включение коллекции метрик 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.
Вручную установите windows-экспортер на узлах AKS для доступа к метрикам Windows, развернув файл YAML windows-exporter-daemonset. Включите следующие сборщики:
Разверните файл YAML windows-exporter-daemonset. Обратите внимание, что если на узле применены ограничения, необходимо применить соответствующие терпимые действия.
Включите правила записи, необходимые для встроенных панелей мониторинга:
При подключении с помощью интерфейса командной строки включите этот параметр --enable-windows-recording-rules.
При подключении с помощью шаблона ARM, Bicep или Политика Azure задайте значение enableWindowsRecordingRulestrue в файле параметров.
Если кластер уже подключен, используйте этот шаблон ARM и этот файл параметров для создания групп правил. Это добавит необходимые правила записи и не является операцией ARM в кластере и не влияет на текущее состояние мониторинга кластера.
Проверка развертывания
Используйте средство командной строки kubectl, чтобы убедиться, что агент развернут правильно.
Управляемая служба Prometheus
Убедитесь, что daemonSet был развернут правильно в пулах узлов Linux
AzureCLI
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 были развернуты правильно
AzureCLI
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
AzureCLI
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
AzureCLI
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 и сводная информация о кластере.
Azure CLI
az aks show --resource-group<resourceGroupofAKSCluster>--name<nameofAksCluster>
Команда вернет сведения о решении в формате JSON. Этот addonProfiles раздел должен содержать сведения о omsagent следующем примере:
При включении мониторинга в подписке создаются следующие ресурсы:
Имя ресурса
Тип ресурса
Группа ресурсов
Регион или расположение
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 в рамках нее создаются следующие дополнительные ресурсы.
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.
Присоединитесь к серии встреч для создания масштабируемых решений искусственного интеллекта на основе реальных вариантов использования с другими разработчиками и экспертами.