Habilitar o monitoramento para clusters Kubernetes
Este artigo descreve como habilitar o monitoramento completo de seus clusters Kubernetes usando os seguintes recursos do Azure Monitor:
- Prometheus gerenciado para coleta de métricas
- Informações de contêiner para coleta de logs
- Grafana gerenciado para visualização.
Usando o portal do Azure, você pode habilitar todos os recursos ao mesmo tempo. Você também pode habilitá-los individualmente usando a CLI do Azure, o modelo do Azure Resource Manager, o Terraform ou a Política do Azure. Cada um desses métodos é descrito neste artigo.
Importante
Os clusters do Kubernetes geram muitos dados de log, o que pode resultar em custos significativos se você não for seletivo sobre os logs coletados. Antes de habilitar o monitoramento para seu cluster, consulte os seguintes artigos para garantir que seu ambiente seja otimizado para custo e que você limite sua coleta de logs apenas aos dados necessários:
- Configurar a coleta de dados e a otimização de custos no Container insights usando a regra de coleta de dados
Detalhes sobre como personalizar a coleta de logs depois de habilitar o monitoramento, incluindo o uso de configurações predefinidas de otimização de custos. - Práticas recomendadas para monitorar o Kubernetes com o Azure Monitor
Práticas recomendadas para monitorar clusters Kubernetes organizados pelos cinco pilares do Azure Well-Architected Framework, incluindo otimização de custos. - Otimização de custos no Azure Monitor
Práticas recomendadas para configurar todos os recursos do Azure Monitor para otimizar seus custos e limitar a quantidade de dados que você coleta.
Clusters suportados
Este artigo fornece orientações de integração para os seguintes tipos de clusters. Quaisquer diferenças no processo para cada tipo são anotadas nas seções relevantes.
Pré-requisitos
Permissões
- Você precisa de pelo menos acesso de Colaborador ao cluster para integração.
- Você precisa do Leitor de Monitoramento ou do Colaborador de Monitoramento para exibir dados depois que o monitoramento estiver habilitado.
Pré-requisitos do Managed Prometheus
- O cluster tem de utilizar a autenticação de identidade gerida.
- Os seguintes provedores de recursos devem ser registrados na assinatura do cluster AKS e no espaço de trabalho do Azure Monitor:
- Microsoft.ContainerService
- Microsoft.Insights
- Microsoft.AlertsManagement
- Microsoft.Monitor
- Os seguintes provedores de recursos devem estar registrados na assinatura do espaço de trabalho Grafana:
- Microsoft.Dashboard
Pré-requisitos de clusters Kubernetes habilitados para Arc
- Pré-requisitos para extensões de cluster do Kubernetes habilitadas para Azure Arc.
- Verifique os requisitos de firewall, além dos requisitos de rede do Kubernetes compatíveis com o Azure Arc.
- Se instalou anteriormente a monitorização para o AKS, certifique-se de que desativou a monitorização antes de prosseguir para evitar problemas durante a instalação da extensão.
- Se você instalou anteriormente o monitoramento em um cluster usando um script sem extensões de cluster, siga as instruções em Desabilitar o monitoramento do cluster do Kubernetes para excluir este gráfico de leme.
Nota
A extensão Managed Prometheus Arc-Enabled Kubernetes não suporta as seguintes configurações:
- Distribuições do Red Hat Openshift, incluindo o Azure Red Hat OpenShift (ARO)
- Nós do Windows
Áreas de Trabalho
A tabela a seguir descreve os espaços de trabalho necessários para dar suporte a insights do Managed Prometheus e do Container. Você pode criar cada espaço de trabalho como parte do processo de integração ou usar um espaço de trabalho existente. Consulte Criar uma arquitetura de espaço de trabalho do Log Analytics para obter orientação sobre quantos espaços de trabalho criar e onde eles devem ser colocados.
Caraterística | Área de trabalho | Notas |
---|---|---|
Prometheus Gerido | Espaço de trabalho do Azure Monitor | Contributor permissão é suficiente para habilitar o complemento para enviar dados para o espaço de trabalho do Azure Monitor. Você precisará de Owner permissão de nível para vincular seu Espaço de Trabalho do Azure Monitor para exibir métricas no Azure Managed Grafana. Isso é necessário porque o usuário que executa a etapa de integração precisa ser capaz de atribuir a função Identidade Monitoring Reader do Sistema Grafana Gerenciado do Azure no Espaço de Trabalho do Azure Monitor para consultar as métricas. |
Informações de contentores | Área de trabalho do Log Analytics | Você pode anexar um cluster AKS a um espaço de trabalho do Log Analytics em uma assinatura diferente do Azure no mesmo locatário do Microsoft Entra, mas deve usar a CLI do Azure ou um modelo do Azure Resource Manager. No momento, não é possível executar essa configuração com o portal do Azure. Se você estiver conectando um cluster AKS existente a um espaço de trabalho do Log Analytics em outra assinatura, o provedor de recursos Microsoft.ContainerService deverá estar registrado na assinatura com o espaço de trabalho do Log Analytics. Para obter mais informações, consulte Registar fornecedor de recursos. Para obter uma lista dos pares de mapeamento suportados a serem usados para o espaço de trabalho padrão, consulte Mapeamentos de região suportados pelo Container insights. |
Managed Grafana | Espaço de trabalho do Azure Managed Grafana | Vincule seu espaço de trabalho do Grafana ao espaço de trabalho do Azure Monitor para disponibilizar as métricas do Prometheus coletadas do cluster para os painéis do Grafana. |
Ativar Prometheus e Grafana
Use um dos seguintes métodos para habilitar a raspagem de métricas do Prometheus do cluster e habilitar o Managed Grafana para visualizar as métricas. Consulte Vincular um espaço de trabalho do Grafana para obter opções para conectar seu espaço de trabalho do Azure Monitor e o espaço de trabalho do Azure Managed Grafana.
Nota
Se você tiver um único Recurso do Azure Monitor vinculado a privados, a habilitação do Prometheus não funcionará se o cluster AKS e o Espaço de Trabalho do Azure Monitor estiverem em regiões diferentes. A configuração necessária para o complemento Prometheus não está disponível entre regiões devido à restrição de link privado. Para resolver isso, crie um novo DCE no local do cluster AKS e um novo DCRA (associação) na mesma região do cluster AKS. Associe o novo DCE ao cluster AKS e nomeie a nova associação (DCRA) como configurationAccessEndpoint. Para obter instruções completas sobre como configurar os DCEs associados ao seu espaço de trabalho do Azure Monitor para usar um Link Privado para ingestão de dados, consulte Habilitar link privado para monitoramento do Kubernetes no Azure Monitor.
Se você não especificar um espaço de trabalho existente do Azure Monitor nos comandos a seguir, o espaço de trabalho padrão para o grupo de recursos será usado. Se ainda não existir um espaço de trabalho padrão na região do cluster, um com um nome no formato DefaultAzureMonitorWorkspace-<mapped_region>
será criado em um grupo de recursos com o nome DefaultRG-<cluster_region>
.
Pré-requisitos
- Az CLI versão 2.49.0 ou superior é necessária.
- A extensão aks-preview deve ser desinstalada dos clusters AKS usando o comando
az extension remove --name aks-preview
. - A extensão k8s deve ser instalada usando o comando
az extension add --name k8s-extension
. - É necessária a extensão k8s versão 1.4.1 ou superior.
Cluster do AKS
Use a -enable-azure-monitor-metrics
opção az aks create
ou az aks update
(dependendo se você está criando um novo cluster ou atualizando um cluster existente) para instalar o complemento de métricas que raspa as métricas do Prometheus.
Comandos de exemplo
### 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 habilitado para arco
### 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]"
Qualquer um dos comandos pode usar os seguintes parâmetros opcionais:
- AKS:
--ksm-metric-annotations-allow-list
Arco:--AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList
Lista separada por vírgulas de chaves de anotações do Kubernetes usadas na métrica de kube_resource_annotations do recurso. Por exemplo, kube_pod_annotations é a métrica de anotações para o recurso pods. Por padrão, essa métrica contém apenas rótulos de nome e namespace. Para incluir mais anotações, forneça uma lista de nomes de recursos em sua forma plural e chaves de anotação do Kubernetes que você deseja permitir para eles. Um único*
recurso pode ser fornecido para permitir quaisquer anotações, mas isso tem graves implicações de desempenho. Por exemplo,pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],...
. - AKS:
--ksm-metric-labels-allow-list
Arco:--AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist
Lista separada por vírgulas de mais chaves de rótulo do Kubernetes que são usadas na métrica kube_resource_labels métrica kube_resource_labels do recurso. Por exemplo, kube_pod_labels é a métrica de rótulos para o recurso pods. Por padrão, essa métrica contém apenas rótulos de nome e namespace. Para incluir mais rótulos, forneça uma lista de nomes de recursos em sua forma plural e chaves de rótulo do Kubernetes que você deseja permitir para eles Um único*
pode ser fornecido para cada recurso para permitir quaisquer rótulos, mas isso tem graves implicações de desempenho. Por exemplo,pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],...
. - AKS:
--enable-windows-recording-rules
Permite ativar os grupos de regras de gravação necessários para o funcionamento adequado dos painéis do Windows.
Habilitar insights de contêiner
Use um dos seguintes métodos para habilitar o Container insights em seu cluster. Quando terminar, consulte Configurar a recolha de dados do agente para informações de contentores para personalizar a configuração e para garantir que não recolhe mais dados do que o necessário.
Use um dos seguintes comandos para habilitar o monitoramento de seus clusters habilitados para AKS e Arc. Se você não especificar um espaço de trabalho existente do Log Analytics, o espaço de trabalho padrão para o grupo de recursos será usado. Se ainda não existir um espaço de trabalho padrão na região do cluster, será criado um com um nome no formato DefaultWorkspace-<GUID>-<Region>
.
Pré-requisitos
- Azure CLI versão 2.43.0 ou superior
- A autenticação de identidade gerenciada é padrão na CLI versão 2.49.0 ou superior.
- Azure k8s-extension versão 1.3.7 ou superior
- A autenticação de identidade gerenciada é o padrão na extensão k8s versão 1.43.0 ou superior.
- A autenticação de identidade gerenciada não é suportada para clusters Kubernetes habilitados para Arc com ARO (Azure Red Hat Openshift) ou nós do Windows. Use a autenticação herdada.
- Para CLI versão 2.54.0 ou superior, o esquema de log será configurado para ContainerLogV2 usando ConfigMap.
Nota
Você pode habilitar o esquema ContainerLogV2 para um cluster usando a Regra de Coleta de Dados (DCR) ou o ConfigMap do cluster. Se ambas as configurações estiverem habilitadas, o ConfigMap terá precedência. Os logs Stdout e stderr só serão ingeridos na tabela ContainerLog quando o DCR e o ConfigMap estiverem explicitamente desativados.
Cluster do 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
Exemplo
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 habilitado para arco
### 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>
Consulte a seção solicitações de recursos e limites do gráfico Helm para obter as definições de configuração disponíveis.
Exemplo
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 habilitado para arco com proxy de encaminhamento
Se o cluster estiver configurado com um proxy de encaminhamento, as configurações de proxy serão aplicadas automaticamente à extensão. No caso de um cluster com AMPLS + proxy, a configuração de proxy deve ser ignorada. Integre a extensão com a configuração .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 habilitado para arco com nós ARO ou OpenShift ou Windows
A autenticação de identidade gerenciada não é suportada para clusters Kubernetes habilitados para Arc com ARO (Azure Red Hat OpenShift) ou nós OpenShift ou Windows. Use a autenticação herdada especificando amalogs.useAADAuth=false
como no exemplo a seguir.
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
Excluir instância de extensão
O comando a seguir exclui apenas a instância de extensão, mas não exclui o espaço de trabalho do Log Analytics. Os dados no recurso Log Analytics são deixados intactos.
az k8s-extension delete --name azuremonitor-containers --cluster-type connectedClusters --cluster-name <cluster-name> --resource-group <resource-group>
Habilite o monitoramento completo com o portal do Azure
Novo cluster AKS (Prometheus, Container insights, e Grafana)
Ao criar um novo cluster AKS no portal do Azure, você pode habilitar Prometheus, Container insights e Grafana na guia Monitoramento. Certifique-se de marcar as caixas de seleção Habilitar logs de contêiner, Habilitar métricas Prometheus e Habilitar Grafana.
Cluster existente (Prometheus, Container insights, e Grafana)
- Navegue até o cluster AKS no portal do Azure.
- No menu de serviço, em Monitoramento, selecione Insights>Configurar monitoramento.
- O Container insights já está habilitado. Marque as caixas de seleção Ativar métricas Prometheus e Ativar Grafana . Se você tiver o espaço de trabalho do Azure Monitor e o espaço de trabalho do Grafana, eles serão selecionados para você.
- Selecione Configurações avançadas se quiser selecionar espaços de trabalho alternativos ou criar novos. A configuração Predefinições de custo permite modificar os detalhes de coleta padrão para reduzir os custos de monitoramento. Consulte Habilitar configurações de otimização de custos em Insights de contêiner para obter detalhes.
- Selecione Configurar.
Cluster existente (apenas Prometheus)
- Navegue até o cluster AKS no portal do Azure.
- No menu de serviço, em Monitoramento, selecione Insights>Configurar monitoramento.
- Marque a caixa de seleção Ativar métricas do Prometheus.
- Selecione Configurações avançadas se quiser selecionar espaços de trabalho alternativos ou criar novos. A configuração Predefinições de custo permite modificar os detalhes de coleta padrão para reduzir os custos de monitoramento.
- Selecione Configurar.
Habilitar a coleta de métricas do Windows (visualização)
Nota
Não há limite de CPU/memória no windows-exporter-daemonset.yaml, portanto, ele pode provisionar demais os nós do Windows
Para obter mais detalhes, consulte Reserva de recursos
À medida que você implanta cargas de trabalho, defina a memória de recursos e os limites de CPU em contêineres. Isso também subtrai do NodeAllocatable e ajuda o agendador de todo o cluster a determinar quais pods colocar em quais nós. Agendar pods sem limites pode provisionar demais os nós do Windows e, em casos extremos, pode fazer com que os nós se tornem não íntegros.
A partir da versão 6.4.0-main-02-22-2023-3ee44b9e do contêiner de complemento Managed Prometheus (prometheus_collector), a coleta de métricas do Windows foi habilitada para os clusters AKS. A integração ao complemento Azure Monitor Metrics permite que os pods DaemonSet do Windows comecem a ser executados em seus pools de nós. O Windows Server 2019 e o Windows Server 2022 são suportados. Siga estas etapas para permitir que os pods coletem métricas de seus pools de nós do Windows.
Instale manualmente o windows-exporter em nós AKS para acessar as métricas do Windows implantando o arquivo YAML windows-exporter-daemonset . Habilite os seguintes coletores:
[defaults]
container
memory
process
cpu_info
Para obter mais coletores, consulte Prometheus exporter for Windows metrics.
Implante o arquivo YAML windows-exporter-daemonset . Observe que, se houver alguma mancha aplicada no nó, você precisará aplicar as tolerâncias apropriadas.
kubectl apply -f windows-exporter-daemonset.yaml
Aplique o ama-metrics-settings-configmap ao cluster. Defina o
windowsexporter
ewindowskubeproxy
Booleans comotrue
. Para obter mais informações, consulte Metrics add-on settings configmap.Habilite as regras de gravação necessárias para os painéis prontos para uso:
- Se a integração estiver usando a CLI, inclua a opção
--enable-windows-recording-rules
. - Se a integração estiver usando um modelo ARM, Bíceps ou Política do Azure, defina
enableWindowsRecordingRules
comotrue
no arquivo de parâmetros. - Se o cluster já estiver integrado, use este modelo ARM e este arquivo de parâmetro para criar os grupos de regras. Isso adicionará as regras de gravação necessárias e não é uma operação ARM no cluster e não afeta o estado atual de monitoramento do cluster.
- Se a integração estiver usando a CLI, inclua a opção
Verificar a implementação
Use a ferramenta de linha de comando kubectl para verificar se o agente está implantado corretamente.
Prometheus Gerido
Verifique se o DaemonSet foi implantado corretamente nos pools de nós do Linux
kubectl get ds ama-metrics-node --namespace=kube-system
O número de pods deve ser igual ao número de nós Linux no cluster. A saída deve ser semelhante ao seguinte exemplo:
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
Verifique se os nós do Windows foram implantados corretamente
kubectl get ds ama-metrics-win-node --namespace=kube-system
O número de pods deve ser igual ao número de nós do Windows no cluster. A saída deve ser semelhante ao seguinte exemplo:
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
Verifique se os dois ReplicaSets foram implantados para o Prometheus
kubectl get rs --namespace=kube-system
A saída deve ser semelhante ao seguinte exemplo:
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
Informações de contentores
Verifique se os DaemonSets foram implantados corretamente nos pools de nós do Linux
kubectl get ds ama-logs --namespace=kube-system
O número de pods deve ser igual ao número de nós Linux no cluster. A saída deve ser semelhante ao seguinte exemplo:
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
Verifique se os nós do Windows foram implantados corretamente
kubectl get ds ama-logs-windows --namespace=kube-system
O número de pods deve ser igual ao número de nós do Windows no cluster. A saída deve ser semelhante ao seguinte exemplo:
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
Verificar a implantação da solução Container insights
kubectl get deployment ama-logs-rs --namespace=kube-system
A saída deve ser semelhante ao seguinte exemplo:
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
Ver configuração com CLI
Use o aks show
comando para descobrir se a solução está habilitada, o ID do recurso do espaço de trabalho do Log Analytics e informações resumidas sobre o cluster.
az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>
O comando retornará informações formatadas em JSON sobre a solução. A addonProfiles
seção deve incluir informações sobre o omsagent
como no exemplo a seguir:
"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
},
}
Recursos provisionados
Quando você habilita o monitoramento, os seguintes recursos são criados em sua assinatura:
Nome do Recurso | Tipo de Recurso | Grupo de Recursos | Região/Localização | Description |
---|---|---|---|---|
MSCI-<aksclusterregion>-<clustername> |
Regra de Recolha de Dados | O mesmo que cluster | O mesmo que o espaço de trabalho do Log Analytics | Esta regra de recolha de dados destina-se à recolha de registos pelo agente do Azure Monitor, que utiliza a área de trabalho do Log Analytics como destino e está associada ao recurso de cluster AKS. |
MSPROM-<aksclusterregion>-<clustername> |
Regra de Recolha de Dados | O mesmo que cluster | O mesmo que o espaço de trabalho do Azure Monitor | Esta regra de recolha de dados destina-se à recolha de métricas prometheus por addon de métricas, que tem a área de trabalho de monitorização do Azure escolhida como destino e também está associada ao recurso de cluster AKS |
MSPROM-<aksclusterregion>-<clustername> |
Ponto de extremidade de coleta de dados | O mesmo que cluster | O mesmo que o espaço de trabalho do Azure Monitor | Este ponto de extremidade de coleta de dados é usado pela regra de coleta de dados acima para ingerir métricas Prometheus do complemento de métricas |
Quando você cria um novo espaço de trabalho do Azure Monitor, os seguintes recursos adicionais são criados como parte dele
Nome do Recurso | Tipo de Recurso | Grupo de Recursos | Região/Localização | Description |
---|---|---|---|---|
<azuremonitor-workspace-name> |
Regra de Recolha de Dados | MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed | O mesmo que o Azure Monitor Workspace | DCR criado quando você usa o servidor OSS Prometheus para Gravação Remota no Espaço de Trabalho do Azure Monitor. |
<azuremonitor-workspace-name> |
Ponto Final de Recolha de Dados | MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed | O mesmo que o Azure Monitor Workspace | DCE criado quando você usa o servidor OSS Prometheus para Gravação Remota no Espaço de Trabalho do Azure Monitor. |
Diferenças entre clusters Windows e Linux
As principais diferenças no monitoramento de um cluster do Windows Server em comparação com um cluster Linux incluem:
- O Windows não tem uma métrica RSS de memória. Como resultado, ele não está disponível para nós e contêineres do Windows. A métrica Conjunto de Trabalho está disponível.
- As informações sobre a capacidade de armazenamento em disco não estão disponíveis para nós do Windows.
- Apenas os ambientes pod são monitorados, não os ambientes Docker.
- Com a versão de visualização, há suporte para um máximo de 30 contêineres do Windows Server. Essa limitação não se aplica a contêineres Linux.
Nota
O suporte de informações de contêiner para o sistema operacional Windows Server 2022 está em visualização.
O agente Linux em contêiner (pod replicaset) faz chamadas de API para todos os nós do Windows na porta segura do Kubelet (10250) dentro do cluster para coletar métricas relacionadas ao desempenho do nó e do contêiner. A porta segura do Kubelet (:10250) deve ser aberta na rede virtual do cluster para que a coleta de métricas relacionadas ao desempenho do nó do Windows e do contêiner funcione.
Se você tiver um cluster Kubernetes com nós do Windows, revise e configure o grupo de segurança de rede e as políticas de rede para garantir que a porta segura do Kubelet (:10250) esteja aberta para entrada e saída na rede virtual do cluster.