Configurar métricas de rede de contentores para o Azure Kubernetes Service (AKS)

Utilize métricas de redes de contentores para identificar quedas de pacotes, investigar o comportamento do DNS e identificar as cargas de trabalho envolvidas em problemas de rede. Este guia permite a recolha no Azure Kubernetes Service (AKS), liga-a a um backend Prometheus e mostra-lhe como visualizar a saúde da rede nos dashboards ACNS Grafana.

Use o serviço gerido Azure Monitor para Prometheus e visualize os painéis de rede diretamente no portal Azure. Os dashboards Grafana do portal estão disponíveis sem custo adicional de dashboard; não precisa de criar uma instância Azure Managed Grafana. Alternativamente, usa o teu próprio Prometheus e Grafana deployment. A recolha de métricas está disponível em planos de dados Cilium e não-Cilium suportados; métricas ao nível pod requerem Linux. Consulte a visão geral das métricas para a cobertura da plataforma e métricas disponíveis.

Nos clusters Cilium, pode então filtrar métricas individuais por carga de trabalho ou identidade de segurança, ou ativar métricas para IPs de destino externos e portas de destino. Estes são passos seguintes opcionais, não requisitos para a recolha básica.

Por exemplo, comece por incluir filtros para recolher métricas de fluxo de uma aplicação. Adicione filtros de exclusão apenas se precisar de uma exceção, como omitir tráfego para um destino específico. Para manter uma coleção ampla enquanto se removem observações descartadas em testes de carga, use antes um filtro apenas de exclusão. Veja exemplos de filtragem de métricas.

Para registos armazenados ou inspeção em tempo real do Hubble em vez de métricas, veja Configurar registos de rede de contentores.

Prerequisites

• Uma conta do Azure com uma subscrição ativa. Se necessário, crie uma conta gratuita.
• Bash no Azure Cloud Shell ou num terminal Bash local com a versão atual do CLI do Azure e kubectl. Corre az --version para verificar a instalação do teu CLI.
• Permissões para criar ou atualizar o cluster e os recursos de monitorização que escolher, e acesso de leitura ao espaço de trabalho do Azure Monitor que contém as métricas. Para o caminho gerido, consulte os pré-requisitos do Azure Monitor.
• Uma versão AKS Kubernetes suportada e sistema operativo de nó. Não crie novos pools de nós em imagens Azure Linux 2.0 retiradas. Ver Atualizar o sistema operativo do nó.
• Executar cargas de trabalho com atividade de rede para preencher os painéis de carga de trabalho. Um cluster vazio não exibirá tráfego da aplicação.
• Para métricas DNS no Cilium, configure a visibilidade DNS aplicando uma política de inspeção DNS e gerando tráfego DNS. Para métricas HTTP, completar a configuração da política da Camada 7: ativar o L7 no cluster, aplicar uma política de inspeção HTTP à carga de trabalho e gerar tráfego HTTP através dessa política. A configuração de filtros de métricas não aplica estas políticas nem verifica a geração de observações. Nenhuma delas é necessária para monitorização básica de rede ao nível dos nós.

Passo 1: Ativar o ACNS e ligar-se ao cluster

Inicia sessão com az login se estiveres a usar uma CLI local. Selecione a sua subscrição e defina os valores utilizados ao longo deste guia:

az account set --subscription "<subscription-id>"
export RESOURCE_GROUP="<aks-resource-group>"
export CLUSTER_NAME="<aks-cluster-name>"
export LOCATION="<azure-region>"

Usar um cluster existente

Se o ACNS já estiver ativado, ignora o comando update. Caso contrário, ative-o:

az aks update \
    --resource-group "$RESOURCE_GROUP" \
    --name "$CLUSTER_NAME" \
    --enable-acns

Ativar o ACNS não altera o plano de dados de um cluster existente. A filtragem métrica e a habilitação métrica adicional descrita posteriormente requerem Cilium. Para outras capacidades do ACNS e seus pré-requisitos, consulte a visão geral do ACNS.

Ou criar um novo cluster

Crie o grupo de recursos se ainda não existir:

az group create --name "$RESOURCE_GROUP" --location "$LOCATION"

Escolha uma das seguintes opções. Estes comandos usam a versão predefinida do AKS Kubernetes da região em vez de bloquearem uma versão antiga específica. Para escolher outra versão suportada, inspecione az aks get-versions --location "$LOCATION" -o table e adicione --kubernetes-version com a versão selecionada.

Cilium

Escolha o Cilium se planeia usar filtragem de métricas ao nível da origem ou as métricas adicionais de IP externo e porta de destino:

az aks create \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --generate-ssh-keys \
    --location "$LOCATION" \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --node-count 2 \
    --pod-cidr 192.168.0.0/16 \
    --enable-acns

Não-Cílio

Esta opção suporta a recolha das métricas disponíveis para o plano de dados não-Cilium. Não fornece o caminho de filtragem CNM específico da Cilium nem as funcionalidades de Segurança de Rede de Contentores. Para restrições FIPS, consulte as limitações da plataforma de métricas.

az aks create \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --generate-ssh-keys \
    --location "$LOCATION" \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --enable-acns

Obter credenciais de cluster

Para um cluster novo ou existente, estabeleça ligação e confirme o contexto atual:

az aks get-credentials --name "$CLUSTER_NAME" --resource-group "$RESOURCE_GROUP"

kubectl config current-context
kubectl get nodes

Pare se o contexto não for o cluster pretendido ou se os comandos falharem. Resolva problemas de ligação, permissões ou prontidão de nós antes de continuar.

Passo 2: Escolha um caminho de recolha

Configura primeiro um caminho. Se já recolheu métricas de rede com sucesso, preserve essa configuração e avance para o Passo 3 ou Passo 4. Configurar recolhas duplicadas pode aumentar a ingestão e distorcer as consultas.

Prometheus gerido do Azure e dashboards do portal

Utilize um espaço de trabalho Azure Monitor para métricas Prometheus. Um espaço de trabalho Log Analytics armazena logs e não substitui esta área de trabalho de métricas.

O exemplo seguinte cria um espaço de trabalho Azure Monitor no grupo de recursos do cluster. Se já tens um espaço de trabalho, define AZURE_MONITOR_NAME para o seu nome, salta a criação e obtém o ID usando o grupo de recursos real. Use uma localização suportada pelos workspaces do Azure Monitor.

Crie ou selecione um espaço de trabalho no Azure Monitor

export AZURE_MONITOR_NAME="<azure-monitor-name>"

az resource create \
    --resource-group "$RESOURCE_GROUP" \
    --namespace Microsoft.Monitor \
    --resource-type accounts \
    --name "$AZURE_MONITOR_NAME" \
    --location "$LOCATION" \
    --properties '{}'

Permitir a recolha gerida do Prometheus

Obtenha o ID do recurso do Azure Monitor workspace:

azuremonitorId=$(az resource show \
    --resource-group "$RESOURCE_GROUP" \
    --name "$AZURE_MONITOR_NAME" \
    --resource-type "Microsoft.Monitor/accounts" \
    --query id --output tsv)

Verifique o comando quanto a erros e confirme que azuremonitorId contém o ID do recurso do workspace pretendido antes de continuar. Ativar o scraping:

az aks update \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --enable-azure-monitor-metrics \
    --azure-monitor-workspace-resource-id "$azuremonitorId"

Verifique os pods de métricas do Azure Monitor:

kubectl get pods -n kube-system -o wide | grep ama-metrics

Resolva pods não preparados antes de verificar os dados. Executar pods por si só não garante uma raspagem ou ingestão bem-sucedida. Para problemas de permissões ou recolha, siga Ativar a monitorização no AKS.

Não é necessário nenhum recurso Grafana separado ou link Grafana para os painéis do portal Azure. Continue com a seleção de métricas e depois abra os painéis de rede no Passo 4.

O teu próprio Prometheus e Grafana

Use uma implementação Prometheus existente que possa descobrir pods Kubernetes e alcançar os endpoints das métricas do agente. Configura primeiro a autenticação da sua API Kubernetes, RBAC e acesso à rede. O exemplo seguinte cobre métricas ao nível do pod do Hubble; não configura métricas do Cilium ou do Retina ao nível do nó.

Adicione esta tarefa à sua lista scrape_configs atual, preservando as outras tarefas. Se um operador administrar o seu Prometheus, use o mecanismo de configuração suportado em vez de editar um ficheiro de configuração gerado. Substitua myAKSCluster pelo rótulo do cluster:

scrape_configs:
  - job_name: networkobservability-hubble
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_pod_label_k8s_app]
        regex: 'kube-system;(retina|cilium)'
        action: keep
      - source_labels: [__meta_kubernetes_pod_phase]
        regex: Running
        action: keep
      - source_labels: [__meta_kubernetes_pod_ip]
        regex: '([^:]+)'
        replacement: '$1:9965'
        target_label: __address__
      - source_labels: [__meta_kubernetes_pod_ip]
        regex: '(.+:.*)'
        replacement: '[$1]:9965'
        target_label: __address__
      - target_label: cluster
        replacement: myAKSCluster
      - source_labels: [__meta_kubernetes_pod_node_name]
        target_label: instance
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'hubble_dns_queries_total|hubble_dns_responses_total|hubble_drop_total|hubble_tcp_flags_total'
        action: keep

Valide a configuração fundida com promtool check config "<prometheus-config-file>" , se estiver disponível na sua implantação, depois recarregue o Prometheus usando o seu procedimento operacional normal. Em Alvos, verifica se os alvos para networkobservability-hubble estão UP. Inspecione os erros de scraping se não o estiverem. O exemplo assume que o endpoint do Hubble está exposto na porta 9965; verifique o endpoint da sua implementação se for diferente.

Liga a Grafana a esta fonte de dados Prometheus. Prossiga com a seleção de métricas no Passo 3 e depois abra os painéis no Passo 4.

Passo 3: Escolha quais métricas do Hubble ingerir

Para limitar dados de alta cardinalidade e custos de ingestão, o perfil mínimo de ingestão do Prometheus gerido não recolhe estas métricas por defeito:

• hubble_flows_processed_total
• hubble_flows_to_world_total
• hubble_port_distribution_total

Se precisar de quaisquer destas três métricas, adicione os seus nomes à sua configuração de coleção existente. Caso contrário, continue para o Passo 4.

As métricas devem estar disponíveis no endpoint do agente antes de poderem ser ingeridas. Para ativar as métricas opcionais de mundo ou de porta de destino no Cilium, veja Configurar filtragem de métricas de rede de contentores.

Siga as instruções na secção seguinte para o seu backend Prometheus.

Permitir as famílias de métricas no Prometheus gerido

Use as suas seleções para atualizar a networkobservabilityHubble lista de permissões no ama-metrics-settings-configmap ConfigMap em kube-system. Esta alteração permite ao coletor incluir estas métricas a partir do endpoint das métricas Prometheus do agente.

1. Se o ConfigMap não existir, cria-o usando o template suportado no Personalizar Prometheus scraping. Se já existir, faça uma cópia de segurança antes de fazer alterações:

   kubectl get configmap ama-metrics-settings-configmap -n kube-system \
     -o yaml > ama-metrics-settings-before.yaml
   

   Resolva qualquer erro antes de continuar.

2. Abra o ConfigMap para editar. No esquema v2, encontre networkobservabilityHubble na default-targets-metrics-keep-list secção sob data.cluster-metrics. Preserve o esquema existente do seu ConfigMap e outras definições.

   kubectl edit configmap ama-metrics-settings-configmap -n kube-system
   

3. Mantenha a ingestão mínima de dados ativada. Adicione cada nome adicional de métrica ao valor existentenetworkobservabilityHubble, separado por |. Por exemplo, se o valor atual for:

   networkobservabilityHubble = "hubble_dns_queries_total|hubble_drop_total"
   

   Para também ingerir métricas de fluxo, altere para:

   networkobservabilityHubble = "hubble_dns_queries_total|hubble_drop_total|hubble_flows_processed_total"
   

   Utilize o seu próprio valor existente como ponto de partida, não o valor de exemplo. Esta definição não é um ConfigMap completo. Recolher mais métricas pode aumentar o volume de ingestão e o custo.

4. Salve e feche o editor. Permitir que o coletor recarregue as definições e depois consultar cada métrica adicionada no Prometheus. Para o exemplo anterior, consulte hubble_flows_processed_total e verifique amostras recentes enquanto o tráfego relevante está a circular. Consulte também uma métrica existente, por exemplo, hubble_dns_queries_total se já a recolhe, para confirmar que ainda recebe novas amostras. Verifique os painéis e alertas que utilizam estas métricas antes de continuar para o Passo 4.

Permitir as famílias métricas no teu próprio Prometheus

Adicione nomes adicionais de métricas à expressão keep do metric_relabel_configs trabalho existente, separados por |. Mantém todos os nomes e padrões existentes. Por exemplo, se a expressão atual for hubble_dns_queries_total|hubble_drop_total, adicionem métricas de fluxo da seguinte forma:

metric_relabel_configs:
  - source_labels: [__name__]
    regex: 'hubble_dns_queries_total|hubble_drop_total|hubble_flows_processed_total'
    action: keep

Use a sua própria expressão como ponto de partida. Atualize a regra de keep existente em vez de adicionar uma segunda; uma segunda regra de keep pode descartar métricas mantidas pela primeira. Valide e recarregue a configuração. Consulte cada métrica adicionada, como hubble_flows_processed_total, e consulte uma métrica existente no Prometheus. Confirme que ambos recebem amostras recentes enquanto o tráfego relevante está a fluir e depois abra os painéis de rede no Passo 4.

Passo 4: Visualize os painéis de rede da ACNS

portal do Azure

Depois de ativar a recolha do Azure Monitor, abra um painel de controlo de rede:

1. Abra o seu cluster AKS no portal Azure.
2. Em Monitorização, selecione Dashboards com Grafana.
3. Escolha um painel de controlo da lista e depois selecione o namespace ou carga de trabalho e um intervalo de tempo com a atividade da rede.

Para mais detalhes, consulte Usar dashboards com Grafana com AKS.

Painéis de controlo de rede disponíveis

Utilize os seguintes seis painéis Kubernetes / Redes para explorar a atividade de rede do seu cluster. Os IDs de importação são fornecidos apenas para clientes que usam o seu próprio Grafana; não são necessários para os painéis incorporados do portal Azure.

Comece com Clusters para a saúde da rede ao nível dos nós, depois abra um painel de workload ou namespace para investigar tráfego, quedas ou comportamentos DNS. Considere um atraso na recolha após ativar a monitorização ou alterar a lista de conservação.

Os painéis DNS requerem visibilidade DNS. Os painéis Pod Flows requerem hubble_flows_processed_total na lista de manutenção configurada no Passo 3. Um painel vazio pode significar que não há tráfego correspondente, ausência de recolha ou um intervalo de tempo ou seleção incorreta. Isso não significa necessariamente que haja um problema de rede.

Opcional: Utilizar uma implantação separada do Grafana

Se já usas o Azure Managed Grafana, podes ligá-lo ao espaço de trabalho do Azure Monitor e usar os dashboards Kubernetes / Networking / ... sob Dashboards > Azure Managed Prometheus. Azure Managed Grafana é um serviço pago separado, não um pré-requisito para os dashboards do portal.

Para o seu próprio Grafana, importe os dashboards usando os IDs na tabela anterior e selecione a sua fonte de dados Prometheus.

Resolução de problemas de métricas em falta

Limpar recursos

Restaure apenas as alterações da sua investigação às listas de permissões CNM e Prometheus. Preserva as definições usadas por outras equipas e quaisquer alterações feitas desde o teu backup. Remover uma entrada CNM desativa uma métrica opcional apenas se essa entrada a ativou; métricas fornecidas pelo serviço permanecem ativadas. Remover filtros pode alargar a seleção. As amostras históricas continuam sujeitas a retenção no backend.

Elimine um grupo de recursos apenas se o criou exclusivamente para este exercício e ninguém precisar de nenhum recurso nele. O comando seguinte elimina o cluster e todos os outros recursos desse grupo:

az group delete --name "$RESOURCE_GROUP"

Próximos passos

• Escolha métricas e compreenda os seus limites.
• Filtrar métricas e ativar métricas adicionais no Cilium.
• Configurar registos de rede armazenados ou sob demanda.
• Explore os Serviços Avançados de Redes de Containers.