Usando il portale di Azure, è possibile abilitare tutte le funzionalità contemporaneamente. È anche possibile abilitarli singolarmente usando l'interfaccia della riga di comando di Azure, il modello di Azure Resource Manager, Terraform o Criteri di Azure. Ognuno di questi metodi è descritto in questo articolo.
Importante
I cluster Kubernetes generano molti dati di log, che possono comportare costi significativi se non si presta attenzione a quali log vengono raccolti. Prima di abilitare il monitoraggio per il cluster, vedere gli articoli seguenti per assicurarsi che l'ambiente sia ottimizzato per i costi e per limitare la raccolta dei log solo ai dati necessari:
Ottimizzazione dei costi in Monitoraggio di Azure Procedure consigliate per configurare tutte le funzionalità di Monitoraggio di Azure per ottimizzare i costi e limitare la quantità di dati raccolti.
Cluster supportati
Questo articolo fornisce indicazioni sull'onboarding per i tipi di cluster seguenti. Le eventuali differenze nel processo per ogni tipo sono indicate nelle sezioni pertinenti.
I provider di risorse seguenti devono essere registrati nella sottoscrizione del cluster servizio Azure Kubernetes e nell'area di lavoro Monitoraggio di Azure:
Microsoft.ContainerService
Microsoft.Insights
Microsoft.AlertsManagement
Microsoft.Monitor
I provider di risorse seguenti devono essere registrati nella sottoscrizione dell'area di lavoro Grafana:
Microsoft.Dashboard
Prerequisiti dei cluster Kubernetes abilitati per Arc
Se in precedenza è stato installato il monitoraggio per il servizio Azure Kubernetes, prima di procedere assicurarsi di aver disabilitato il monitoraggio, per evitare problemi durante l'installazione dell'estensione.
Se in precedenza è stato installato il monitoraggio in un cluster usando uno script senza estensioni del cluster, seguire le istruzioni in Disabilitare il monitoraggio del cluster Kubernetes per eliminare questo grafico Helm.
Nota
L'estensione Kubernetes abilitata per Arc di Prometheus (anteprima) gestita non supporta le configurazioni seguenti:
Distribuzioni di Red Hat Openshift, tra cui Azure Red Hat OpenShift (ARO)
Nodi di Windows
Aree di lavoro
Nella tabella seguente vengono descritte le aree di lavoro necessarie per supportare Prometheus gestito e Container Insights. È possibile creare ogni area di lavoro come parte del processo di onboarding o usare un'area di lavoro esistente. Vedere Progettare un'architettura dell'area di lavoro Log Analytics per indicazioni sul numero di aree di lavoro da creare e sulla posizione in cui devono essere inserite.
L'autorizzazione Contributor è sufficiente per consentire al componente aggiuntivo di inviare dati all'area di lavoro di Monitoraggio di Azure. È necessaria l'autorizzazione a livello di Owner per collegare l'area di lavoro di Monitoraggio di Azure in modo da visualizzare le metriche in Grafana con gestione Azure. Questa operazione è necessaria perché l'utente che esegue il passaggio di onboarding deve essere in grado di assegnare il ruolo Monitoring Reader di identità del sistema Grafana con gestione Azure nell'area di lavoro di Monitoraggio di Azure per eseguire query sulle metriche.
È possibile collegare un cluster del servizio Azure Kubernetes a un'area di lavoro Log Analytics in una sottoscrizione di Azure diversa nello stesso tenant di Microsoft Entra, ma è necessario usare l'interfaccia della riga di comando di Azure o un modello di Azure Resource Manager. Non è attualmente possibile eseguire questa configurazione con il portale di Azure.
Se si connette un cluster del servizio Azure Kubernetes esistente a un'area di lavoro Log Analytics in un'altra sottoscrizione, il provider di risorse Microsoft.ContainerService deve essere registrato nella sottoscrizione con l'area di lavoro Log Analytics. Per maggiori informazioni, consultare la sezione Registrare il provider di risorse.
Usare uno dei metodi seguenti per abilitare lo scorporo delle metriche di Prometheus dal cluster e abilitare Grafana gestito per visualizzare le metriche. Vedere Collegare un'area di lavoro Grafana per le opzioni per connettere l'area di lavoro di Monitoraggio di Azure e l'area di lavoro Grafana con gestione Azure.
Nota
Se si ha una singola risorsa di Monitoraggio di Azure con collegamento privato, l'abilitazione di Prometheus non funzionerà se il cluster del servizio Azure Kubernetes e l'area di lavoro di Monitoraggio di Azure si trovano in aree diverse.
La configurazione necessaria per il componente aggiuntivo Prometheus non è disponibile tra aree a causa del vincolo di collegamento privato.
Per risolvere questo problema, creare un nuovo controller di dominio nel percorso del cluster del servizio Azure Kubernetes e una nuova associazione DCRA nella stessa area del cluster. Associare il nuovo controller di dominio al cluster del servizio Azure Kubernetes e denominare la nuova associazione (DCRA) come configurationAccessEndpoint.
Per istruzioni complete su come configurare i controller di dominio associati all'area di lavoro di Monitoraggio di Azure per l'uso di un collegamento privato per l'inserimento dati, vedere Abilitare un collegamento privato per il monitoraggio di Kubernetes in Monitoraggio di Azure.
Se non si specifica un'area di lavoro di Monitoraggio di Azure esistente nei comandi seguenti, verrà usata l'area di lavoro predefinita per il gruppo di risorse. Se un'area di lavoro predefinita non esiste già nell'area del cluster, ne verrà creata una con un nome nel formato DefaultAzureMonitorWorkspace-<mapped_region> in un gruppo di risorse con il nome DefaultRG-<cluster_region>.
Prerequisiti
È necessaria la versione dell'interfaccia della riga di comando di Az 2.49.0 o successiva.
L'estensione k8s-extension deve essere installata usando il comando az extension add --name k8s-extension.
È necessaria la versione 1.4.1 o successiva dell'estensione k8s.
Cluster del servizio Azure Kubernetes
Usare l'opzione -enable-azure-monitor-metricsaz aks create o az aks update (a seconda che si stia creando un nuovo cluster o aggiornando un cluster esistente) per installare il componente aggiuntivo delle metriche che scorpora le metriche Prometheus.
Comandi di esempio
### 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 con abilitazione di Arc (anteprima)
### 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]"
I comandi possono usare i parametri facoltativi seguenti:
Servizio Azure Kubernetes: --ksm-metric-annotations-allow-list Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList Elenco delimitato da virgole delle chiavi di annotazioni Kubernetes usate nella metrica kube_resource_annotations della risorsa. Ad esempio, kube_pod_annotations è la metrica delle annotazioni per la risorsa pod. Per impostazione predefinita, questa metrica contiene solo il nome e le etichette dello spazio dei nomi. Per includere altre annotazioni, specificare un elenco di nomi di risorse nel formato plurale e le chiavi di annotazione Kubernetes che si desidera consentire. È possibile specificare un singolo * per ogni risorsa per consentire qualsiasi annotazione, ma questo approccio ha gravi implicazioni sulle prestazioni. Ad esempio: pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
Servizio Azure Kubernetes: --ksm-metric-labels-allow-list Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist Elenco delimitato da virgole di altre chiavi di etichetta Kubernetes usate nella metrica kube_resource_labels della risorsa kube_resource_labels. Ad esempio, kube_pod_labels è la metrica delle etichette per la risorsa pod. Per impostazione predefinita, questa metrica contiene solo il nome e le etichette dello spazio dei nomi. Per includere più etichette, fornire un elenco di nomi di risorse nel formato plurale e le chiavi di etichetta Kubernetes che si desidera consentire per loro. È possibile specificare un singolo * per ogni risorsa per consentire qualsiasi etichetta, ma questo approccio ha gravi implicazioni sulle prestazioni. Ad esempio: pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],....
Servizio Azure Kubernetes: --enable-windows-recording-rules consente di abilitare i gruppi di regole di registrazione necessari per il corretto funzionamento dei dashboard di Windows.
Abilitare con i modelli di Resource Manager
Prerequisiti
È necessario creare già l'area di lavoro di Monitoraggio di Azure e l'istanza di Grafana con gestione Azure.
Il modello deve essere distribuito nello stesso gruppo di risorse dell'istanza di Grafana con gestione Azure.
Se l'istanza di Grafana con gestione Azure si trova in una sottoscrizione diversa da quella dell'area di lavoro di Monitoraggio di Azure, registrare la sottoscrizione dell'area di lavoro di Monitoraggio di Azure con il provider di risorse Microsoft.Dashboard seguendo le indicazioni riportate in Registrare il provider di risorse.
Gli utenti con il ruolo User Access Administrator nella sottoscrizione del cluster del servizio Azure Kubernetes possono abilitare il ruolo Monitoring Reader direttamente distribuendo il modello.
Nota
Attualmente in Bicep non è possibile definire in modo esplicito l'ambito dell'assegnazione di ruolo Monitoring Reader su un parametro stringa "ID risorsa" per un'area di lavoro di Monitoraggio di Azure come in un modello di Resource Manager. Bicep prevede un valore di tipo resource | tenant. Inoltre, non esiste alcuna specifica di API REST per un'area di lavoro di Monitoraggio di Azure.
Pertanto, l'ambito predefinito per il ruolo Monitoring Reader è nel gruppo di risorse. Il ruolo viene applicato alla stessa area di lavoro di Monitoraggio di Azure in base all'ereditarietà, cosa che è il comportamento previsto. Dopo aver distribuito questo modello Bicep, all'istanza di Grafana vengono concesse le autorizzazioni Monitoring Reader per tutte le aree di lavoro di Monitoraggio di Azure in tale gruppo di risorse.
Recuperare i valori obbligatori per la risorsa Grafana
Se l'istanza di Grafana con gestione Azure è già collegata a un'area di lavoro di Monitoraggio di Azure, è necessario includere questo elenco nel modello. Nella pagina Panoramica per l'istanza di Grafana con gestione Azure nel portale di Azure selezionare Visualizzazione JSON e copiare il valore di azureMonitorWorkspaceIntegrations che sarà simile all'esempio seguente. Se non esiste, l'istanza non è stata collegata ad alcuna area di lavoro di Monitoraggio di Azure.
Modificare i valori seguenti nel file di parametri. Per i modelli ARM e Bicep viene usato lo stesso set di valori. Recuperare l'ID risorsa delle risorse dalla Visualizzazione JSON della relativa pagina di Panoramica.
Parametro
Valore
azureMonitorWorkspaceResourceId
ID risorsa per l'area di lavoro di Monitoraggio di Azure. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'area di lavoro di Monitoraggio di Azure.
azureMonitorWorkspaceLocation
Posizione dell'area di lavoro di Monitoraggio di Azure. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'area di lavoro di Monitoraggio di Azure.
clusterResourceId
ID risorsa per il cluster del servizio Azure Kubernetes. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per il cluster.
clusterLocation
Posizione del cluster del servizio Azure Kubernetes. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per il cluster.
metricLabelsAllowlist
Elenco delimitato da virgole delle chiavi delle etichette kubernetes da usare nella metrica delle etichette della risorsa.
metricAnnotationsAllowList
Elenco delimitato da virgole di altre chiavi di etichetta Kubernetes da usare nella metrica delle annotazioni della risorsa.
grafanaResourceId
ID risorsa per l'istanza di Grafana gestita. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'istanza di Grafana.
grafanaLocation
Posizione per l'istanza di Grafana gestita. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'istanza di Grafana.
grafanaSku
SKU per l'istanza di Grafana gestita. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'istanza di Grafana. Usare sku.name.
Aprire il file modello e aggiornare la proprietà grafanaIntegrations alla fine del file con i valori recuperati dall'istanza di Grafana. L'aspetto sarà simile agli esempi seguenti. In questi esempi full_resource_id_1 e full_resource_id_2 erano già presenti nel codice JSON della risorsa Grafana con gestione Azure. La voce azureMonitorWorkspaceResourceId finale è già presente nel modello e viene usata per il collegamento all'ID risorsa dell'area di lavoro di Monitoraggio di Azure fornito nel file dei parametri.
Distribuire il modello con il file di parametri usando qualsiasi metodo valido per la distribuzione di modelli di Resource Manager. Per esempi di metodi diversi, vedere Distribuire i modelli di esempio.
Abilitare con Terraform
Prerequisiti
È necessario creare già l'area di lavoro di Monitoraggio di Azure e l'area di lavoro di Grafana con gestione Azure.
Il modello deve essere distribuito nello stesso gruppo di risorse dell'area di lavoro di Grafana con gestione Azure.
Gli utenti con il ruolo Amministratore accesso utente nella sottoscrizione del cluster del servizio Azure Kubernetes possono abilitare il ruolo Lettore monitoraggio direttamente distribuendo il modello.
Se l'istanza di Grafana con gestione Azure si trova in una sottoscrizione diversa da quella dell'area di lavoro di Monitoraggio di Azure, registrare la sottoscrizione dell'area di lavoro di Monitoraggio di Azure con il provider di risorse Microsoft.Dashboard seguendo questa documentazione.
Recuperare i valori obbligatori per una risorsa Grafana
Nella pagina Panoramica per l'istanza di Grafana con gestione Azure nel portale di Azure selezionare Visualizzazione JSON.
Se si usa un'istanza di Grafana con gestione Azure esistente già collegata a un'area di lavoro di Monitoraggio di Azure, è necessario l'elenco delle integrazioni di Grafana. Copiare il valore del campo azureMonitorWorkspaceIntegrations. Se non esiste, l'istanza non è stata collegata ad alcuna area di lavoro di Monitoraggio di Azure. Aggiornare il blocco azure_monitor_workspace_integrations in main.tf con l'elenco delle integrazioni di Grafana.
Se si distribuisce un nuovo cluster del servizio Azure Kubernetes usando Terraform con il componente aggiuntivo Prometheus gestito abilitato, seguire questa procedura:
Modificare le variabili nel file variables.tf con i valori dei parametri corretti.
Eseguire terraform init -upgrade per inizializzare la distribuzione di Terraform.
Eseguire terraform plan -out main.tfplan per inizializzare la distribuzione di Terraform.
Eseguire terraform apply main.tfplan per applicare il piano di esecuzione all'infrastruttura cloud.
Nota: passare le variabili per le chiavi annotations_allowed e labels_allowed in main.tf solo quando tali valori esistono. Questi blocchi sono facoltativi.
Nota
Modificare il file main.tf in modo appropriato prima di eseguire il modello terraform. Aggiungere tutti i valori di azure_monitor_workspace_integrations esistenti alla risorsa Grafana prima di eseguire il modello. In caso contrario, i valori meno recenti vengono eliminati e sostituiti con ciò che è presente nel modello durante la distribuzione. Gli utenti con il ruolo Amministratore accesso utente nella sottoscrizione del cluster del servizio Azure Kubernetes possono abilitare il ruolo Lettore monitoraggio direttamente distribuendo il modello. Modificare il parametro grafanaSku se si usa un SKU non standard ed eseguire infine questo modello nel gruppo di risorse della risorsa Grafana.
Eseguire l'abilitazione con Criteri di Azure
Scaricare il modello e i file dei parametri di Criteri di Azure.
Dopo aver creato la definizione dei criteri, nel portale di Azure selezionare Criteri e quindi Definizioni. Selezionare la definizione di criteri creata.
Selezionare Assegna e immettere i dettagli nella scheda Parametri. Selezionare Rivedi e crea.
Se si desidera applicare i criteri a un cluster esistente, creare un'Attività di correzione per tale risorsa cluster da Assegnazione di criteri.
Dopo aver assegnato i criteri alla sottoscrizione, ogni volta che si crea un nuovo cluster senza Prometheus abilitato, i criteri verranno eseguiti e distribuiti per abilitare il monitoraggio di Prometheus.
Usare uno dei comandi seguenti per abilitare il monitoraggio dei cluster del servizio Azure Kubernetes e abilitati per Arc. Se non si specifica un'area di lavoro Log Analytics esistente, verrà usata l'area di lavoro predefinita per il gruppo di risorse. Se un'area di lavoro predefinita non esiste già nell'area del cluster, ne verrà creata una con un nome nel formato DefaultWorkspace-<GUID>-<Region>.
Prerequisiti
Interfaccia della riga di comando di Azure versione 2.43.0 o successiva
L'autenticazione dell'identità gestita è predefinita nell'interfaccia della riga di comando versione 2.49.0 o successiva.
Estensione Azure k8s versione 1.3.7 o successiva
L'autenticazione dell'identità gestita è predefinita in k8s-extension versione 1.43.0 o successiva.
L'autenticazione dell'identità gestita non è supportata per i cluster Kubernetes abilitati per Arc con nodi ARO (Azure Red Hat Openshift) o Windows. Usare l'autenticazione legacy.
Per l'interfaccia della riga di comando versione 2.54.0 o successiva, lo schema di registrazione verrà configurato per ContainerLogV2 usando ConfigMap.
Nota
È possibile abilitare lo schema ContainerLogV2 per un cluster usando la regola di raccolta dati del cluster o ConfigMap. Se entrambe le impostazioni sono abilitate, ConfigMap avrà la precedenza. I log stdout e stderr verranno inseriti nella tabella ContainerLog solo quando sia DCR che ConfigMap vengono esplicitamente disattivati.
Cluster del servizio Azure Kubernetes
### 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
Esempio
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 con abilitazione di 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>
Se il cluster è configurato con un proxy di inoltro, le impostazioni proxy vengono applicate automaticamente all'estensione. Nel caso di un cluster con AMPLS + proxy, la configurazione proxy deve essere ignorata. Eseguire l'onboarding dell'estensione con l'impostazione di configurazione amalogs.ignoreExtensionProxySettings=true.
Cluster abilitato per Arc con nodi ARO o OpenShift o Windows
L'autenticazione dell'identità gestita non è supportata per i cluster Kubernetes abilitati per Arc con nodi ARO (Azure Red Hat OpenShift), OpenShift o Windows. Usare l'autenticazione legacy specificando amalogs.useAADAuth=false come nell'esempio seguente.
Il comando seguente elimina solo l'istanza dell'estensione, ma non elimina l'area di lavoro Log Analytics. I dati nella risorsa di Log Analytics sono rimasti intatti.
Modificare i valori seguenti nel file di parametri. Per i modelli ARM e Bicep viene usato lo stesso set di valori. Recuperare l'ID risorsa delle risorse dalla Visualizzazione JSON della relativa pagina di Panoramica.
Parametro
Descrizione
Servizio Azure Kubernetes: aksResourceId Arc: clusterResourceId
ID risorsa del cluster.
Servizio Azure Kubernetes: aksResourceLocation Arc: clusterRegion
Località del cluster.
Servizio Azure Kubernetes: workspaceResourceId Arc: workspaceResourceId
ID risorsa dell'area di lavoro Log Analytics.
Arc: workspaceRegion
Area dell'area di lavoro Log Analytics.
Arc: workspaceDomain
Dominio dell'area di lavoro Log Analytics. opinsights.azure.com per cloud pubblico di Azure opinsights.azure.us per AzureUSGovernment.
Servizio Azure Kubernetes: resourceTagValues
Valori di tag specificati per la regola di raccolta dati (DCR) dell’estensione Dati analitici sui contenitori esistente del cluster e nome della regola. Il nome sarà MSCI-<clusterName>-<clusterRegion> e questa risorsa creata in un gruppo di risorse cluster del servizio Azure Kubernetes. Per il primo onboarding, è possibile impostare valori di tag arbitrari.
Distribuire il modello con il file di parametri usando qualsiasi metodo valido per la distribuzione di modelli di Resource Manager. Per esempi di metodi diversi, vedere Distribuire i modelli di esempio.
Nuovo cluster del servizio Azure Kubernetes
Scaricare il file modello Terraform a seconda che si voglia abilitare la raccolta Syslog.
Modificare la risorsa azurerm_kubernetes_cluster in main.tf in base alle impostazioni del cluster.
Aggiornare i parametri in variables.tf per sostituire i valori in "<>"
Parametro
Descrizione
aks_resource_group_name
Usare i valori nella pagina Panoramica del servizio Azure Kubernetes per il gruppo di risorse.
resource_group_location
Usare i valori nella pagina Panoramica del servizio Azure Kubernetes per il gruppo di risorse.
cluster_name
Definire il nome del cluster da creare.
workspace_resource_id
Usare l'ID risorsa dell'area di lavoro Log Analytics.
workspace_region
Usare la posizione dell'area di lavoro Log Analytics.
resource_tag_values
Abbinare i valori di tag specificati esistenti per la regola di raccolta dati (DCR) dell'estensione Dati analitici sui contenitori esistente del cluster e il nome della regola. Il nome corrisponderà a MSCI-<clusterName>-<clusterRegion> e questa risorsa verrà creata nello stesso gruppo di risorse dei cluster del servizio Azure Kubernetes. Per il primo onboarding, è possibile impostare valori di tag arbitrari.
enabledContainerLogV2
Impostare questo valore del parametro su true per usare il valore predefinito ContainerLogV2 consigliato.
Copiare le risorse DCR e DCRA dai modelli Terraform
Eseguire terraform plan -out main.tfplan e assicurarsi che la modifica stia aggiungendo la proprietà oms_agent. Nota: se la risorsa azurerm_kubernetes_cluster definita è diversa durante il piano terraform, il cluster esistente verrà eliminato e ricreato.
Eseguire terraform apply main.tfplan per applicare il piano di esecuzione all'infrastruttura cloud.
Suggerimento
Modificare il file main.tf in modo appropriato prima di eseguire il modello terraform
I dati inizieranno a fluire dopo 10 minuti perché il cluster deve essere prima predisposto
WorkspaceID deve corrispondere al formato /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/example-resource-group/providers/Microsoft.OperationalInsights/workspaces/workspaceValue
Se il gruppo di risorse esiste già, eseguire terraform import azurerm_resource_group.rg /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name> prima del piano terraform
Portale di Azure
Nella scheda Definizioni del menu Criteri nel portale di Azure creare una definizione di criteri con i dettagli seguenti.
Percorso definizione: sottoscrizione di Azure in cui deve essere archiviata la definizione dei criteri.
Nome: AKS-Monitoring-Addon
Descrizione: criteri personalizzati di Azure per abilitare il componente aggiuntivo di monitoraggio nei cluster Azure Kubernetes.
Categoria: selezionare Usa esistente e quindi Kubernetes dall'elenco a discesa.
Dopo aver assegnato i criteri alla sottoscrizione, ogni volta che si crea un nuovo cluster senza Prometheus abilitato, i criteri verranno eseguiti e distribuiti per abilitare il monitoraggio di Prometheus.
Abilitare il monitoraggio completo con il portale di Azure
Nuovo cluster del servizio Azure Kubernetes (Prometheus, Container Insights e Grafana)
Quando si crea un nuovo cluster del servizio Azure Kubernetes nel portale di Azure, è possibile abilitare Prometheus, Container Insights e Grafana dalla scheda Monitoraggio. Assicurarsi di aver selezionato le caselle Abilitare log contenitori, Abilitare le metriche di Prometheus e Abilitare Grafana.
Cluster esistente (Prometheus, Container Insights e Grafana)
Passare al cluster del servizio Azure Kubernetes nel portale di Azure.
Nel menu di servizio, in Monitoraggio, selezionare Informazioni dettagliate>Configurare monitoraggio.
Le informazioni dettagliate sui contenitori sono già abilitate. Selezionare le caselle Abilitare le metriche di Prometheus e Abilitare Grafana. Se si dispone di un'area di lavoro di Monitoraggio di Azure esistente e di un'area di lavoro Grafana, vengono selezionate automaticamente.
Selezionare Impostazioni avanzate per selezionare aree di lavoro alternative o crearne di nuove. L'impostazione Preimpostazioni costi consente di modificare i dettagli predefiniti della raccolta per ridurre i costi di monitoraggio. Per informazioni dettagliate, vedere Abilitare le impostazioni di ottimizzazione dei costi in Container Insights.
Seleziona Configura.
Cluster esistente (solo Prometheus)
Passare al cluster del servizio Azure Kubernetes nel portale di Azure.
Nel menu di servizio, in Monitoraggio, selezionare Informazioni dettagliate>Configurare monitoraggio.
Selezionare la casella Abilitare le metriche di Prometheus.
Selezionare Impostazioni avanzate per selezionare aree di lavoro alternative o crearne di nuove. L'impostazione Preimpostazioni costi consente di modificare i dettagli predefiniti della raccolta per ridurre i costi di monitoraggio.
Seleziona Configura.
Abilitare la raccolta delle metriche di Windows (anteprima)
Nota
Non esiste alcun limite di CPU/memoria in windows-exporter-daemonset.yaml, quindi potrebbe eseguire il over-provisioning dei nodi Di Windows
Per altri dettagli, vedere Prenotazione delle risorse
Durante la distribuzione dei carichi di lavoro, impostare i limiti di memoria delle risorse e CPU per i contenitori. Ciò sottrae anche da NodeAllocatable e consente all'utilità di pianificazione a livello di cluster di determinare quali pod inserire nei nodi.
La pianificazione dei pod senza limiti può eseguire il provisioning eccessivo dei nodi Windows e in casi estremi può causare la mancata integrità dei nodi.
A partire dalla versione 6.4.0-main-02-22-2023-3ee44b9e del contenitore del componente aggiuntivo Prometheus gestito (prometheus_collector), la raccolta di metriche di Windows è stata abilitata per i cluster del servizio Azure Kubernetes. L'onboarding nel componente aggiuntivo Metriche di Monitoraggio di Azure consente ai pod Windows DaemonSet di avviare l'esecuzione nei pool di nodi. Sono supportati sia Windows Server 2019 che Windows Server 2022. Seguire questa procedura per abilitare i pod per raccogliere le metriche dai pool di nodi di Windows.
Installare manualmente Windows-Exporter nei nodi del servizio Azure Kubernetes per accedere alle metriche di Windows distribuendo il file YAML windows-exporter-daemonset. Abilitare i raccoglitori seguenti:
Distribuire il file YAML windows-exporter-daemonset. Si noti che, se nel nodo sono presenti taint applicati, sarà necessario applicare le tolleranze appropriate.
Abilitare le regole di registrazione necessarie per i dashboard predefiniti:
Se si esegue l'onboarding usando l'interfaccia della riga di comando, includere l'opzione --enable-windows-recording-rules.
Se si esegue l'onboarding usando un modello di Resource Manager, Bicep o Criteri di Azure, impostare enableWindowsRecordingRules su true nel file dei parametri.
Se il cluster è già stato sottoposto a onboarding, usare questo modello di Resource Manager e questo file di parametri per creare i gruppi di regole. Verranno aggiunte le regole di registrazione necessarie. Non si tratta di un'operazione ARM nel cluster e non influisce sullo stato di monitoraggio corrente del cluster.
Verificare la distribuzione
Usare lo strumento da riga di comando kubectl per verificare che l'agente sia distribuito correttamente.
Prometheus gestito
Verificare che il DaemonSet sia stato distribuito correttamente nei pool di nodi Linux
kubectl get ds ama-metrics-node --namespace=kube-system
Il numero di pod deve essere uguale al numero di nodi Linux nel cluster. Il risultato dovrebbe essere simile all'esempio seguente:
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
Verificare che i nodi Windows siano stati distribuiti correttamente
kubectl get ds ama-metrics-win-node --namespace=kube-system
Il numero di pod deve essere uguale al numero di nodi Windows nel cluster. Il risultato dovrebbe essere simile all'esempio seguente:
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
Verificare che i due ReplicaSet siano stati distribuiti per Prometheus
kubectl get rs --namespace=kube-system
Il risultato dovrebbe essere simile all'esempio seguente:
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
Informazioni dettagliate contenitore
Verificare che i DaemonSet siano stati distribuiti correttamente nei pool di nodi Linux
kubectl get ds ama-logs --namespace=kube-system
Il numero di pod deve essere uguale al numero di nodi Linux nel cluster. Il risultato dovrebbe essere simile all'esempio seguente:
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
Verificare che i nodi Windows siano stati distribuiti correttamente
kubectl get ds ama-logs-windows --namespace=kube-system
Il numero di pod deve essere uguale al numero di nodi Windows nel cluster. Il risultato dovrebbe essere simile all'esempio seguente:
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
Verificare la distribuzione della soluzione Container Insights
kubectl get deployment ama-logs-rs --namespace=kube-system
Il risultato dovrebbe essere simile all'esempio seguente:
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
Visualizzare la configurazione con l'interfaccia della riga di comando
Usare il comando aks show per verificare se la soluzione è abilitata, l'ID risorsa dell'area di lavoro Log Analytics e le informazioni di riepilogo sul cluster.
az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>
Il comando restituirà informazioni in formato JSON sulla soluzione. La sezione addonProfiles deve includere informazioni su omsagent come nell'esempio seguente:
Quando si abilita il monitoraggio, nella sottoscrizione vengono create le risorse seguenti:
Nome della risorsa
Tipo di risorsa
Gruppo di risorse
Area/Posizione
Descrizione
MSCI-<aksclusterregion>-<clustername>
Regola di raccolta dei dati
Uguale al cluster
Uguale all'area di lavoro Log Analytics
Questa regola di raccolta dati si applica alla raccolta di log da parte dell'agente di Monitoraggio di Azure, che usa l'area di lavoro Log Analytics come destinazione ed è associata alla risorsa cluster del servizio Azure Kubernetes.
MSPROM-<aksclusterregion>-<clustername>
Regola di raccolta dei dati
Uguale al cluster
Uguale all'area di lavoro Monitoraggio di Azure
Questa regola di raccolta dati si applica alla raccolta di metriche Prometheus in base al componente aggiuntivo delle metriche, che dispone dell'area di lavoro monitoraggio di Azure scelta come destinazione ed è associata anche alla risorsa cluster del servizio Azure Kubernetes
MSPROM-<aksclusterregion>-<clustername>
Endpoint di raccolta dati
Uguale al cluster
Uguale all'area di lavoro Monitoraggio di Azure
Questo endpoint di raccolta dati viene usato dalla regola di raccolta dati precedente per l'inserimento di metriche Prometheus dal componente aggiuntivo per le metriche
Quando si crea una nuova area di lavoro di Monitoraggio di Azure, vengono create le risorse aggiuntive seguenti come parte di essa
DCE creato quando si usa il server OSS Prometheus per scrivere in remoto nell'area di lavoro di Monitoraggio di Azure.
Differenze tra cluster Windows e Linux
Le principali differenze nel monitoraggio di un cluster Windows Server rispetto a un cluster Linux includono:
Windows non dispone di una metrica RSS Memoria. Di conseguenza, non è disponibile per nodi e contenitori di Windows. La metrica Set di lavoro è disponibile.
Le informazioni sulla capacità di archiviazione su disco non sono disponibili per i nodi Windows.
Vengono monitorati solo gli ambienti pod, non gli ambienti Docker.
Con la versione di anteprima sono supportati un massimo di 30 contenitori di Windows Server. Questa limitazione non si applica ai contenitori Linux.
Nota
Il supporto di Container Insights per il sistema operativo Windows Server 2022 è disponibile in anteprima.
L'agente Linux in contenitori (pod replicaset) effettua chiamate API a tutti i nodi Windows sulla porta sicura Kubelet (10250) all'interno del cluster per raccogliere le metriche correlate alle prestazioni del nodo e del contenitore. La porta sicura Kubelet (:10250) deve essere aperta nella rete virtuale del cluster per la raccolta di metriche correlate alle prestazioni del contenitore e del nodo Windows in ingresso e in uscita.
Se si dispone di un cluster Kubernetes con nodi Windows, esaminare e configurare il gruppo di sicurezza di rete e i criteri di rete per assicurarsi che la porta sicura Kubelet (:10250) sia aperta sia per la rete virtuale in ingresso che per quella in uscita nella rete virtuale del cluster.
Una volta abilitato il monitoraggio per rilevare l'integrità e l'utilizzo delle risorse del cluster e dei carichi di lavoro del servizio Azure Kubernetes in esecuzione, è possibile trovare informazioni su come usare Dati analitici sui contenitori.
In questo modulo verrà illustrato come usare Criteri di Azure per Kubernetes per imporre regole e rilevare una mancata conformità nei cluster del servizio Azure Kubernetes.