Activer le monitoring pour des clusters Kubernetes

Article
11/03/2024

Cet article décrit la façon d’effectuer un monitoring complet de vos clusters Kubernetes en utilisant les fonctionnalités Azure Monitor suivantes :

Prometheus managé pour des collections de métriques
Container Insights pour des collections de journaux
Managed Grafana pour la visualisation.

L’utilisation du Portail Azure vous permet d’activer toutes les fonctionnalités en même temps. Vous pouvez les activer individuellement en utilisant l’interface Azure CLI, un modèle Azure Resource Manager, Terraform ou Azure Policy. Chacune de ces méthodes est décrite dans cet article.

Important

Les clusters Kubernetes génèrent un grand nombre de données de journal, ce qui peut entraîner des coûts significatifs si vous ne choisissez pas soigneusement les journaux que vous collectez. Avant d’activer la surveillance de votre cluster, consultez les articles suivants pour vous assurer que votre environnement est optimisé pour les coûts et que vous limitez votre collecte de journaux aux données dont vous avez besoin :

Configurer la collecte de données et l’optimisation des coûts dans Container Insights à l’aide d’une règle de collecte de données
Détails sur la personnalisation de la collecte de journaux une fois que vous avez activé la surveillance, notamment à l’aide de configurations d’optimisation des coûts prédéfinies.
Meilleures pratiques pour la surveillance de Kubernetes avec Azure Monitor
Bonnes pratiques recommandées pour la surveillance des clusters Kubernetes organisés par les cinq piliers du Azure Well-Architected Framework, y compris l’optimisation des coûts.
Optimisation des coûts dans Azure Monitor
Les meilleures pratiques pour configurer toutes les fonctionnalités d’Azure Monitor afin d’optimiser vos coûts et limiter la quantité de données que vous collectez.

Clusters pris en charge

Cet article fournit des conseils sur l’intégration pour les types de cluster suivants. Les différences dans le processus de chaque type sont notées dans les sections appropriées.

Prérequis

autorisations

Vous avez besoin d’au moins un accès Contributeur au cluster pour l’intégration.
Pour afficher des données après l’activation du monitoring, vous devez disposer du rôle Lecteur d’analyse ou Contributeur d’analyse.

Conditions préalables de Prometheus managé

Le cluster doit utiliser l’authentification par identité managée.
Les fournisseurs de ressources suivants doivent être inscrits dans l’abonnement du cluster AKS et de l’espace de travail Azure Monitor :
- Microsoft.ContainerService
- Microsoft.Insights
- Microsoft.AlertsManagement
- Microsoft.Monitor
Les fournisseurs de ressources suivants doivent être inscrits dans l’abonnement de l’abonnement à l’espace de travail Grafana :
- Microsoft.Dashboard

Conditions préalables pour les clusters Kubernetes avec Arc

Conditions préalables pour les extensions de cluster Kubernetes avec Azure Arc.
- Vérifiez les exigences de pare-feu en plus des exigences réseau Kubernetes avec Azure Arc.
- Si vous avez déjà installé le monitoring pour AKS, vérifiez que vous avez désactivé le monitoring avant de continuer pour éviter les problèmes pendant l’installation de l’extension.
- Si vous avez précédemment installé le monitoring sur un cluster en utilisant un script sans extension de cluster, suivez les instructions fournies dans l’article Désactiver le monitoring de votre cluster Kubernetes pour supprimer ce graphique Helm.

Remarque

L’extension Kubernetes avec Prometheus Arc managée (préversion) ne prend pas en charge les configurations suivantes :

Distributions Red Hat Openshift, notamment Azure Red Hat OpenShift (ARO)
Nœuds Windows

Workspaces

Le tableau suivant décrit les espaces de travail requis pour prendre en charge Prometheus managé et Container Insights. Vous pouvez créer chaque espace de travail dans le cadre du processus d’intégration ou utilisez un espace de travail existant. Consultez Concevoir une architecture d’espace de travail Log Analytics pour obtenir des conseils sur le nombre d’espaces de travail à créer et l’emplacement où vous devez les placer.

Fonctionnalité	Espace de travail	Notes
Prometheus managé	Espace de travail Azure Monitor	`Contributor` l’autorisation est suffisante pour permettre au module complémentaire d’envoyer des données à l’espace de travail Azure Monitor. Vous aurez besoin d’une autorisation de niveau `Owner` si vous liez votre espace de travail Azure Monitor pour afficher des métriques dans Azure Managed Grafana. Cela est obligatoire, car l’utilisateur qui exécute l’étape d’intégration doit être en mesure d’attribuer le rôle Azure Managed Grafana System Identity `Monitoring Reader` sur l’espace de travail Azure Monitor pour interroger les métriques.
Container Insights	Espace de travail Log Analytics	Vous pouvez attacher un cluster AKS à un espace de travail Log Analytics dans un autre abonnement Azure et dans le même locataire Microsoft Entra, mais vous devez utiliser l’interface Azure CLI ou un modèle Azure Resource Manager. Cette configuration ne peut pas être effectuée avec le portail Azure. Si vous connectez un cluster AKS existant à un espace de travail Log Analytics dans un autre abonnement, le fournisseur de ressources Microsoft.ContainerService doit être inscrit dans l’abonnement avec l’espace de travail Log Analytics. Pour plus d’informations, consultez Inscrire un fournisseur de ressources. Pour obtenir la liste des paires de mappage prises en charge à utiliser pour l’espace de travail par défaut, consultez Mappages des régions pris en charge par Container Insights.
Grafana managé	Espace de travail Azure Managed Grafana	Liez votre espace de travail Grafana à votre espace de travail Azure Monitor pour que les métriques Prometheus collectées à partir de votre cluster soient disponibles dans des tableaux de bord Grafana.

Activer Prometheus et Grafana

Utilisez l’une des méthodes suivantes pour activer le scraping des métriques Prometheus à partir de votre cluster et activez Grafana managé pour visualiser les métriques. Consultez Lier un espace de travail Grafana afin d’obtenir des options pour connecter votre espace de travail Azure Monitor et votre espace de travail Azure Managed Grafana.

Remarque

Si vous disposez d’une ressource Azure Monitor unique avec une liaison privée, l’activation de Prometheus ne va pas fonctionner si le cluster AKS et l’espace de travail Azure Monitor se trouvent dans des régions différentes. La configuration nécessaire pour le module complémentaire Prometheus n’est pas disponible entre des régions en raison de la contrainte de la liaison privée. Pour résoudre cela, créez un point de terminaison de collecte de données (DCE) dans l’emplacement du cluster AKS et une association de règles de collecte de données (DCRA) dans la même région que le cluster AKS. Associez le nouveau DCE au cluster AKS et nommez la nouvelle DCRA « configurationAccessEndpoint ». Pour obtenir des instructions complètes sur la configuration des DCE associés à votre espace de travail Azure Monitor afin d’utiliser une liaison privée pour l’ingestion de données, consultez Activer une liaison privée pour la surveillance Kubernetes dans Azure Monitor.

Activer à l’aide de l’interface CLI

Si vous ne spécifiez aucun espace de travail Azure Monitor existant dans les commandes suivantes, l’espace de travail par défaut pour le groupe de ressources est utilisé. Si aucun espace de travail par défaut n’existe dans la région du cluster, il est créé avec un nom au format DefaultAzureMonitorWorkspace-<mapped_region> dans un groupe de ressources ayant le nom DefaultRG-<cluster_region>.

Prérequis

Une version 2.49.0 ou ultérieure d’Azure CLI est requise.
L’extension aks-preview doit être désinstallée des clusters AKS en utilisant la commande az extension remove --name aks-preview.
L’extension k8s-extension doit être installée en tirant parti de la commande az extension add --name k8s-extension.
La version 1.4.1 de k8s-extension ou une version ultérieure est requise.

Cluster AKS

Utilisez l’option -enable-azure-monitor-metrics az aks create ou az aks update (selon si vous créez un cluster ou mettez à jour un cluster existant) pour installer le module complémentaire des métriques qui scrape les métriques Prometheus.

Exemples de commandes

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

Cluster avec Arc (préversion)

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

Toutes les commandes peuvent utiliser les paramètres facultatifs suivants :

AKS : --ksm-metric-annotations-allow-list
Arc : --AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList
Liste séparée par des virgules des clés d’annotations Kubernetes utilisées dans la métrique kube_resource_annotations de la ressource. Par exemple, kube_pod_annotations est la métrique d’annotations pour la ressource pods. Par défaut, cette métrique contient uniquement des étiquettes de nom et d’espace de noms. Pour inclure d’autres annotations, fournissez une liste de noms de ressources dans leur forme plurielle et les clés d’annotation Kubernetes que vous souhaitez autoriser. Une seule * peut être fournie pour chaque ressource afin d’autoriser toutes les annotations, mais cela a des conséquences graves sur les performances. Par exemple : pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
AKS : --ksm-metric-labels-allow-list
Arc : --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist
Liste séparée par des virgules d’autres clés d’étiquette Kubernetes utilisées dans la métrique kube_resource_labels kube_resource_labels de la ressource. Par exemple, kube_pod_labels est la métrique d’étiquettes pour la ressource pods. Par défaut, cette métrique contient uniquement des étiquettes de nom et d’espace de noms. Pour inclure davantage d’étiquettes, fournissez une liste de noms de ressources dans leur forme plurielle et les clés d’étiquette Kubernetes que vous souhaitez autoriser pour eux. Un seul * peut être fourni pour chaque ressource afin d’autoriser toutes les étiquettes, mais cela a des conséquences graves sur les performances. Par exemple : pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],....
AKS : --enable-windows-recording-rules Vous permet d’activer les groupes de règles d’enregistrement nécessaires au bon fonctionnement des tableaux de bord Windows.

Activer avec des modèles ARM

Prérequis

L’espace de travail Azure Monitor et l’instance Azure Managed Grafana doivent déjà être créés.
Le modèle doit être déployé dans le même groupe de ressources que l’instance Azure Managed Grafana.
Si l’instance Azure Managed Grafana se trouve dans un abonnement autre que l’abonnement à l’espace de travail Azure Monitor, inscrivez l’abonnement à l’espace de travail Azure Monitor auprès du fournisseur de ressources Microsoft.Dashboard en utilisant l’aide sur Lier un espace de travail Grafana.
Les utilisateurs disposant du rôle User Access Administrator dans l’abonnement du cluster AKS peuvent activer le rôle Monitoring Reader directement en déployant le modèle.

Remarque

Actuellement dans Bicep, il n’existe aucun moyen de définir explicitement l’étendue de l’attribution de rôle Monitoring Reader sur un paramètre de chaîne « ID de ressource » pour un espace de travail Azure Monitor comme dans un modèle ARM. Bicep attend une valeur de type resource | tenant. De plus, il n’existe aucune spécification d’API REST pour un espace de travail Azure Monitor.

Par conséquent, l’étendue par défaut du rôle Monitoring Reader est définie sur le groupe de ressources. Le rôle est appliqué sur le même espace de travail Azure Monitor (par héritage), ce qui est le comportement attendu. Après avoir déployé ce modèle Bicep, l’instance Grafana reçoit les autorisations Monitoring Reader pour tous les espaces de travail Azure Monitor de ce groupe de ressources.

Récupérer les valeurs requises pour la ressource Grafana

Si l’instance Azure Managed Grafana est déjà liée à un espace de travail Azure Monitor, vous devez alors inclure cette liste dans le modèle. Dans la page Vue d’ensemble pour l’instance Azure Managed Grafana dans le Portail Azure, sélectionnez Vue JSON, puis copiez la valeur de azureMonitorWorkspaceIntegrations qui ressemble à l’exemple ci-dessous. S’il n’existe pas, cela signifie que l’instance n’a pas été liée à un espace de travail Azure Monitor.

"properties": {
    "grafanaIntegrations": {
        "azureMonitorWorkspaceIntegrations": [
            {
                "azureMonitorWorkspaceResourceId": "full_resource_id_1"
            },
            {
                "azureMonitorWorkspaceResourceId": "full_resource_id_2"
            }
        ]
    }
}

Télécharger et modifier le modèle et le fichier de paramètres

Téléchargez les fichiers requis pour le type de cluster Kubernetes avec lequel vous travaillez.

Cluster AKS ARM
- Fichier de modèle : https://aka.ms/azureprometheus-enable-arm-template
- Fichier de paramètres : https://aka.ms/azureprometheus-enable-arm-template-parameters
Cluster AKS Bicep
- Fichier de modèle : https://aka.ms/azureprometheus-enable-bicep-template
- Fichier de paramètres : https://aka.ms/azureprometheus-enable-bicep-template-parameters
- Module DCRA : https://aka.ms/nested_azuremonitormetrics_dcra_clusterResourceId
- Module de profil : https://aka.ms/nested_azuremonitormetrics_profile_clusterResourceId
- Module d’attribution de rôle Azure Managed Grafana : https://aka.ms/nested_grafana_amw_role_assignment
Arm avec cluster avec Arc (préversion)
- Fichier de modèle : https://aka.ms/azureprometheus-arc-arm-template
- Fichier de paramètres : https://aka.ms/azureprometheus-arc-arm-template-parameters

Modifiez les valeurs suivantes dans le fichier de paramètres. Le même ensemble de valeurs est utilisé pour les modèles ARM et Bicep. Récupérez l’ID de ressource des ressources à partir de la Vue JSON de la page Vue d’ensemble.

Paramètre	Valeur
`azureMonitorWorkspaceResourceId`	ID de ressource de l’espace de travail Azure Monitor. Récupérez-le à partir de la Vue JSON sur la page Vue d’ensemble de l’espace de travail Azure Monitor.
`azureMonitorWorkspaceLocation`	Emplacement de l’espace de travail Azure Monitor. Récupérez-le à partir de la Vue JSON sur la page Vue d’ensemble de l’espace de travail Azure Monitor.
`clusterResourceId`	ID de ressource pour le cluster AKS. Récupérez-le à partir de la Vue JSON sur la page Vue d’ensemble du cluster.
`clusterLocation`	Emplacement du cluster AKS. Récupérez-le à partir de la Vue JSON sur la page Vue d’ensemble du cluster.
`metricLabelsAllowlist`	Liste séparée par des virgules de clés d’étiquettes Kubernetes pour être utilisées dans la métrique des étiquettes de la ressource.
`metricAnnotationsAllowList`	Liste séparée par des virgules d’autres clés d’étiquettes Kubernetes à utiliser dans la métrique des annotations de la ressource.
`grafanaResourceId`	ID de ressource de l’instance Grafana managée. Récupérez-le à partir de la Vue JSON sur la page Vue d’ensemble de l’instance Grafana.
`grafanaLocation`	Emplacement de l’instance Grafana managée. Récupérez-le à partir de la Vue JSON sur la page Vue d’ensemble de l’instance Grafana.
`grafanaSku`	Référence SKU de l’instance Grafana managée. Récupérez-la à partir de la Vue JSON sur la page Vue d’ensemble de l’instance Grafana. Utilisez sku.name.

Ouvrez le fichier de modèle et mettez à jour la propriété grafanaIntegrations à la fin du fichier avec les valeurs que vous avez récupérées à partir de l’instance Grafana. Cela ressemble aux exemples suivants. Dans ces exemples, full_resource_id_1 et full_resource_id_2 étaient déjà dans le JSON de ressource Azure Managed Grafana. L’entrée azureMonitorWorkspaceResourceId finale se trouve déjà dans le modèle et est utilisée pour établir un lien vers l’ID de ressource d’espace de travail Azure Monitor fourni dans le fichier de paramètres.

ARM

{
    "type": "Microsoft.Dashboard/grafana",
    "apiVersion": "2022-08-01",
    "name": "[split(parameters('grafanaResourceId'),'/')[8]]",
    "sku": {
        "name": "[parameters('grafanaSku')]"
    },
    "location": "[parameters('grafanaLocation')]",
    "properties": {
        "grafanaIntegrations": {
        "azureMonitorWorkspaceIntegrations": [
            {
                "azureMonitorWorkspaceResourceId": "full_resource_id_1"
            },
            {
                "azureMonitorWorkspaceResourceId": "full_resource_id_2"
            },
            {
                "azureMonitorWorkspaceResourceId": "[parameters('azureMonitorWorkspaceResourceId')]"
            }
        ]
        }
    }
}

Bicep

    resource grafanaResourceId_8 'Microsoft.Dashboard/grafana@2022-08-01' = {
        name: split(grafanaResourceId, '/')[8]
        sku: {
            name: grafanaSku
        }
        identity: {
            type: 'SystemAssigned'
        }
        location: grafanaLocation
        properties: {
            grafanaIntegrations: {
                azureMonitorWorkspaceIntegrations: [
                    {
                        azureMonitorWorkspaceResourceId: 'full_resource_id_1'
                    }
                    {
                        azureMonitorWorkspaceResourceId: 'full_resource_id_2'
                    }
                    {
                        azureMonitorWorkspaceResourceId: azureMonitorWorkspaceResourceId
                    }
                ]
            }
        }
    }

Déployez le modèle avec le fichier de paramètres en utilisant une méthode valide pour déployer des modèles Resource Manager. Pour obtenir des exemples des différentes méthodes, consultez Déployer les exemples de modèles.

Activer avec Terraform

Prérequis

L’espace de travail Azure Monitor et l’espace de travail Azure Managed Grafana doivent déjà être créés.
Le modèle doit être déployé dans le même groupe de ressources que la ressource que l’espace de travail Azure Managed Grafana.
Les utilisateurs disposant du rôle d’Administrateur de l’accès utilisateur dans l’abonnement du cluster AKS peuvent activer le rôle de Lecteur de supervision directement en déployant le modèle.
Si l’instance Azure Managed Grafana se trouve dans un abonnement autre que l’abonnement Espaces de travail Azure Monitor, inscrivez l’abonnement Espaces de travail Azure Monitor auprès du fournisseur de ressources Microsoft.Dashboard en suivant cette documentation.

Récupérez les valeurs requises pour une ressource Grafana

Dans la page Vue d’ensemble de l’instance Azure Managed Grafana ans le portail Azure, sélectionnez Vue JSON.

Si vous utilisez une instance Azure Managed Grafana existante qui est déjà liée à un espace de travail Azure Monitor, vous avez besoin de la liste des intégrations Grafana. Copiez la valeur du champ azureMonitorWorkspaceIntegrations. S’il n’existe pas, l’instance n’a pas été liée à un espace de travail Azure Monitor. Mettez à jour le bloc azure_monitor_workspace_integrations dans main.tf avec la liste des intégrations Grafana.

  azure_monitor_workspace_integrations {
    resource_id  = var.monitor_workspace_id[var.monitor_workspace_id1, var.monitor_workspace_id2]
  }

Télécharger et modifier les modèles

Si vous déployez un nouveau cluster AKS en tirant parti de Terraform avec le module complémentaire Prometheus managé activé, suivez ces étapes :

Téléchargez tous les fichiers sous AddonTerraformTemplate.
Remplacez les variables dans le fichier variables.tf par les valeurs de paramètre correctes.
Exécutez terraform init -upgrade pour initialiser le déploiement Terraform.
Exécutez terraform plan -out main.tfplan pour initialiser le déploiement Terraform.
Exécutez terraform apply main.tfplan pour appliquer le plan d’exécution à votre infrastructure cloud.

Remarque : transmettez les variables pour des clés annotations_allowed et labels_allowed dans main.tf uniquement lorsque ces valeurs existent. Ces blocs sont facultatifs.

Notes

Modifiez le fichier main.tf de manière appropriée avant d’exécuter le modèle Terraform. Ajoutez toute valeur azure_monitor_workspace_integrations existante à la ressource Grafana avant d’exécuter le modèle. Sinon, les anciennes valeurs sont supprimées et remplacées par le contenu du modèle pendant le déploiement. Les utilisateurs disposant du rôle « Administrateur de l’accès utilisateur » dans l’abonnement du cluster AKS peuvent activer le rôle « Lecteur de supervision » directement en déployant le modèle. Modifiez le paramètre grafanaSku si vous utilisez une référence SKU non standard et exécutez finalement ce modèle dans le groupe de ressources de la ressource Grafana.

Activer avec Azure Policy

Téléchargez le modèle et les fichiers de paramètres Azure Policy.
- Fichier de modèle : https://aka.ms/AddonPolicyMetricsProfile
- Fichier de paramètres : https://aka.ms/AddonPolicyMetricsProfile.parameters
Créez la définition de stratégie en utilisant la commande suivante CLI :

az policy definition create --name "Prometheus Metrics addon" --display-name "Prometheus Metrics addon" --mode Indexed --metadata version=1.0.0 category=Kubernetes --rules AddonPolicyMetricsProfile.rules.json --params AddonPolicyMetricsProfile.parameters.json
Après la création de la définition de stratégie, dans le Portail Azure, sélectionnez Définitions Stratégie, puis Définitions. Sélectionnez la définition de stratégie que vous avez créée.
Sélectionnez Attribuer et remplissez les détails sous l’onglet Paramètres. Sélectionnez Vérifier + créer.
Si vous souhaitez appliquer la stratégie à un cluster existant, créez une Tâche de correction pour cette ressource de cluster à partir d’Attribution de stratégie.

Dès lors que la stratégie est attribuée à l’abonnement, chaque fois que vous créez un cluster sur lequel Prometheus n’est pas activé, la stratégie s’exécute et se déploie pour activer la supervision Prometheus.

Activer Container Insights

Utilisez l’une des méthodes suivantes pour activer Container Insights sur votre cluster. Une fois cette opération effectuée, consultez Configurer la collecte de données d’agent pour Container Insights pour personnaliser votre configuration afin de vérifier que vous ne collectez pas plus de données que nécessaire.

Utilisez l’une des commandes suivantes pour activer le monitoring de vos clusters AKS et Arc. Si vous ne spécifiez aucun espace de travail Log Analytics existant, l’espace de travail par défaut pour le groupe de ressources est utilisé. S’il n’existe pas déjà un espace de travail par défaut dans la région du cluster, il est créé avec un nom au format DefaultWorkspace-<GUID>-<Region>.

Prérequis

Azure CLI version 2.43.0 ou ultérieure
L’authentification d’identité managée est définie par défaut dans l’interface CLI version 2.49.0 ou ultérieure.
Extension Azure k8s version 1.3.7 ou ultérieure
L’authentification d’identité managée est la valeur par défaut dans la version 1.43.0 de k8s-extension (ou une version ultérieure).
L’authentification de l’identité managée n’est pas prise en charge pour les clusters Kubernetes avec Arc avec des nœuds ARO (Azure Red Hat Openshift) ou Windows. Utilisez l’authentification héritée.
Pour l’interface CLI version 2.54.0 ou ultérieure, le schéma de journalisation est configuré pour ContainerLogV2 en utilisant ConfigMap.

Remarque

Vous pouvez activer le schéma ContainerLogV2 d’un cluster à l’aide des DCR (Règles de collecte de données) du cluster ou de ConfigMap. Si les deux paramètres sont activés, ConfigMap est prioritaire. Les journaux Stdout et stderr ne seront ingérés dans la table ContainerLog que lorsque la DCR et ConfigMap sont explicitement définies sur désactivé.

Cluster 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

Exemple

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"

Cluster avec 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>

Consultez la section Requêtes et limites des ressources des graphiques Helm pour découvrir les paramètres de configuration disponibles.

Exemple

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"

Cluster avec Arc avec proxy de transfert

Si le cluster est configuré avec un proxy de transfert, les paramètres de proxy sont automatiquement appliqués à l’extension. Dans le cas d’un cluster avec AMPLS + proxy, la configuration du proxy doit être ignorée. Intégrez l’extension avec le paramètre de configuration 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

Cluster avec Arc avec des nœuds ARO ou OpenShift ou Windows

L’authentification de l’identité managée n’est pas prise en charge pour les clusters Kubernetes avec Arc avec des nœuds ARO (Azure Red Hat OpenShift) ou OpenShift ou Windows. Utilisez l’authentification héritée en spécifiant amalogs.useAADAuth=false comme dans l’exemple suivant.

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

Supprimer une instance d’extension

La commande suivante supprime uniquement l’instance d’extension, mais pas l’espace de travail Log Analytics. Les données dans la ressource Log Analytics restent intactes.

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

Les modèles ARM et Bicep sont fournis dans cette section.

Prérequis

Le modèle doit être déployé dans le même groupe de ressources que le cluster.

Télécharger et installer un modèle

Télécharger et modifier le modèle et le fichier de paramètres

Cluster AKS ARM
- Fichier de modèle : https://aka.ms/aks-enable-monitoring-msi-onboarding-template-file
- Fichier de paramètres : https://aka.ms/aks-enable-monitoring-msi-onboarding-template-parameter-file
Cluster AKS Bicep
- Fichier de modèle (Syslog) : https://aka.ms/enable-monitoring-msi-syslog-bicep-template
- Fichier de paramètres (non Syslog) : https://aka.ms/enable-monitoring-msi-syslog-bicep-parameters
- Fichier de modèle (non Syslog) : https://aka.ms/enable-monitoring-msi-bicep-template
- Fichier de paramètres (non Syslog) : https://aka.ms/enable-monitoring-msi-bicep-parameters
Cluster avec Arc ARM
- Fichier de modèle : https://aka.ms/arc-k8s-azmon-extension-msi-arm-template
- Fichier de paramètres : https://aka.ms/arc-k8s-azmon-extension-msi-arm-template-params
- Fichier de modèle (authentification héritée) : https://aka.ms/arc-k8s-azmon-extension-arm-template
- Fichier de paramètres (authentification héritée) : https://aka.ms/arc-k8s-azmon-extension-arm-template-params

Paramètre	Description
AKS : `aksResourceId` Arc : `clusterResourceId`	ID de ressource du cluster.
AKS : `aksResourceLocation` Arc : `clusterRegion`	Emplacement du cluster.
AKS : `workspaceResourceId` Arc : `workspaceResourceId`	ID de ressource de l’espace de travail Log Analytics.
Arc : `workspaceRegion`	Région de l’espace de travail Log Analytics.
Arc : `workspaceDomain`	Domaine de l’espace de travail Log Analytics. `opinsights.azure.com` pour cloud public Azure `opinsights.azure.us` pour AzureUSGovernment.
AKS : `resourceTagValues`	Valeurs de balise spécifiées pour la règle de collecte de données (DCR) de l’extension Container Insights existante du cluster et nom de la DCR. Le nom est `MSCI-<clusterName>-<clusterRegion>` et cette ressource est créée dans un groupe de ressources de clusters AKS. S’il s’agit de la première intégration, vous pouvez définir des valeurs de balise arbitraires.

Déployez le modèle avec le fichier de paramètres en utilisant une méthode valide pour déployer des modèles Resource Manager. Pour obtenir des exemples des différentes méthodes, consultez Déployer les exemples de modèles.

Nouveau cluster AKS

Téléchargez le fichier de modèle Terraform que vous souhaitez, avec ou sans la collection Syslog.

Syslog
- https://aka.ms/enable-monitoring-msi-syslog-terraform
Sans Syslog
- https://aka.ms/enable-monitoring-msi-terraform
Ajustez la ressource azurerm_kubernetes_cluster dans main.tf en fonction des paramètres de votre cluster.

Mettez à jour les paramètres dans le fichier variables.tf pour remplacer les valeurs dans « <> »

Paramètre	Description
`aks_resource_group_name`	Utilisez les valeurs sur la page de présentation d’AKS pour le groupe de ressources.
`resource_group_location`	Utilisez les valeurs sur la page de présentation d’AKS pour le groupe de ressources.
`cluster_name`	Définissez le nom du cluster que vous souhaitez créer.
`workspace_resource_id`	Utilisez l’ID de la ressource de votre espace de travail Log Analytics.
`workspace_region`	Utilisez l’emplacement de votre espace de travail Log Analytics.
`resource_tag_values`	Faites correspondre les valeurs d’étiquettes existantes, spécifiées pour la règle de collecte de données (DCR) de l’extension Container Insights existante du cluster, et le nom du DCR. Le nom correspond à `MSCI-<clusterName>-<clusterRegion>` et cette ressource est créée dans le même groupe de ressources que les clusters AKS. S’il s’agit de la première intégration, vous pouvez définir les valeurs d’étiquettes arbitraires.
`enabledContainerLogV2`	Définissez cette valeur de paramètre comme vraie pour utiliser le ContainerLogV2 recommandé par défaut.
Paramètres d’optimisation des coûts	Reportez-vous aux paramètres de collecte de données

Exécutez terraform init -upgrade pour initialiser le déploiement Terraform.
Exécutez terraform plan -out main.tfplan pour initialiser le déploiement Terraform.
Exécutez terraform apply main.tfplan pour appliquer le plan d’exécution à votre infrastructure cloud.

Cluster AKS existant

Pour commencer, importez la ressource de cluster existante à l’aide de la commande suivante : terraform import azurerm_kubernetes_cluster.k8s <aksResourceId>

Ajoutez le profil de module complémentaire oms_agent à la ressource azurerm_kubernetes_cluster existante.

oms_agent {
    log_analytics_workspace_id = var.workspace_resource_id
    msi_auth_for_monitoring_enabled = true
  }

Copiez les ressources DCR et DCRA à partir des modèles Terraform
Exécutez terraform plan -out main.tfplan et vérifiez que la modification ajoute la propriété oms_agent. Remarque : si la ressource définie azurerm_kubernetes_cluster est différente pendant la planification Terraform, le cluster existant est détruit et recréé.
Exécutez terraform apply main.tfplan pour appliquer le plan d’exécution à votre infrastructure cloud.

Conseil

Modifiez le fichier main.tf de manière appropriée avant d’exécuter le modèle Terraform.
Les données commencent à circuler au bout de 10 minutes, car le cluster doit d’abord être prêt.
WorkspaceID doit respecter le format /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/example-resource-group/providers/Microsoft.OperationalInsights/workspaces/workspaceValue.
Si le groupe de ressources existe déjà, exécutez terraform import azurerm_resource_group.rg /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name> avant le plan Terraform.

Portail Azure

Sous l’onglet Définitions du menu Stratégie dans le Portail Azure, créez une définition de stratégie avec les informations suivantes.
- Emplacement de la définition : abonnement Azure dans lequel la définition de stratégie doit être stockée.
- Nom : AKS-Monitoring-Addon
- Description : stratégie personnalisée Azure pour activer le module complémentaire Monitoring sur les clusters Azure Kubernetes.
- Catégorie : sélectionnez Utiliser une existante, puis Kubernetes dans la liste déroulante.
- Règle de stratégie : remplacez l’exemple JSON existant par le contenu de https://aka.ms/aks-enable-monitoring-custom-policy.
Sélectionnez la nouvelle définition de stratégie Module complémentaire de monitoring AKS.
Sélectionnez Attribuer et spécifiez une étendue pour l’emplacement où la stratégie doit être attribuée.
Sélectionnez Suivant et indiquez l’ID de ressource de l’espace de travail Log Analytics.
Créez une tâche de correction si vous souhaitez appliquer la stratégie à des clusters AKS existants dans l’étendue sélectionnée.
Sélectionnez Vérifier + créer pour créer l’attribution des stratégies.

Azure CLI

Téléchargez le modèle et les fichiers de paramètres Azure Policy.
- Fichier de modèle : https://aka.ms/enable-monitoring-msi-azure-policy-template
- Fichier de paramètres : https://aka.ms/enable-monitoring-msi-azure-policy-parameters

Créez la définition de stratégie en utilisant la commande suivante CLI :

az policy definition create --name "AKS-Monitoring-Addon-MSI" --display-name "AKS-Monitoring-Addon-MSI" --mode Indexed --metadata version=1.0.0 category=Kubernetes --rules azure-policy.rules.json --params azure-policy.parameters.json

Créez la définition de stratégie en utilisant la commande suivante CLI :

az policy assignment create --name aks-monitoring-addon --policy "AKS-Monitoring-Addon-MSI" --assign-identity --identity-scope /subscriptions/<subscriptionId> --role Contributor --scope /subscriptions/<subscriptionId> --location <location> --role Contributor --scope /subscriptions/<subscriptionId> -p "{ \"workspaceResourceId\": { \"value\":  \"/subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/microsoft.operationalinsights/workspaces/<workspaceName>\" } }"

Activer le monitoring complet avec le Portail Azure

Nouveau cluster AKS (Prometheus, Container Insights et Grafana)

Lorsque vous créez un cluster AKS dans le portail Azure, vous pouvez activer Prometheus, Container Insights et Grafana à partir de l’onglet Surveillance. Vérifiez que vous cochez les cases Activer les journaux de conteneur, Activer les métriques Prometheus et Activer Grafana.

Cluster existant (Prometheus, Container Insights et Grafana)

Accédez à votre cluster AKS dans le portail Azure.
Dans le menu du service, sous Surveillance, sélectionnez Insights>Configurer la surveillance.
Insights de conteneur est déjà activé. Cochez les cases Activer les métriques Prometheus et Activer Grafana. Si vous disposez déjà d’un espace de travail Azure Monitor et d’un espace de travail Grafana, ils sont sélectionnés pour vous.
Sélectionnez Paramètres avancés si vous souhaitez sélectionner d’autres espaces de travail ou en créer de nouveaux. Le paramètre Coûts prédéfinis vous permet de modifier les détails de collecte par défaut pour réduire le suivi des coûts. Pour plus d’informations, consultez Activer les paramètres d’optimisation des coûts dans Container Insights.
Sélectionnez Configurer.

Cluster existant (Prometheus uniquement)

Accédez à votre cluster AKS dans le portail Azure.
Dans le menu du service, sous Surveillance, sélectionnez Insights>Configurer la surveillance.
Cochez la case Activer les métriques Prometheus.
Sélectionnez Paramètres avancés si vous souhaitez sélectionner d’autres espaces de travail ou en créer de nouveaux. Le paramètre Coûts prédéfinis vous permet de modifier les détails de collecte par défaut pour réduire le suivi des coûts.
Sélectionnez Configurer.

Activer la collecte de métriques Windows (préversion)

Remarque

Il n’y a pas de limite de CPU/mémoire dans windows-exporter-daemonset.yaml, il peut donc surapprovisionner les nœuds Windows.
Pour plus d’informations, consultez Réservation de ressources

Lorsque vous déployez des charges de travail, définissez des limites de mémoire et de processeur pour les conteneurs. Cela soustrait également NodeAllocatable et aide le planificateur du cluster à déterminer quels pods doivent être placés sur quels nœuds. La planification de pods sans limitation peut provoquer un surapprovisionnement des nœuds Windows et, dans certains cas extrêmes, nuire à l’intégrité des nœuds.

À partir de la version 6.4.0-main-02-22-2023-3ee44b9e du conteneur de complément Prometheus managé (prometheus_collector), une collection de métriques Windows a été activée pour les clusters AKS. L’intégration au module complémentaire Métriques Azure Monitor permet aux pods Daemonset Windows de commencer à s’exécuter sur vos pools de nœuds. Windows Server 2019 et Windows Server 2022 sont pris en charge. Suivez ces étapes pour permettre aux pods de collecter des métriques à partir de vos pools de nœuds Windows.

Installez manuellement windows-exporter sur des nœuds AKS pour accéder aux métriques Windows en déployant le fichier YAML windows-exporter-daemonset. Activez les collecteurs suivants :
- [defaults]
- container
- memory
- process
- cpu_info
Pour plus de collecteurs, consultez Exportateur Prometheus des métriques Windows.

Déployez le fichier YAML windows-exporter-daemonset. Notez que si des teintes sont appliquées dans le nœud, vous devez appliquer les tolérances appropriées.
```
    kubectl apply -f windows-exporter-daemonset.yaml
```
Appliquez ama-metrics-settings-configmap à votre cluster. Définissez les valeurs booléennes windowsexporter et windowskubeproxy sur true. Pour plus d’informations, consultez Configmap des paramètres complémentaires de métriques.
Activez les règles d’enregistrement requises pour les tableaux de bord prêts à l’emploi :
- Si vous procédez à l’intégration à l’aide de l’interface CLI, incluez l’option --enable-windows-recording-rules.
- Si vous procédez à l’intégration à l’aide d’un modèle ARM, Bicep ou Azure Policy, définissez enableWindowsRecordingRules sur true dans le fichier de paramètres.
- Si le cluster est déjà intégré, utilisez ce modèle ARM et ce fichier de paramètres pour créer les groupes de règles. Cela ajoute les règles d’enregistrement requises, n’est pas une opération ARM sur le cluster et n’affecte pas l’état de surveillance actuel du cluster.

Vérifier le déploiement

Utilisez l’outil de ligne de commande kubectl pour vérifier que l’agent est déployé correctement.

Prometheus managé

Vérifier que DaemonSet a été correctement déployé sur les pools de nœuds Linux

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

Le nombre de pods doit être égal au nombre de nœuds Linux du cluster. La sortie doit ressembler à l’exemple suivant :

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

Vérifier que les nœuds Windows ont été déployés correctement

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

Le nombre de pods doit être égal au nombre de nœuds Windows du cluster. La sortie doit ressembler à l’exemple suivant :

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

Vérifier que les deux ReplicaSets ont été déployés pour Prometheus

kubectl get rs --namespace=kube-system

La sortie doit ressembler à l’exemple suivant :

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

Container Insights

Vérifier que les DaemonSets ont été correctement déployés sur les pools de nœuds Linux

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

Le nombre de pods doit être égal au nombre de nœuds Linux du cluster. La sortie doit ressembler à l’exemple suivant :

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

Vérifier que les nœuds Windows ont été déployés correctement

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

Le nombre de pods doit être égal au nombre de nœuds Windows du cluster. La sortie doit ressembler à l’exemple suivant :

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

Vérifier le déploiement de la solution Container Insights

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

La sortie doit ressembler à l’exemple suivant :

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

Afficher la configuration avec l’interface CLI

Utilisez la commande aks show pour découvrir si la solution est activée, quel est l’ID de ressource de l’espace de travail Log Analytics et obtenir des informations récapitulatives sur le cluster.

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

La commande retourne des informations au format JSON concernant la solution. La section addonProfiles doit inclure des informations sur omsagent comme dans l’exemple suivant :

"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
    },
}

Ressources approvisionnées

Lorsque vous activez le monitoring, les ressources suivantes sont créées dans votre abonnement :

Nom de la ressource	Type de ressource	Groupe de ressources	Région/Localisation	Description
`MSCI-<aksclusterregion>-<clustername>`	Règle de collecte de données	Identique à un cluster	Identique à un espace de travail Log Analytics	Cette règle de collecte de données s’applique à la collecte de journaux par l’agent Azure Monitor qui utilise l’espace de travail Log Analytics comme destination et qui est associé à la ressource de cluster AKS.
`MSPROM-<aksclusterregion>-<clustername>`	Règle de collecte de données	Identique à un cluster	Identique à un espace de travail Azure Monitor	Cette règle de collecte de données s’applique à la collecte de métriques Prometheus par le module complémentaire de métriques, pour qui l’espace de travail Azure Monitor choisi correspond à la destination, et qui est également associé à la ressource de cluster AKS
`MSPROM-<aksclusterregion>-<clustername>`	Point de terminaison de collecte de données	Identique à un cluster	Identique à un espace de travail Azure Monitor	Ce point de terminaison de collecte de données est utilisé par la règle de collecte de données ci-dessus pour ingérer les métriques Prometheus du module complémentaire de métriques

Lorsque vous créez un espace de travail Azure Monitor, les ressources supplémentaires suivantes sont créées en même temps

Nom de la ressource	Type de ressource	Groupe de ressources	Région/Localisation	Description
`<azuremonitor-workspace-name>`	Règle de collecte de données	MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	Identique à un espace de travail Azure Monitor	DCR créée lorsque vous utilisez un serveur OSS Prometheus pour l’écriture à distance dans un espace de travail Azure Monitor.
`<azuremonitor-workspace-name>`	Point de terminaison de collecte de données	MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	Identique à un espace de travail Azure Monitor	DCE créé lorsque vous utilisez un serveur OSS Prometheus pour l’écriture à distance dans un espace de travail Azure Monitor.

Différences entre les clusters Windows et Linux

Les principales différences entre la supervision d’un cluster Windows Server et celle d’un cluster Linux sont notamment les suivantes :

Windows n’a pas de métrique Mémoire RSS. Elle n’est donc pas disponible pour les nœuds et les conteneurs Windows. La métrique Plage de travail est disponible.
Les informations de capacité de stockage des disques ne sont pas disponibles pour les nœuds Windows.
Seuls les environnements de pod sont surveillés, pas les environnements Docker.
Avec la préversion, un maximum de 30 conteneurs Windows Server sont pris en charge. Cette limitation ne s’applique pas aux conteneurs Linux.

Notes

La prise en charge de Container Insights pour le système d’exploitation Windows Server 2022 est en préversion.

L’agent Linux conteneurisé (pod replicaset) effectue des appels d’API vers tous les nœuds Windows sur le port sécurisé Kubelet (10250) au sein du cluster afin de collecter des métriques liées aux performances du nœud et du conteneur. Le port sécurisé Kubelet (:10250) doit être ouvert dans le réseau virtuel du cluster à la fois pour le trafic entrant et sortant pour que la collecte de métriques liées aux performances des nœuds et des conteneurs Windows soit opérationnelle.

Si vous avez un cluster Kubernetes avec des nœuds Windows, passez en revue et configurez le groupe de sécurité réseau et les stratégies réseau pour vous assurer que le port sécurisé Kubelet (:10250) est ouvert au trafic entrant et sortant dans le réseau virtuel du cluster.

Étapes suivantes

Si vous rencontrez des problèmes quand vous tentez d’intégrer la solution, consultez le guide de résolution des problèmes.
Une fois la supervision activée pour collecter l’intégrité et l’utilisation des ressources de votre cluster AKS et des charges de travail s’exécutant sur celles-ci, découvrez comment utiliser Container Insights.

Partager via

Activer le monitoring pour des clusters Kubernetes

Clusters pris en charge

Prérequis

Workspaces

Activer Prometheus et Grafana

Activer à l’aide de l’interface CLI

Prérequis

Cluster AKS

Cluster avec Arc (préversion)

Activer Container Insights

Prérequis

Cluster AKS

Cluster avec Arc

Activer le monitoring complet avec le Portail Azure

Nouveau cluster AKS (Prometheus, Container Insights et Grafana)

Cluster existant (Prometheus, Container Insights et Grafana)

Cluster existant (Prometheus uniquement)

Activer la collecte de métriques Windows (préversion)

Vérifier le déploiement

Prometheus managé

Container Insights

Ressources approvisionnées

Différences entre les clusters Windows et Linux

Étapes suivantes

Commentaires

Ressources supplémentaires