Diagnosticar e resolver problemas de rede do AKS com os Serviços Avançados de Rede de Contêiner

Este guia orienta você a diagnosticar e resolver problemas de rede do mundo real em AKS (Serviço de Kubernetes do Azure) usando Advanced Container Networking Services (ACNS). Cada manual começa com um sintoma (falhas de DNS, quedas de pacotes, desequilíbrio de tráfego, erros L7), mostra qual indicador verificar primeiro e informa quando se aprofundar nos logs.

O guia é organizado em torno de tarefas, não de recursos. Leia o modelo mental uma vez e, em seguida, vá direto para o manual que corresponde ao seu sintoma.

O que este guia ajuda você a resolver

• Falhas na resolução de DNS em pods (NXDOMAIN, SERVFAIL, respostas ausentes).
• Quedas de pacotes causadas por políticas de rede configuradas incorretamente, controle de conexão ou degradação de conectividade.
• Desequilíbrio de tráfego entre pods ou namespaces (pods com alta demanda, distribuição de carga desigual).
• Erros de aplicativo L7 (HTTP 4xx/5xx, falhas de gRPC, quedas do Kafka).
• Monitoramento de integridade de rede em todo o cluster e planejamento de capacidade.
• Controle de custo de observabilidade por meio da coleta direcionada de métricas e logs.

Modelo mental: como as métricas, os logs e a filtragem se encaixam

O ACNS fornece três sinais. Cada um responde a uma pergunta diferente.

Para obter uma referência mais detalhada dos recursos, consulte Métricas de rede de contêineres, Logs de rede de contêineres e Configurar filtragem de métricas.

Fluxo de solução de problemas padrão

Use este loop para qualquer incidente de rede:

1. Inicie em painéis de métricas. Confirme a anomalia: um aumento repentino em quedas, erros, redefinições de TCP ou falhas de DNS. Identifique o nó, namespace ou carga de trabalho afetada.
2. Consulte os logs armazenados. Filtre a ContainerNetworkLogs tabela pelo namespace e pela janela de tempo da etapa 1. Os logs informam o veredito, o motivo da queda, as cargas de trabalho de origem/destino e os códigos de status da camada 7 que as métricas não contêm.
3. Reproduza ao vivo com logs sob demanda. Se o problema for intermitente ou já estiver corrigido em dados armazenados, use a CLI do Hubble ou a interface do usuário do Hubble para capturar fluxos dinâmicos para essa carga de trabalho.
4. Valide a correção. Verifique novamente o mesmo painel de métricas e execute novamente a mesma consulta KQL. A anomalia deve ter sumido.
5. Ajuste a coleta. Se você tiver coletado demais durante o incidente, restrinja o ContainerNetworkLog CRD ou aplique um ContainerNetworkMetric filtro para capturar apenas o que precisa daqui para frente.

Painéis integrados em um relance

Configure-os uma vez com Configurar a Observabilidade de Rede de Contêiner. Você os consultará ao longo dos playbooks.

Manual 1: Diagnosticar falhas de resolução de DNS

Sintoma. Os pods registram erros como DNS_PROBE_FINISHED_NXDOMAIN, SERVFAIL ou travam ao resolver nomes de serviço.

Objetivo. Identifique se a falha é upstream (CoreDNS ou resolvedor externo), controlada por política (negação FQDN) ou específica da carga de trabalho.

Etapa 1: confirmar a anomalia nas métricas DNS

Abra o painel DNS (Cluster ). Observe alterações repentinas no volume de solicitação, volume de resposta ou Porcentagem de Solicitações sem Resposta. Os painéis de resumo exibem as consultas mais comuns, os códigos de resposta mais comuns e os nós que geram mais erros.

O que procurar: um aumento contínuo nas respostas de erro, uma queda nas respostas bem-sucedidas ou um único nó dominando a contagem de erros. Observe a marca temporal da anomalia.

Etapa 2: Identificar os Pods Mais Barulhentos

Role para baixo no mesmo painel até o painel que classifica os pods por erros de DNS em todos os namespaces. As entradas principais são seus principais suspeitos.

Ponto de decisão.

• Se os erros estiverem concentrados nos pods do CoreDNS, acesse o painel do DNS (Carga de trabalho) com a opção kube-system / coredns selecionada — o problema está no próprio CoreDNS ou em seu resolvedor upstream.
• Se os erros estiverem concentrados em uma carga de trabalho de aplicativo, essa carga de trabalho estará gerando consultas incorretas ou sendo negada por uma política FQDN.

Etapa 3: Detalhar a carga de trabalho afetada

Abra o painel DNS (Carga de Trabalho) para a carga de trabalho que você identificou.

• Painéis de Solicitações DNS/Respostas DNS. Uma alta porcentagem de solicitações sem resposta indica tempos limite em upstream ou sobrecarga de consulta.

  

• Erros de DNS por tipo. Corresponda o pico a um código:

  • NXDOMAIN — nome de domínio incorreto ou obsoleto na configuração do aplicativo.
  • SERVFAIL — problema no resolvedor upstream.
  • Consulta recusada – incompatibilidade de configuração de DNS ou política FQDN.

  

• IPs de resposta de DNS retornados. Confirma a taxa de resolução bem-sucedida. Uma queda geralmente significa que o CoreDNS não consegue alcançar o upstream; um aumento repentino pode indicar uma tempestade de consultas.

• Tabela de resposta DNS. Use isso para identificar padrões como "registros A falham, mas registros AAAA são bem-sucedidos", o que geralmente aponta para uma pilha mal configurada para ambientes somente IPv4.

  

Etapa 4: Confirmar com registros armazenados

Execute essa consulta KQL em seu workspace Log Analytics para exibir padrões de erro DNS. As linhas agregadas preservam Verdict, namespaces, cargas de trabalho e Layer7.dns.rcode portanto, esta consulta funciona com a tabela ContainerNetworkLogs padrão (agregada):

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L4 = parse_json(Layer4), L7 = parse_json(Layer7)
| where L4.UDP.destination_port == 53
| where Reply == true
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name),
         DnsRcode    = tostring(L7.dns.rcode)
| where DnsRcode != "NOERROR"
| summarize ResponseCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DnsRcode, Verdict
| order by ResponseCount desc

Substitua <start-time> e <end-time> por timestamps no formato 2026-04-30T15:00:00Z.

O que fazer para verificar os resultados:

• Veredicto. DROPPED significa que um FQDN ou uma política de rede está bloqueando a consulta. FORWARDED com um NOERRORDnsRcode (por exemplo, NXDOMAIN, SERVFAIL) significa que o resolvedor upstream retornou um erro.
• Cargas de trabalho de origem/destino. Confirme se o tráfego está sendo direcionado para a tarefa de CoreDNS esperada.
• DnsRcode. O código de resposta DNS identifica o modo de falha rapidamente.

Você também pode visualizar os mesmos fluxos no portal Azure em aks cluster>Insights>Networking>Flow Logs.

Etapa 5: reproduza o problema em tempo real se ele for intermitente.

Se o pico já tiver passado e você não conseguir capturá-lo em logs armazenados, use a CLI do Hubble sob demanda:

hubble observe --namespace <ns> --port 53 --type l7 --follow

Etapa 6: Validar a correção

Depois de atualizar a política FQDN, corrigir a configuração do aplicativo ou dimensionar o CoreDNS, abra novamente o painel DNS (Carga de Trabalho ). A taxa de erros deve cair dentro de um ou dois minutos. Execute novamente a consulta KQL para o mesmo intervalo de tempo para confirmar se as consultas com falha desapareceram.

Playbook 2: investigar descartes de pacotes.

Sintoma. Os serviços não podem alcançar uns aos outros. As sondas falham. As conexões expiram. Os contadores de descarte aumentam nos painéis.

Objetivo. Identifique se as quedas são causadas pela política de rede, pelo esgotamento do controle de conexão ou por problemas de conectividade upstream e qual carga de trabalho é responsável.

Etapa 1: localize as perdas no nível do namespace

Abra Fluxos de Pod (Namespace). Os mapas de calor mostram os namespaces e pods com as maiores taxas de perda de pacotes de entrada e saída.

Células mais brilhantes indicam taxas de queda mais altas. Observe o namespace e a janela de tempo.

Etapa 2: Detalhar a carga de trabalho afetada

Abra Drops (Carga de Trabalho) e selecione a carga de trabalho que você identificou.

• Instantâneo de Carga de Trabalho mostra as perdas máximas e mínimas de pacotes de saída em pacotes/seg. Use-o para avaliar a gravidade.

  

• O Tráfego Descartado por Motivo é o painel mais importante. O motivo indica o que corrigir:

  • Política negada – um NetworkPolicy ou CiliumNetworkPolicy está bloqueando o tráfego.
  • CT: Falha na inserção do mapa — a tabela de rastreamento de conexões está cheia; dimensione o nó ou reduza a rotatividade de conexões.
  • Protocolo L3 sem suporte / pacote inválido – o aplicativo ou o proxy está enviando tráfego malformado.

  

• Mapa de calor das perdas de pacotes de entrada/saída. Identifica quais pares de pods específicos estão perdendo tráfego.

  

• Total de pacotes descartados acumulados por pod de origem. Classifica os infratores para que você saiba qual réplica verificar primeiro.

  

Etapa 3: confirme os fluxos descartados nos logs armazenados.

Localize as cargas de trabalho exatas de origem e de destino do tráfego descartado. Verdict, DropReason, namespaces e cargas de trabalho estão todos na chave de agregação, portanto, essa consulta funciona em dados agregados.

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DropReason, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, DropCount desc

Restringir a um namespace depois de identificá-lo:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| where SourceNamespace == "<namespace-name>"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DestinationNamespace, DstWorkload, DropReason, TrafficDirection
| order by DropCount desc

O painel Flow Logs no portal Azure mostra os mesmos dados visualmente, incluindo um grafo de dependência de serviço que realça caminhos bloqueados.

Etapa 4: verifique as políticas.

Depois de conhecer o pod de origem e o pod de destino:

kubectl get netpol,cnp -A
kubectl describe cnp -n <namespace> <policy-name>

Compare o fluxo com falha com as regras de entrada/saída. A causa mais comum é uma política de negação padrão adicionada sem uma regra de permissão para um caminho legítimo.

Etapa 5: Validar a correção

Após ajustar a política, o gráfico Dropped Traffic by Reason deve ficar plano para política negada. Execute novamente a consulta KQL — os veredictos DROPPED para esse par de origem/destino devem parar de aparecer.

Playbook 3: encontre desequilíbrios de tráfego e pods sobrecarregados

Sintoma. Alguns pods de um Deployment estão saturando a CPU ou a rede, enquanto outros estão ociosos. O número de redefinições TCP aumenta. Os relatórios de latência são provenientes de usuários (a latência em si não é visível nas métricas do ACNS — consulte a observação no modelo Mental).

Objetivo. Identifique quais pods estão carregando tráfego desproporcional e se as redefinições indicam sobrecarga ou balanceamento de carga configurado incorretamente.

Etapa 1: compare o tráfego em nível de pod

Abra Fluxos de Pod (Carga de Trabalho). O Instantâneo de Carga de Trabalho resume o tráfego de entrada/saída e os pacotes descartados.

O painel de tráfego por tipo de rastreamento mostra o padrão do tráfego ao longo do tempo. Uma grande diferença entre o volume de saída e de entrada geralmente aponta para um gargalo downstream.

Etapa 2: identifique pods sobrecarregados com mapas de calor

Os mapas de calor no nível do pod tornam o desequilíbrio óbvio. Se um pod (por exemplo, default/tcp-client-0) aparecer nos mapas de calor de saída e entrada com células muito mais escuras do que suas réplicas, o tráfego está concentrado ali.

Causas comuns:

• Serviço sessionAffinity: ClientIP fixando clientes em um pod.
• Serviço headless com resolução DNS persistente.
• Hash do balanceador de carga externo em um campo de baixa cardinalidade.

Etapa 3: use resets TCP como sinal de saturação

Abra os painéis de métricas de redefinição de TCP .

• Mapa de calor de RSTs TCP de saída por pod de origem. Um pod de origem com alta demanda que também gera RSTs está sobrecarregado — o aplicativo está fechando conexões agressivamente.

  

• Mapa de calor de RSTs TCP de entrada por pod de destino. Um pod que recebe RSTs de muitas origens geralmente significa que ele não consegue aceitar novas conexões com rapidez suficiente (backlog cheio, listener lento).

  

• Total RST agrupado por Origem/Destino. As tendências ao longo do tempo indicam se as reinicializações são um incidente ou um novo estado estável.

Etapa 4: Confirmar com registros

Identificar as cargas de trabalho mais ocupadas pelo volume total de fluxo. Use as colunas de contagem de fluxo agregadas em vez de count(), que conta apenas linhas agregadas, não os fluxos subjacentes:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend SrcWorkload = tostring(SourceWorkloads[0].name)
| summarize TotalFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload
| top 10 by TotalFlows desc

Etapa 5: Validar a correção

Após dimensionar a carga de trabalho, rebalancear o serviço ou corrigir as regras de afinidade, o mapa de calor deve clarear uniformemente em mais pods e a taxa de RST TCP deve diminuir.

Guia estratégico 4: Monitorar a integridade da rede em todo o cluster

Use isso quando precisar de uma visão geral: planejamento de capacidade, painéis de plantão ou uma verificação rápida de integridade em vários clusters.

Abra Kubernetes/Rede/Clusters.

Sinais para observar e o que eles significam:

Quando algo neste painel parecer errado, acesse o playbook correspondente (Playbook 1 para DNS, Playbook 2 para descartes, Playbook 3 para pods ativos).

Plano de ação 5: Diagnosticar erros na camada de aplicativo (L7)

Sintoma. As taxas de erro HTTP 4xx/5xx sobem. As chamadas gRPC falham. Atraso dos consumidores do Kafka. Disponível em clusters Cilium com aplicação de política L7 habilitada e um CiliumNetworkPolicy que inclua regras L7 — consulte Configurar uma política de Camada 7.

Objetivo. Identifique se os erros L7 vêm de clientes configurados incorretamente, falhas no lado do servidor ou fluxos negados.

Etapa 1: Abrir o painel L7

Use Kubernetes/Networking/L7 (Carga de Trabalho) para um único serviço ou L7 (Namespace) para um inquilino inteiro.

Etapa 2: Separar o tráfego HTTP descartado versus encaminhado

O painel de veredicto divide o tráfego HTTP em fluxos encaminhados e descartados. Um pico em HTTP descartado geralmente significa que uma CiliumNetworkPolicy está negando a solicitação na camada 7 (por exemplo, bloqueando um caminho ou método).

Etapa 3: Acompanhar códigos de status ao longo do tempo

O painel de código de status informa se os erros são do lado do cliente ou do servidor. Um aumento repentino em erros 4xx indica entrada inválida, tokens expirados ou caminhos negados. Um aumento repentino em erros 5xx indica falhas no backend.

Etapa 4: encontre os pods problemáticos

O mapa de calor de erros 4xx mostra quais pods de origem estão gerando o maior número de solicitações com falha. Um único pod com destaque negativo geralmente significa um loop de repetição de cliente travado ou uma réplica mal configurada.

Etapa 5: Confirmar com o KQL

Extrair tráfego HTTP segmentado por código de status. Layer7.http.code faz parte da chave de agregação, portanto, isso se aplica às linhas agregadas:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L7 = parse_json(Layer7)
| where isnotnull(L7.http)
| extend StatusCode  = tostring(L7.http.code),
         SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where StatusCode startswith "4" or StatusCode startswith "5"
| summarize ErrorFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount),
            UniqueCodes = dcount(StatusCode)
    by SrcWorkload, DstWorkload, StatusCode
| order by ErrorFlows desc

Para gRPC e Kafka, Layer7 carrega o conteúdo específico do protocolo, mas apenas http.code e dns.rcode são chaves de agregação. Filtrar por Verdict e pela identidade da carga de trabalho e usar logs sob demanda quando precisar do método gRPC ou do tópico do Kafka:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where Verdict == "DROPPED"
| summarize DroppedFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DstWorkload
| order by DroppedFlows desc

Em que focar durante a RCA da Camada 7

• Volume e forma de tráfego. Usar mapas de calor para encontrar desequilíbrios; uma réplica ativa geralmente explica a taxa de erros.
• Tendência de código de status. 4xx vs 5xx restringe a investigação ao lado do cliente ou do servidor.
• Veredicto.Descartado Fluxos da Camada 7 significam que uma política da Camada 7 está rejeitando a solicitação — leia a política e confirme a intenção.

Análise detalhada de recursos (quando usar cada um)

Use esta seção como uma referência rápida depois de conhecer os guias estratégicos.

Métricas de rede de contêiner

• Use para: detecção de anomalias, dashboards, alertas, planejamento de capacidade.
• Ignorar para: causa principal que precisa de identificação (qual pod, qual caminho, qual veredicto).
• Granularidade: nível de nó em todos os planos de dados; nível de pod no Linux.
• Cargas de trabalho sensíveis a custos: aplique filtragem de métricas em clusters Cilium para manter apenas os namespaces, rótulos e tipos de métricas que são importantes para você. A filtragem ocorre antes da coleta, portanto, séries indesejadas nunca chegam ao Prometheus.

Logs de rede de contêineres (armazenados)

• Use para: análise de causa raiz, tendências históricas, conformidade/auditoria.

• Plano de dados:Somente Cilium. Logs armazenados não estão disponíveis em clusters não Cilium.

• Etapa obrigatória: defina um ContainerNetworkLog CRD que selecione o tráfego desejado. Sem ele, nenhum log é coletado. Consulte Configurar logs de rede de contêiner.

• Onde os logs são armazenados: por padrão, o Cilium grava registros de fluxo em /var/log/acns/hubble/events.log cada nó (buffer rotativo de 50 MB). A partir daí, você tem dois caminhos de armazenamento:

  • Azure Log Analytics (gerenciado, recomendado) — o Container Insights envia logs para a tabela ContainerNetworkLogs para consultas KQL e painéis integrados do portal Azure.
  • Traga seu próprio coletor: aponte um agente compatível com OpenTelemetry (Splunk, Datadog, Elastic, qualquer coletor OTel) para o caminho de log do host para encaminhar fluxos para sua pilha de observabilidade existente em vez de, ou além de, o Log Analytics.

• Controle de custos: a agregação de logs de fluxo consolida fluxos semelhantes em uma janela de 30 segundos, preservando padrões e reduzindo o volume. Combine com um includeFilters estreito para obter os melhores resultados.

• Visualização: use os painéis Logs de Fluxo — Nível de Análise ou Logs de Fluxo — Nível Básico em Azure>Insights>Contêineres>Rede.

  

  

Logs de rede de contêiner (sob demanda)

• Use para: incidentes dinâmicos, problemas intermitentes, investigação ad hoc sem alterar a configuração da coleção.

• Plano de dados:Somente Cilium.

• Ferramentas: CLI do Hubble para filtragem de terminal; Interface do usuário do Hubble para mapas de serviço a serviço visual.

• Sem armazenamento persistente, sem custo adicional, sem configuração além de habilitar o ACNS.

  

Filtragem de métricas (clusters Cilium)

Aplique um ContainerNetworkMetric CRD para controlar quais métricas do Hubble são exportadas por nó. Útil quando você precisa de uma ampla observabilidade em alguns namespaces críticos, mas não deseja pagar por séries de fluxo de alta cardinalidade em todos eles.

Padrões comuns:

• Mantenha o DNS e exclua as métricas em todo o cluster; restrinja métricas de fluxo de dados a namespaces de produção.
• Exclua namespaces de sistema de alto volume, como kube-system, das métricas de fluxo.
• Delimite os namespaces por locatário para seus próprios blocos de filtro.

Para obter exemplos de CRD completos, consulte Configurar a filtragem de métricas de rede de contêiner.

Práticas recomendadas

• Comece largo e, em seguida, estreito. Habilite logs/métricas gerais por alguns dias, revise o que você realmente usa e, em seguida, restrinja os filtros ContainerNetworkLog e ContainerNetworkMetric.
• Mantenha as janelas de tempo de métricas e logs alinhadas. Ao investigar um incidente, use o mesmo tempo de início/fim no painel e na consulta KQL para que os sinais se correlacionem de forma limpa.
• Prefira os painéis pré-criados. Elas abordam as perguntas mais comuns. Os painéis personalizados geralmente só são necessários quando você já passou da triagem inicial.
• Camada ContainerNetworkLogs por necessidade. Alterne para a camada Básica para cargas de trabalho sensíveis a custos; use o painel de camada básica correspondente. Consulte planos de tabela do Log Analytics.
• Considere os logs agregados e os logs sob demanda como complementares. Os logs agregados são ótimos para detecção de tendências e padrões, mas omitem detalhes em cada fluxo. Use o Hubble sob demanda para inspeção detalhada.
• Valide as correções com o mesmo painel que gerou o problema. Se o mesmo painel ficar inativo após a alteração, você encontrou uma solução real.

Armadilhas comuns

• Esquecendo o ContainerNetworkLog CRD. Habilitar os Logs de Rede do Contêiner no cluster não coleta nada até que você aplique pelo menos um CRD que selecione tráfego.
• Tentando usar logs armazenados para incidentes em andamento que já ocorreram. Se os logs não estavam habilitados antes do incidente ou estavam fora do filtro de captura, mude para fluxos do Hubble sob demanda para a próxima ocorrência.
• Painéis L7 vazios em um cluster Cilium. As métricas L7 requerem tanto --acns-advanced-networkpolicies L7 no cluster quanto uma CiliumNetworkPolicy com regras L7. O CCNP não dá suporte a regras L7. Consulte Aplicação de políticas L7.
• As métricas DNS estão vazias no Cilium. A visibilidade de DNS requer um CiliumNetworkPolicy com uma regra dns (normalmente junto com toFQDNs). O proxy FQDN/DNS não é compatível com o DNS local do nó ou o DNS local do AKS — executar qualquer um deles desativa o proxy DNS e as métricas resultantes. Consulte as limitações de filtragem do FQDN.
• matchPattern: "*" bloqueia todos os DNS. Um curinga simples não é compatível. Use um padrão de curinga inicial, como *.example.com ou app*.example.com. Consulte Aplicar políticas de filtragem do FQDN.

Observabilidade de rede incluída no Monitoramento do Azure

Quando você habilita o serviço gerenciado do Azure Monitor para Prometheus em um cluster do AKS, as métricas básicas de monitoramento de rede de nós são coletadas por padrão por meio do networkobservabilityRetina de destino. Ele fornece:

• Métricas básicas de rede no nível do nó: visibilidade do tráfego de rede essencial no nível do nó
• Destinos padrão do Prometheus: Métricas de observabilidade de rede coletadas automaticamente pelo Azure Monitor
• Integração do Azure Monitor: integração perfeita com o Azure Monitor; as métricas são coletadas automaticamente e podem ser visualizadas no Grafana
• Nenhuma configuração adicional é necessária: habilitada automaticamente quando o Prometheus gerenciado do Azure Monitor está configurado
• Suporte da Microsoft: com suporte como parte do Azure Monitor e do AKS

Observação: ele requer que o serviço gerenciado do Azure Monitor para o Prometheus seja habilitado no cluster do AKS e isso pode ter custos associados.

Introdução: habilite o serviço gerenciado do Azure Monitor para Prometheus no cluster do AKS por meio do portal ou da CLI do Azure. As métricas de observabilidade de rede serão coletadas automaticamente e ficarão disponíveis para visualização no Grafana Gerenciado do Azure.

Observabilidade de rede com o Retina OSS

Embora o ACNS (serviços avançados de rede de contêineres) seja uma oferta paga que fornece recursos abrangentes de observabilidade de rede, a Microsoft também dá suporte à observabilidade de rede com o Retina OSS, uma plataforma de observabilidade de rede de software livre que fornece recursos essenciais de monitoramento de rede.

O RETINA OSS é a plataforma de observabilidade de software livre disponível no retina.sh e no GitHub. Ela oferece:

• Observabilidade de rede baseada em eBPF: usa tecnologias eBPF para coletar insights com sobrecarga mínima
• Análise de tráfego profundo com o contexto do Kubernetes: captura e análise abrangentes de fluxos de tráfego de rede com integração completa do Kubernetes
• Coleção de métricas avançadas: métricas de camada 4, métricas DNS e recursos de captura de pacote distribuído
• Extensibilidade baseada em plug-in: personalização e extensão de funcionalidade por meio de uma arquitetura de plug-in
• Métricas compatíveis com Prometheus: exportação de métricas de rede abrangentes no formato Prometheus com modos de métrica configuráveis
• Captura de pacote distribuído: capturas de pacote sob demanda em vários nós para solução de problemas profunda
• Plataforma e CNI independente: funciona com qualquer cluster do Kubernetes (AKS, habilitado para Arc, local), qualquer sistema operacional (Linux/Windows) e qualquer CNI
• Suporte da comunidade: software livre com suporte e contribuições orientados pela comunidade
• Autogerenciamento: controle total sobre implantação e configuração
• Integração com o Hubble: integra-se ao Hubble da Cilium para obter insights adicionais de rede

Introdução: implantar o Retina OSS usando gráficos do Helm ou manifestos do Kubernetes do repositório oficial do Retina. Configure o Prometheus e o Grafana para visualizar as métricas, configurar a análise de tráfego profundo com o contexto do Kubernetes, habilitar a captura de pacotes distribuídos para solução de problemas avançada e personalizar a funcionalidade usando a arquitetura baseada em plug-in para casos de uso específicos.

Comparação de ofertas de observabilidade de rede

Saiba mais

Serviços avançados de rede de contêineres (ACNS)

• Visão geral da plataforma:o que são os Serviços Avançados de Rede de Contêiner para AKS?
• Configurar a observabilidade:Configurar a observabilidade da rede de contêiner
• Métricas de rede de contêiner:Visão geral das métricas de rede do contêiner
• Logs de rede de contêiner:Visão geral dos logs de rede de contêiner e Configuração de logs de rede de contêiner
• Filtragem de métricas (Cilium):Configurar a filtragem de métricas de rede de contêiner

Diagnóstico controlado por IA

• Agente do Container Network Insights (versão prévia):Visão geral e configurar o agente
• Servidor AKS MCP:servidor do protocolo de contexto do modelo AKS

Segurança de Rede de Contêiner (Cilium)

• Filtragem de FQDN:Conceitos e aplicar políticas de filtragem FQDN
• Política de camada 7:Conceitos e aplicar políticas L7
• TLS mútuo (Cilium):Conceitos e Configurar TLS mútuo
• Criptografia em trânsito:conceitos de criptografia do WireGuard

Plano de dados e plataforma

• Azure CNI alimentado por Cilium:Configure Azure CNI alimentado pelo Cilium
• Desempenho de roteamento de host eBPF:Desempenho de rede de contêiner com roteamento de host eBPF
• Planos de tabela do Log Analytics:Escolha um plano de tabela com base no uso dos dados

Ferramentas de software livre

• Retina:retina.sh e o repositório Microsoft Retina GitHub
• Hubble (projeto Cilium):documentação do Hubble