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 :
- 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 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.
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
etwindowskubeproxy
surtrue
. 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
surtrue
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.
- Si vous procédez à l’intégration à l’aide de l’interface CLI, incluez l’option
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.