O que são registos de rede de contentores?

Os registos da rede de contentores em Advanced Container Networking Services para Azure Kubernetes Service (AKS) dão-lhe visibilidade sobre cada fluxo de rede dentro do seu cluster. As métricas dizem-lhe o que está a acontecer na sua rede (uso de largura de banda, taxas de erro). Os registos indicam porquê: quem iniciou uma ligação, que protocolos foram usados e se o tráfego foi permitido ou bloqueado.

Estes registos capturam metadados para cada fluxo de rede:

  • Endereços IP de origem e destino, nomes de pods e nomes de serviços
  • Namespaces, portas e protocolos
  • Direção do trânsito e veredictos de política

Neste contexto, pode correlacionar o comportamento da rede com cargas de trabalho específicas, resolver problemas de conectividade, validar políticas de segurança e realizar análises forenses. Os registos da rede de contentores cobrem o tráfego da Camada 3 (IP), Camada 4 (TCP/UDP) e Camada 7 (HTTP/gRPC/Kafka).

Para gerir o volume e o custo de dados, os registos da rede de contentores suportam agregação de registos de fluxo, que agrupa fluxos semelhantes em registos resumidos em vez de armazenar um registo por evento de ligação. Manténs os padrões operacionais de que precisas enquanto reduzes os custos de armazenamento e ingestão. Para mais informações, consulte Agregação de registos de fluxo.

Os registos de rede de contentores oferecem dois modos:

  • Registos armazenados - Recolha contínua com filtros personalizados e agregação de fluxos. É ideal para monitorização e análise a longo prazo.
  • Registos on-demand - Captura em tempo real através da CLI do Hubble e da interface do Hubble. Ideal para resolução de problemas improvisada.

Use registos armazenados quando precisar de registos persistentes para conformidade, análise de tendências ou alertas automatizados. Use registos on-demand quando estiver a depurar ativamente um problema de conectividade ou desempenho e precisar de visibilidade imediata sobre o tráfego em tempo real.

Registos armazenados

O modo de registos armazenados é ativado automaticamente sempre que o Advanced Container Networking Services está ativado num cluster. A capacidade está implementada, mas não são gerados registos até que digas à ACNS o que deve capturar.

Para começar a recolher registos, defina ContainerNetworkLog recursos personalizados que especifiquem que tráfego monitorizar: por namespace, pod, serviço, protocolo ou veredicto. Uma vez aplicado um CRD, o agente Cilium começa a gerar fluxos que correspondem aos seus filtros e escreve-os em cada nó. A recolha mantém-se ativa até remover os CRDs ou desativar o ACNS.

Como controla exatamente qual o tráfego registado através dos filtros CRD, pode focar-se nos fluxos que importam e evitar recolher dados desnecessários. Combinada com a agregação de registos de fluxo, esta abordagem mantém os custos de armazenamento previsíveis e foca a análise.

Como funciona o modo de logs armazenados

Os Serviços Avançados de Rede de Contentores utilizam tecnologia eBPF com Cilium para capturar fluxos de rede em cada nó. Uma vez ativado o ACNS e aplicado um ContainerNetworkLog recurso personalizado, o agente Cilium recolhe o tráfego que corresponde ao filtro e escreve registos em formato /var/log/acns/hubble/events.log JSON em cada host. A geração de logs corre inteiramente dentro do cluster e não depende do Azure Monitor.

Para uso em produção, recomendamos ativar o add-on Azure Monitor. Quando ativados, os agentes Container Insights recolhem logs locais do host, aplicam limites de controlo de fluxo e enviam-nos para um workspace do Log Analytics, onde pode obter retenção a longo prazo, fazer consultas KQL e utilizar os dashboards integrados do portal Azure e Grafana. Este é o caminho mais integrado e aquele que a maioria dos clientes deveria escolher.

Se a sua equipa já tiver um pipeline de observabilidade, pode em vez disso encaminhar os mesmos logs locais do host para qualquer coletor ou serviço de registos compatível com OpenTelemetry — seja juntamente com o Azure Monitor ou em seu lugar.

Diagrama de como os logs de rede de contêiner funcionam.

Para mais informações sobre throttling e Container Insights, consulte a documentação Container Insights.

Utilização de registos de rede de contentores com ou sem Azure Monitor

Pode consumir registos de rede de contentores de duas formas. A escolha certa depende se queres uma experiência Azure-native integrada ou se já tens um pipeline de observabilidade que queres continuar a usar.

Path O que obtém Quando escolhê-lo
Azure Monitor complemento (recomendado) O Container Insights recolhe registos locais do host num espaço de trabalho de Log Analytics. Tens retenção a longo prazo, KQL, dashboards do portal Azure integrados e dashboards Grafana geridos logo de fábrica. Queres a experiência mais integrada e pronta para produção no AKS com configuração mínima.
Ficheiros do host local utilizando o seu próprio pipeline O ACNS escreve registos JSON em /var/log/acns/hubble/events.log em cada nó. Encaminha-os para qualquer coletor ou serviço de registo compatível com OpenTelemetry — juntamente com o Azure Monitor ou em seu lugar. Já tens uma plataforma centralizada de observabilidade e queres que os registos de rede fiquem lá.

Para a maioria dos clientes, recomendamos ativar o Azure Monitor. É a forma mais rápida de obter capacidades de retenção, consulta e dashboard sem ter de construir o seu próprio pipeline.

Principais capacidades do modo de armazenamento de logs

  • Filtros personalizáveis. Defina ContainerNetworkLog recursos personalizados para filtrar por namespace, pod, serviço, porta, protocolo, veredicto ou direção de tráfego. Apenas o tráfego correspondente é registado, por isso tens controlo preciso sobre o que é recolhido e o custo.

  • Agregação de logs de fluxo. Fluxos semelhantes são automaticamente agrupados em registos resumidos a cada 30 segundos, reduzindo o volume de dados enquanto preservam sinais operacionais como padrões de comunicação de serviço, taxas de erro e veredictos de segurança. Combinada com filtros direcionados, a agregação permite-lhe manter uma ampla visibilidade sem custos excessivos de ingestão de dados. Para mais informações, consulte Agregação de registos de fluxo.

  • Opções de armazenamento de log. O ACNS escreve sempre registos localmente em cada nó. A partir daí, pode escolher como os consumir:

    • Ficheiros locais do anfitrião (sempre ativos): Os registos são armazenados em nós anfitriões em /var/log/acns/hubble. Os ficheiros rodam automaticamente a 50 MB, e os registos mais antigos são sobrescritos. Use isto diretamente para monitorização de curto prazo em tempo real, ou encaminhe os ficheiros para qualquer coletor ou serviço de registo compatível com OpenTelemetry para uma gestão adicional de registos.

    • Azure Monitor (recomendado): Ative o add-on Azure Monitor para recolher e armazenar registos num espaço de trabalho Log Analytics. Obtém armazenamento seguro e compatível, com retenção a longo prazo, consultas KQL, deteção de anomalias, análise histórica e alertas através do serviço gerido do Prometheus. A geração de registos ainda é executada através do agente Cilium e do CRD ContainerNetworkLog; O Azure Monitor adiciona a camada de consumo por cima.

      A ContainerNetworkLogs tabela usa o nível de Analytics por padrão. Podes mudar para o nível Básico para custos de ingestão e retenção mais baixos, mantendo uma experiência de observabilidade semelhante. Cada nível tem um painel dedicado do portal Azure otimizado para as suas capacidades de consulta. Para mais informações sobre planos de tabelas, consulte Log Analytics planos de tabelas. Para aprender a montar o plano da mesa, veja Definir o plano da mesa.

  • Visualização no portal do Azure. Consulte e analise os logs diretamente no Log Analytics, ou utilize os painéis integrados do portal do Azure. Existe um painel dedicado para cada nível de mesa, por isso tens a mesma experiência de observabilidade independentemente do nível que escolheres. Para mais detalhes, veja Visualize logs no portal Azure.

Visualize logs no portal do Azure

Pode visualizar, consultar e analisar logs de fluxo no portal Azure, no espaço de trabalho Log Analytics do seu cluster.

Captura de ecrã dos registos da rede de contentores num espaço de trabalho Log Analytics.

Os registos da rede de contentores incluem painéis integrados no portal Azure para visualizar dados de fluxo. Existe um painel separado para cada nível da tabela Log Analytics:

Dashboard Path Nível de tabela
Registos de Fluxo - Nível Básico (ID: 23155) Azure>Insights>Containers>Networking>Registos de Fluxo - Nível Básico Básico
Registos de Fluxo - Nível de Análise (ID: 23156) Azure>Insights>Containers>Networking>Log de Fluxo - Nível de Análise Análises (por padrão)

Ambos os painéis de controlo mostram quais as cargas de trabalho do AKS que comunicam entre si, incluindo pedidos de rede, respostas, perdas e erros. Utilize o dashboard que corresponde ao nível da tabela configurado para a sua ContainerNetworkLogs tabela.

Dica

A ContainerNetworkLogs tabela, por padrão, está definida para o nível de Analytics. Se quiser reduzir custos, pode mudar para o nível Básico e usar o painel correspondente do Nível Básico sem perder a cobertura de observabilidade. Para mais informações, consulte planos de tabelas do Log Analytics.

Os dashboards do portal Azure têm os seguintes componentes principais:

  • Visão geral da saúde da rede. A secção superior mostra métricas resumidas (registos de fluxo total, pedidos únicos, pedidos abandonados e pedidos encaminhados) para que possa identificar rapidamente anomalias. As estatísticas são detalhadas por protocolo: pedidos descartados por DNS, respostas HTTP 2xx, taxas de pedidos e respostas da Camada 4, e contagem de descartes. Um grafo de dependência de serviços mostra quais os serviços que comunicam entre si, facilitando a identificação de gargalos e caminhos de tráfego inesperados.

    Captura de tela de estatísticas de logs de fluxo e um gráfico de dependência de serviço.

  • Registos de fluxo e registos de erros. O painel separa os registos de fluxo dos registos de erro em vistas distintas, para que possa focar-se nos erros sem ter de filtrar o tráfego normal. Use os filtros incorporados para restringir os resultados por protocolo, namespace ou veredicto. Por exemplo, para resolver falhas de resolução DNS, filtra os registos de erro pelo protocolo DNS.

    Captura de ecrã de logs de fluxo e de erro.

    Cada entrada de registo inclui etiquetas, carimbos temporais e detalhes de origem/destino para o ajudar a identificar eventos específicos durante uma investigação.

    Captura de ecrã dos filtros disponíveis nos painéis do portal Azure.

  • Principais namespaces, cargas de trabalho e erros de DNS. Esta secção destaca os namespaces mais ativos, as cargas de trabalho de maior tráfego, o uso de portas e os erros DNS mais frequentes. Use-o para identificar quais as cargas de trabalho que geram mais tráfego, identificar pedidos perdidos e comparar a distribuição dos protocolos (por exemplo, TCP versus UDP). Padrões invulgares aqui, como picos inesperados ou destinos desconhecidos, podem indicar configurações inadequadas ou preocupações de segurança.

    Captura de ecrã dos principais namespaces e métricas de pod.

Agregação de registos de fluxo

Os fluxos de rede acumulam-se rapidamente. Um cluster com 200 microserviços pode gerar centenas de milhares de registos de fluxo a cada 30 segundos. Armazenar todos esses dados brutos torna-se caro.

Por exemplo, digamos que tanto client-1 como client-2 falam com um server pod via TCP. Ao longo de uma janela de 30 segundos, os registos de fluxo bruto no nó apresentam-se assim:

Fonte Porta de origem Destination Porta de destino Protocolo Flag
cliente-1 12345 servidor 80 TCP SYN
servidor 80 cliente-1 12345 TCP SYN-ACK
cliente-1 12345 servidor 80 TCP ACK
cliente-1 12345 servidor 80 TCP PSH
servidor 80 cliente-1 12345 TCP ACK
Cliente-2 23456 servidor 80 TCP SYN
servidor 80 Cliente-2 23456 TCP SYN-ACK
Cliente-2 23456 servidor 80 TCP ACK
Cliente-2 23456 servidor 80 TCP PSH
servidor 80 Cliente-2 23456 TCP ACK

Com a agregação, esses 10 registos tornam-se dois:

Fonte Porta de origem Destination Porta de destino Protocolo Fluxos enviados Fluxos recebidos
cliente-1 12345 servidor 80 TCP 4 6
Cliente-2 23456 servidor 80 TCP 4 6

A agregação de registos de fluxo aborda isto agrupando fluxos semelhantes em registos resumidos. Durante cada janela de 30 segundos, fluxos que partilham os mesmos campos-chave de agregação são combinados num único registo com uma contagem de quantos fluxos representa.

Os seguintes campos compõem a chave de agregação:

Campo Description
verdict ENCAMINHADO, DESCARTADO ou ERRO
is_reply Se o fluxo é um pedido (falso) ou uma resposta (verdadeira)
drop_reason_desc Razão pela qual os pacotes foram eliminados
source.namespace Espaço de nomes pod de origem
destination.namespace Namespace do pod de destino
source.workloads Carga de trabalho de origem (Deployment, StatefulSet ou DaemonSet)
destination.workloads Carga de trabalho de destino (Deployment, StatefulSet ou DaemonSet)
source.identity Identidade de segurança de origem (sempre presente como recurso de contingência)
destination.identity Identidade de segurança de destino (sempre presente como plano B)
l4.TCP.destination_port Porta de destino TCP
l4.UDP.destination_port Porta de destino UDP
l7.http.code Código de resposta HTTP (200, 404, 500, etc.)
l7.dns.rcode Código de resposta DNS (NOERROR, NXDOMAIN, etc.)
IP.ipVersion IPv4 ou IPv6
IP.encrypted Se o fluxo está encriptado (WireGuard/IPsec)
source.cluster_name Nome do cluster de origem
destination.cluster_name Nome do cluster de destino

Numa janela de 30 segundos, fluxos que correspondem a todos estes campos são combinados num único registo. Isto preserva os sinais de que precisa (que serviços comunicam, com que frequência, que erros ocorrem, se o tráfego foi permitido ou bloqueado) enquanto reduz significativamente o volume de dados. Ao contrário da amostragem, que descarta aleatoriamente fluxos e pode perder eventos raros de segurança, a agregação mantém 100% da informação do padrão.

Pontos principais:

  • A agregação está ativada e configurada por defeito. Isto reduz os custos de armazenamento e ingestão de registos sem necessidade de ajustes manuais.
  • Você controla que tráfego é capturado através de includeFilters no ContainerNetworkLog CRD.
  • Filtros mais estreitos (namespace específico ou pares de serviços) normalmente alcançam melhor compressão porque os fluxos capturados são mais semelhantes.
  • Os registos agregados ignoram atributos de alta cardinalidade e de fluxo individual (por exemplo, timestamps individuais, IPs de pods, URLs HTTP, nomes de consultas DNS) para minimizar o volume de ingestão e o custo de armazenamento. São desenhados para deteção de problemas de alto nível. Utilize registos sob demanda para análises e investigações de fluxo detalhadas.

Observação

A redução real de armazenamento varia consoante a configuração do teu filtro, diversidade de carga de trabalho e padrões de tráfego.

Registos a pedido

Os registos on-demand permitem-lhe capturar e inspecionar registos de fluxo em tempo real, sem configuração prévia ou armazenamento persistente. Use logs on-demand quando estiver a tentar resolver problemas de conectividade ou desempenho e precisar de visibilidade imediata.

O ACNS fornece duas ferramentas para captura sob demanda. Para configurar qualquer uma das ferramentas, veja Configurar o modo de registos a pedido.

Hubble CLI

A CLI do Hubble permite-lhe consultar, filtrar e analisar registos de fluxo diretamente a partir do seu terminal. É especialmente útil quando se precisam de filtros de granulação fina, por exemplo, isolar o tráfego por namespace, etiqueta de pod ou veredicto durante uma sessão ativa de depuração.

Captura de tela da CLI do Hubble.

Interface do usuário do Hubble

A interface do Hubble fornece uma vista gráfica da comunicação entre serviços. É uma boa opção quando se quer traçar visualmente caminhos de tráfego, identificar que serviços estão a comunicar e detetar anomalias sem escrever comandos CLI.

Captura de tela da interface do usuário do Hubble.

Principais benefícios dos logs sob demanda

  • Não é necessária configuração prévia. Comece a capturar fluxos imediatamente, sem definir recursos personalizados ou configurar armazenamento.
  • Visibilidade em tempo real. Inspecionar o tráfego em tempo real e visualizar os metadados dos pacotes à medida que surgem problemas.
  • Resolução rápida de problemas. Filtre fluxos interativamente através da CLI do Hubble, ou veja os mapas de serviços na UI do Hubble.
  • Despesas baixas. Não é necessário armazenamento persistente, por isso não há custos contínuos para investigações ad hoc.

Recomendações para registos armazenados

  1. Comece com filtros amplos e depois reduza a escolha. Quando ativar os registos de fluxo pela primeira vez, use filtros largos para captar tráfego através dos seus namespaces-chave. Executa a configuração durante alguns dias e revê os dados recolhidos no Log Analytics. Veja o volume de dados, o custo e se os fluxos capturados correspondem ao que realmente precisa. Depois ajusta o teu includeFilters para focar no tráfego de elevado valor e eliminar o ruído.

  2. Use primeiro os painéis de controlo pré-construídos. Os painéis integrados do portal Azure cobrem casos de uso comuns como padrões de comunicação de serviços, taxas de erro e falhas DNS. Começa por aí. Adiciona painéis personalizados ou consultas de Log Analytics apenas se precisares de visibilidade que os dashboards pré-construídos não oferecem.

  3. Revê periodicamente. À medida que as cargas de trabalho e os padrões de tráfego mudam, os seus filtros podem precisar de ser atualizados. Verifique periodicamente o volume de dados e a cobertura de fluxo para garantir que continua a captar o tráfego certo a um custo razoável.

Limitações

Requisitos de plano de dados e funcionalidades:

  • O modo de registos armazenados funciona apenas com o plano de dados Cilium.
  • Os logs de fluxo da Camada 7 são capturados somente quando o suporte à política da Camada 7 está habilitado. Para obter mais informações, consulte Configurar uma política de camada 7.
  • Os fluxos e métricas DNS só são captados quando é aplicada uma política de rede Cilium Fully Qualified Domain Name (FQDN). Para obter mais informações, consulte Configurar uma política FQDN.

Compensações de agregação:

  • A agregação de registos de fluxo não preserva carimbos temporais individuais de fluxo, endereços IP por pod ou campos de alta cardinalidade como URLs HTTP e nomes de consultas DNS. Use registos a pedido para investigação por fluxo.

Armazenamento e plataforma:

  • O ficheiro local do anfitrião em /var/log/acns/hubble/ está limitado a 50 MB por nó e faz rotação automática. Se precisar de retenção a longo prazo, ative o Azure Monitor (recomendado) ou encaminhe o ficheiro para o seu próprio serviço de loging.
  • O plano da tabela de logs auxiliares não é suportado.

Preços

Importante

Advanced Container Networking Services é uma oferta paga.

Para obter mais informações sobre preços, consulte Advanced Container Networking Services - Pricing.

Conteúdo relacionado

  • Last updated on