Partager via


Activer le monitoring pour des clusters Kubernetes

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

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 :

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

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

Remarque

L’extension Kubernetes avec Prometheus Arc managée 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

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

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.

Capture d’écran de l’onglet Surveillance pour le nouveau cluster AKS.

Cluster existant (Prometheus, Container Insights et Grafana)

  1. Accédez à votre cluster AKS dans le portail Azure.
  2. Dans le menu du service, sous Surveillance, sélectionnez Insights>Configurer la surveillance.
  3. 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.
  4. 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.
  5. Sélectionnez Configurer.

Cluster existant (Prometheus uniquement)

  1. Accédez à votre cluster AKS dans le portail Azure.
  2. Dans le menu du service, sous Surveillance, sélectionnez Insights>Configurer la surveillance.
  3. Cochez la case Activer les métriques Prometheus.
  4. 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.
  5. 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.

  1. 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
    
  2. 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.

  3. 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/00000000-0000-0000-0000-000000000000/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.