Diagnosticar e resolver problemas de rede AKS com Serviços Avançados de Rede de Contentores

Este guia guia-o no diagnóstico e resolução de problemas reais de redes em Azure Kubernetes Service (AKS) utilizando Advanced Container Networking Services (ACNS). Cada playbook começa com um sintoma (falhas de DNS, falhas de pacotes, desequilíbrio de tráfego, erros L7), mostra-te qual sinal verificar primeiro e indica-te quando deves aprofundar os logs.

O guia está organizado em função das tarefas, não das funcionalidades. Lê o modelo mental uma vez e depois salta diretamente para o manual que corresponde ao teu sintoma.

O que este guia te ajuda a resolver

• Falhas de resolução DNS nos pods (NXDOMAIN, SERVFAIL, respostas ausentes).
• Quedas de pacotes causadas por políticas de rede mal configuradas, rastreio de ligação ou degradação da conectividade.
• Desequilíbrio de tráfego entre pods ou namespaces (pods quentes, distribuição de carga desigual).
• Erros de aplicação L7 (HTTP 4xx/5xx, falhas em gRPC, quedas de Kafka).
• Monitorização da saúde da rede em todo o cluster e planeamento de capacidade.
• Controlo de custos de observabilidade através da recolha direcionada de métricas e registos.

Modelo mental: como métricas, registos e filtragem se encaixam

O ACNS dá-te três sinais. Cada um responde a uma pergunta diferente.

Para uma referência de funcionalidades mais detalhada, veja Métricas de rede de contentores, Registos de rede de containers e Configurar filtragem de métricas.

Fluxo padrão de resolução de problemas

Use este ciclo para qualquer incidente de rede:

1. Começa por dashboards de métricas. Confirme a anomalia: um pico de quedas, erros, redefinições TCP ou falhas de DNS. Identifique o nó afetado, o namespace ou a carga de trabalho.
2. Mudar para registos armazenados. Filtre a tabela ContainerNetworkLogs pelo espaço de nomes e pela janela temporal do passo 1. Os registos indicam o veredito, razão do abandono, cargas de trabalho de origem/destino e códigos de estado L7 que as métricas não suportam.
3. Reproduza ao vivo com registos a pedido. Se o problema for intermitente ou já estiver resolvido nos dados armazenados, use a CLI do Hubble ou a interface do Hubble para captar fluxos em tempo real para essa carga de trabalho.
4. Valida a correção. Verifica novamente o mesmo painel de métricas e volta a executar a mesma consulta KQL. A anomalia deve ter desaparecido.
5. Coleção de melodias. Se tiver recolhido em excesso durante o incidente, estreite o CRD ContainerNetworkLog ou aplique um ContainerNetworkMetric filtro para captar apenas o que precisa daqui em diante.

Painéis de controlo integrados num instante

Configura a funcionalidade uma única vez com Configurar a Observabilidade da Rede de Contentores. Vais referi-los ao longo dos livros de jogadas.

Playbook 1: Diagnosticar falhas na resolução de DNS

Sintoma. Os pods registam erros como DNS_PROBE_FINISHED_NXDOMAIN, SERVFAIL, ou ficam pendurados ao resolver nomes de serviço.

Golo. Identifique se a falha é do lado do fornecedor (CoreDNS ou resolvedor externo), orientada por políticas (bloqueio FQDN) ou relacionada com uma carga de trabalho específica.

Passo 1: Confirmar a anomalia nas métricas DNS

Abra o painel DNS (Cluster). Verifique por alterações súbitas no volume de pedidos, volume de respostas ou % de Pedidos Sem Resposta. Os painéis de resumo apresentam as consultas mais comuns, os códigos de resposta mais comuns e os nós que geram mais erros.

O que procurar: Um aumento sustentado nas respostas de erro, uma queda nas respostas bem-sucedidas ou um único nó que domina a contagem de erros. Note a marca temporal da anomalia.

Passo 2: Identificar os pods mais barulhentos

Role para baixo no mesmo dashboard até ao painel que classifica os pods por erros de DNS em todos os namespaces. As primeiras entradas são os teus suspeitos iniciais.

Ponto de decisão.

• Se os erros estiverem concentrados nos pods CoreDNS, salte para o painel DNS (Workload) selecionando kube-system / coredns — o problema é o próprio CoreDNS ou o seu resolvedor upstream.
• Se os erros estiverem concentrados numa carga de trabalho de aplicação, essa carga está a gerar consultas erradas ou a ser negada por uma política FQDN.

Passo 3: Aprofunde a carga de trabalho afetada

Abra o painel DNS (Workload) para a carga de trabalho que identificou.

• Painéis de Pedidos DNS / Respostas DNS. Uma percentagem elevada de pedidos de resposta em falta aponta para timeouts na origem ou sobrecarga de consultas.

  

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

  • NXDOMAIN — nome de domínio errado ou obsoleto na configuração da app.
  • SERVFAIL — problema de resolução a montante.
  • Consulta recusada — Incompatibilidade de política FQDN ou configuração DNS.

  

• IPs de resposta DNS devolvidos. Confirma a taxa de resolução bem-sucedida. Uma queda geralmente significa que o CoreDNS não consegue chegar a montante; Um pico repentino pode indicar uma tempestade de consultas.

• Tabela de Respostas DNS. Use isto para identificar padrões como "Registos A falham mas registos AAAA têm sucesso", que normalmente apontam para uma pilha mal configurada para ambientes apenas IPv4.

  

Passo 4: Confirmar com registos armazenados

Execute esta consulta KQL no seu espaço de trabalho Log Analytics para mostrar padrões de erro DNS. As linhas agregadas preservam Verdict, namespaces, cargas de trabalho, e Layer7.dns.rcode, pelo que esta consulta funciona contra a tabela padrão (agregada ContainerNetworkLogs ):

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 carimbos de data e hora no formato 2026-04-30T15:00:00Z.

O que verificar nos resultados:

• Veredicto. DROPPED significa que uma FQDN ou política de rede está a bloquear a consulta. FORWARDED com um não-NOERRORDnsRcode (por exemplo, NXDOMAIN, SERVFAIL) significa que o resolvedor a montante retornou um erro.
• Cargas de trabalho de origem/destino. Confirme que o tráfego está sendo direcionado para a carga de trabalho prevista do CoreDNS.
• DnsRcode. O código de resposta DNS identifica o modo de falha num instante.

Também pode visualizar os mesmos fluxos no portal Azure sob AKS cluster>Insights>Networking>Logs de Fluxo.

Passo 5: Replicar em tempo real se o problema ocorrer de forma intermitente

Se o pico já passou e não conseguir capturá-lo nos registos armazenados, use o CLI do Hubble a pedido:

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

Passo 6: Validar a correção

Após atualizar a política FQDN, corrigir a configuração da aplicação ou escalar o CoreDNS, reabra o painel DNS (Workload ). A taxa de erro deverá diminuir em um ou dois minutos. Reexecute a consulta KQL na mesma janela de tempo para confirmar que as consultas falhadas desapareceram.

Playbook 2: Investigar as quedas de pacotes

Sintoma. Os serviços não conseguem contactar-se entre si. As sondas falham. As ligações desligam-se. Os contadores de perda sobem nos painéis de instrumentos.

Golo. Identifique se as quedas são causadas por políticas de rede, esgotamento do rastreio de ligação ou problemas de conectividade a montante — e qual a carga de trabalho responsável.

Passo 1: Localizar os drops ao nível do namespace

Abrir Fluxos de Pod (Namespace). Os mapas de calor destacam os espaços de nomes e pods com as maiores taxas de falha de entrada e saída.

Células mais brilhantes indicam taxas de queda mais elevadas. Note o espaço de nomes e a janela temporal.

Passo 2: Explorar a carga de trabalho afetada

Abre Drops (Workload) e seleciona a carga de trabalho que identificaste.

• Workload Snapshot mostra máximos/mínimos de quedas de saída em pacotes por segundo. Pode usá-lo para avaliar a gravidade.

  

• Tráfego Descartado por Razão é o painel mais importante. A razão diz-lhe o que deve corrigir:

  • Política recusada — um NetworkPolicy ou CiliumNetworkPolicy está a bloquear o tráfego.
  • CT: Falha na inserção do mapa — A tabela de rastreio de ligações está cheia; escale o nó ou reduza a rotatividade de ligações.
  • Protocolo L3 não suportado / Pacote inválido — a aplicação ou proxy está a enviar tráfego malformado.

  

• Mapa de calor dos drops que chegam/saem. Identifica quais os pares específicos de pods que estão a perder tráfego.

  

• Drops totais empilhados por Pod de Origem. Ordena os infratores para saberes qual réplica ver primeiro.

  

Passo 3: Confirmar os fluxos perdidos nos registos armazenados

Encontre a carga de trabalho exata de origem e destino do tráfego perdido. Verdict, DropReason, namespaces e cargas de trabalho estão todos na chave de agregação, por isso esta consulta funciona sobre 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

Restringa a um só namespace depois de o identificar:

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 Log de Fluxo no portal Azure mostra visualmente os mesmos dados, incluindo um gráfico de dependência de serviço que destaca caminhos bloqueados.

Passo 4: Verificar com as políticas

Assim que souber o pod de origem e o pod de destino:

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

Compara o fluxo falhado com as regras de entrada/saída. A causa mais comum é uma política de recusa por incumprimento adicionada sem uma regra de permissão para um caminho legítimo.

Passo 5: Validar a correção

Após ajustar a política, o Dropped Traffic by Reason gráfico deverá permanecer estável para política negada. Executar novamente a consulta KQL — DROPPED os resultados para esse par fonte/destino deixarão de aparecer.

Playbook 3: Encontrar desequilíbrios de tráfego e pods quentes

Sintoma. Alguns pods de uma implementação saturam a CPU ou a rede, enquanto outros ficam inativos. O TCP reinicia a subida. Os relatórios de latência vêm dos utilizadores (a latência em si não é visível nas métricas ACNS — veja a nota no Modelo Mental).

Golo. Identifique quais os pods que transportam tráfego desproporcionado e se os resets indicam sobrecarga ou equilíbrio de carga mal configurado.

Passo 1: Comparar o tráfego ao nível dos pods

Abra Fluxos do Pod (Carga de Trabalho). O Workload Snapshot resume o tráfego de saída e de entrada e as quedas.

O painel de tráfego por tipo de traço mostra a forma do tráfego ao longo do tempo. Uma grande diferença entre o volume de saída e de entrada frequentemente aponta para um gargalo a jusante.

Passo 2: Identificar "hot pods" com recurso a mapas de calor

Os mapas de calor ao nível do pod tornam evidente o desequilíbrio. Se um pod (por exemplo, default/tcp-client-0) aparecer tanto nos heatmaps de saída como de entrada, com células significativamente mais escuras que as réplicas, o tráfego está concentrado ali.

Causas comuns:

• Serviço sessionAffinity: ClientIP que fixa clientes a um único pod.
• Serviço headless com resolução DNS persistente.
• Hashing de balanceador de carga externo num campo de baixa cardinalidade.

Passo 3: Usar os resets TCP como sinal de saturação

Abra os painéis de métricas de reset TCP .

• Mapa térmico do RST TCP de saída pelo Pod de origem. Um pod de fonte quente que também gera RSTs está sobrecarregado — a aplicação está a fechar as ligações de forma agressiva.

  

• Mapa de calor do RST TCP recebido por pod de destino. Um pod a receber RSTs de várias fontes normalmente significa que não consegue aceitar novas ligações suficientemente rápido (fila de espera cheia, escutador lento).

  

• Total de RST empilhado por Origem/Destino. As tendências ao longo do tempo dizem-lhe se os resets são um incidente ou um novo estado estacionário.

Passo 4: Confirmar com registos de logs

Identifique as cargas de trabalho mais ocupadas pelo volume total de fluxo. Use as colunas de contagem de fluxo agregadas em vez de count(), que apenas conta 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

Passo 5: Validar a correção

Depois de escalar a carga de trabalho, reequilibrar o serviço ou corrigir regras de afinidade, o heatmap deverá iluminar-se uniformemente em mais pods e a taxa de RST do TCP deverá diminuir.

Playbook 4: Monitorizar a saúde da rede em todo o cluster

Use isto quando precisar de uma vista de frota: planeamento de capacidade, painéis de controlo ou uma rápida verificação do estado em vários clusters.

Abra Kubernetes / Redes / Clusters.

Sinais a observar e o que significam:

Quando algo neste painel parecer errado, consulta o playbook correspondente (o Playbook 1 para o DNS, o Playbook 2 para drops, o Playbook 3 para hot pods).

Playbook 5: Diagnosticar erros na camada de aplicação (L7)

Sintoma. As taxas de erro HTTP 4xx/5xx sobem. As chamadas gRPC falham. Os consumidores de Kafka estão em atraso. Disponível em clusters Cilium com aplicação de políticas L7 ativada e CiliumNetworkPolicy que inclui regras L7 — ver Configurar uma política de Camada 7.

Golo. Identifique se os erros L7 provêm de clientes mal configurados, falhas do lado do servidor ou fluxos negados.

Passo 1: Abra o painel do L7

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

Passo 2: Separar o tráfego HTTP perdido do encaminhado

O painel de vereditos divide o tráfego HTTP em fluxos encaminhados e descontinuados. Um pico em HTTP eliminado normalmente significa que uma CiliumNetworkPolicy está a recusar o pedido na camada 7 (L7) (por exemplo, bloqueando um caminho ou método).

Passo 3: Acompanhar os códigos de estado ao longo do tempo

O painel de códigos de estado indica-lhe se os erros são do lado do cliente ou do servidor. Um aumento de 4xx indica entradas incorretas, tokens expirados, ou percursos negados. Um aumento de 5xx pontos em falhas de backend.

Passo 4: Encontrar os pods problemáticos

O mapa de calor 4xx mostra quais os pods de origem que estão a gerar mais requisições falhadas. Um único pod que brilha intensamente geralmente significa um ciclo de tentativas do cliente preso ou uma réplica configurada incorretamente.

Passo 5: Confirme com a KQL

Retira o tráfego HTTP dividido por código de estado. Layer7.http.code faz parte da chave de agregação, por isso isto funciona contra 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 transporta a carga útil específica do protocolo mas apenas http.code e dns.rcode são chaves de agregação. Filtre em Verdict e na identidade de carga de trabalho e utilize logs sob demanda quando precisar do método gRPC ou do tópico 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 deve focar-se durante o RCA de nível 7

• Volume e perfil do tráfego. Use mapas de calor para encontrar desequilíbrios; Uma réplica em fase de aquecimento explica frequentemente a taxa de erro.
• Tendência do código de estado. 4xx vs 5xx limita a investigação ao lado do cliente ou servidor.
• Veredito.Largado Fluxos L7 significam que uma apólice L7 está a rejeitar o pedido — leia a apólice e confirme a intenção.

Exploração aprofundada de funcionalidades (quando usar cada uma)

Use esta secção como referência rápida quando tiver familiaridade com os manuais.

Métricas de rede de contêiner

• Uso para: deteção de anomalias, dashboards, alertas, planeamento de capacidade.
• Saltar para: causa raiz que precisa de identificação (qual pod, caminho, veredito).
• Granularidade: nível de nó em todos os planos de dados; Nível pod no Linux.
• Cargas de trabalho sensíveis a custos: aplique filtragem de métricas nos clusters Cilium para manter apenas os namespaces, rótulos e tipos de métricas que lhe interessam. A filtragem acontece antes do scrape, por isso séries indesejadas nunca chegam a Prometheus.

Registos da rede de contentores (armazenados)

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

• Plano de dados:Apenas Cilium. Os logs armazenados não estão disponíveis em clusters que não sejam Cilium.

• Passo obrigatório: defina um ContainerNetworkLog CRD que selecione o tráfego que pretende. Sem ele, não são recolhidos registos. Veja Configurar registos de rede para contentores.

• Onde os logs aterram: por defeito, o Cilium escreve registos de fluxo nos /var/log/acns/hubble/events.log nós (buffer rotativo de 50 MB). A partir daí, tens dois caminhos de armazenamento:

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

• Controlo de custos: a agregação de logs de fluxo, numa janela de 30 segundos, colapsa fluxos semelhantes, preservando padrões enquanto corta o volume. Combine com o estreito includeFilters para melhores resultados.

• Visualização: use os painéis Flow Logs - Analytics Tier ou Flow Logs - Basic Tier em Azure>Insights>Containers>Networking.

  

  

Registos de rede de contentores (sob demanda)

• Use para: incidentes em direto, 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 terminais; Interface do Hubble para mapas visuais de serviço para serviço.

• Sem armazenamento persistente, sem custos extra, sem configuração além de ativar o ACNS.

  

Filtragem de métricas (clusters de Cilium)

Aplique um CRD ContainerNetworkMetric para controlar a exportação das métricas do Hubble por cada nó. Útil quando se precisa de observabilidade ampla em alguns namespaces críticos mas não se quer pagar por séries de fluxo de alta cardinalidade em todos eles.

Padrões comuns:

• Mantém o DNS e descarta métricas em todo o cluster; Restringe métricas de fluxo a namespaces de produção.
• Exclua os namespaces de sistemas de alto volume, como kube-system dos indicadores de fluxo.
• Definir os namespaces por inquilino para os seus próprios blocos de filtro.

Para exemplos completos de CRD, veja Configurar filtragem de métricas de rede de contentores.

Melhores práticas

• Comece por uma abordagem ampla, depois vá estreitando. Ativa registos/métricas amplos durante alguns dias, revê o que realmente usas e depois ajusta os ContainerNetworkLog e ContainerNetworkMetric filtros.
• Mantenham as janelas de tempo métrico e de registo alinhadas. Quando investigar um incidente, use a mesma hora de início/fim no painel e na consulta KQL para garantir que os sinais se correlacionem de maneira limpa.
• Prefiro os painéis de instrumentos pré-montados. Abordam as perguntas mais comuns. Painéis personalizados normalmente só são necessários depois de passares a triagem inicial.
• Classificar ContainerNetworkLogs conforme necessário. Mudar para o nível Básico para cargas de trabalho sensíveis a custos; Utilize o painel de instrumentos de nível Básico correspondente. Veja planos de tabelas no Log Analytics.
• Trate os registos agregados e os registos sob demanda como complementos. Os registos agregados são ótimos para deteção de tendências e padrões, mas ignoram detalhes por fluxo. Use o sistema a pedido (Hubble) para inspeção detalhada.
• Valida as correções com o mesmo painel que revelou o problema. Se o mesmo painel ficar plano após a sua troca, tem uma solução real.

Dificuldades comuns

• Ignorar o ContainerNetworkLog CRD. Ativar os Logs de Rede de Contentores no cluster não recolherá nada até aplicar pelo menos um CRD que selecione o tráfego.
• Estou a tentar usar registos armazenados para incidentes em tempo real que já passaram. Se os registos não estivessem ativados antes do incidente ou tivessem saído do filtro capturado, mudar para fluxos Hubble sob demanda para a próxima ocorrência.
• Dashboards L7 estão vazios num cluster Cilium. As métricas L7 exigem a presença de --acns-advanced-networkpolicies L7 no cluster e de um CiliumNetworkPolicy com regras L7. O CCNP não suporta regras de nível 7. Consulte Aplicar políticas L7.
• Métricas DNS vazias no Cilium. A visibilidade DNS requer um CiliumNetworkPolicy com uma regra dns (tipicamente ao lado de toFQDNs). O proxy FQDN/DNS não é compatível com o DNS local do nó nem com o DNS local do AKS — a execução de qualquer um desativa o proxy DNS e as métricas resultantes. Veja limitações de filtragem FQDN.
• matchPattern: "*" bloqueia todos os pedidos DNS. Um wildcard simples não é suportado. Use um padrão de wildcard inicial, como *.example.com ou app*.example.com. Consulte Aplicar políticas de filtragem 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 AKS, as métricas básicas de monitoramento de rede do nó são coletadas por padrão por meio do networkobservabilityRetina destino. Isto prevê:

• Métricas básicas de rede no nível do nó: visibilidade essencial do tráfego de rede no nível do nó
• Destinos predefinidos do Prometheus: métricas de observabilidade de rede automaticamente capturadas 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 Azure Monitor gerenciado Prometheus é configurado
• Suporte da Microsoft: Suportado como parte do Azure Monitor e do AKS

Observação: isso requer que o serviço gerenciado do Azure Monitor para Prometheus esteja habilitado em seu cluster AKS, o que pode ter custos associados.

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

Observabilidade de rede com Retina OSS

Enquanto o Advanced Container Networking Services (ACNS) é uma oferta paga que fornece recursos abrangentes de observabilidade de rede, a Microsoft também oferece suporte à observabilidade de rede com o Retina OSS, uma plataforma de observabilidade de rede de código aberto que fornece recursos essenciais de monitoramento de rede.

O Retina OSS é a plataforma de observabilidade de código aberto disponível no retina.sh e no GitHub. Dispõe o seguinte:

• Observabilidade de rede baseada em eBPF: Utiliza tecnologias eBPF para recolher insights com sobrecarga mínima
• Análise profunda de tráfego com contexto Kubernetes: captura e análise abrangentes de fluxos de tráfego de rede com integração total do Kubernetes
• Coleta avançada de métricas: métricas de camada 4, métricas de DNS e recursos de captura de pacotes distribuídos
• Extensibilidade baseada em plugin: Personalize e estenda a funcionalidade através de uma arquitetura de plug-in
• Métricas compatíveis com Prometheus: exporte métricas de rede abrangentes no formato Prometheus com modos métricos configuráveis
• Captura de pacotes distribuídos: capturas de pacotes sob demanda em vários nós para solução de problemas profunda
• Agnóstico de plataforma e CNI: Funciona com qualquer cluster Kubernetes (AKS, habilitado para Arc, local), qualquer sistema operacional (Linux/Windows) e qualquer CNI
• Apoio da comunidade: Código aberto com apoio e contribuições orientados pela comunidade
• Autogerenciado: controle completo sobre a implantação e a configuração
• Integração com o Hubble: integra-se com o Hubble da Cilium para obter informações adicionais sobre a rede

Introdução: implante o Retina OSS usando gráficos do Helm ou manifests do Kubernetes a partir do repositório oficial do Retina. Configure o Prometheus e o Grafana para visualizar métricas, configurar a análise profunda de tráfego 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 das ofertas de observabilidade da rede

Saiba mais

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

• Visão geral da plataforma:O que são Serviços Avançados de Rede de Contentores para AKS?
• Configurar a observabilidade:Configurar a observabilidade da Rede de Contentores
• Métricas de redes de contentores:Visão geral das métricas de redes de contentores
• Registos da rede de contentores:Visão geral dos registos da rede de contentores e Configurar registos da rede de contentores
• Filtragem de métricas (Cilium):Configurar a filtragem de métricas de rede de contentores

Diagnósticos impulsionados por IA

• Agente Container Network Insights (Pré-visualização):Visão geral e configuração do agente
• Servidor AKS MCP:Servidor do Protocolo de Contexto do Modelo AKS

Segurança de Rede de Contentores (Cilium)

• Filtragem FQDN:Conceitos e Aplicar políticas de filtragem FQDN
• Política da Camada 7:Conceitos e Aplicação das políticas L7
• TLS Mútuo (Cilium):Conceitos e Configurar TLS Mútuo
• Encriptação em trânsito:Conceitos de encriptação WireGuard

Plano de dados e plataforma

• Azure CNI alimentado por Cilium:Configure Azure CNI alimentado por Cilium
• Desempenho do encaminhamento do host eBPF:Desempenho da rede de contentores com encaminhamento do host eBPF
• Planos de tabelas do Log Analytics:Escolha um plano de tabela com base no uso de dados

Ferramentas de código aberto

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