O que são registos de rede de contentores?

Os registos de redes de contentores no Advanced Container Networking Services for Azure Kubernetes Service (AKS) ajudam a investigar que cargas de trabalho comunicaram, que destinos alcançaram e se o tráfego foi encaminhado ou descartado. Use métricas para detetar um problema de rede e depois utilize logs para examinar o tráfego envolvido. Um veredicto de fluxo por si só não estabelece se um pedido da aplicação foi bem-sucedido.

Dependendo do tipo de fluxo, configuração de visibilidade e campos de agregação retidos, os registos podem incluir:

• 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).

Para registos armazenados, a agregação personalizável de registos de fluxo ajuda a equilibrar a visibilidade operacional com o volume e custo dos dados. A agregação resume observações semelhantes, preservando padrões de comunicação da carga de trabalho e contagens de observações encaminhadas ou descartadas. Adicione campos de agrupamento para além dos padrões do serviço para adaptar esses resumos às suas necessidades. A redução de volume depende de quanto tráfego partilha os mesmos valores de agrupamento. Para mais informações, consulte Agregação de registos de fluxo.

Escolha um modo de recolha

Comece por configurar registos de rede de contentores. O guia separa a coleção, o encaminhamento opcional do Azure Monitor e a verificação.

Registos armazenados

Num cluster Cilium suportado com ACNS ativado, defina qual o tráfego a recolher antes de esperar registos armazenados. Ativar o serviço sozinho não seleciona tráfego nem configura a retenção a longo prazo.

Para começar a recolher registos, defina ContainerNetworkLog recursos personalizados que selecionem o tráfego por namespace, pod, etiquetas, endereço IP, identidade numérica de segurança Cilium, protocolo ou veredito. Depois de a configuração chegar aos agentes, os nós que observam o tráfego correspondente escrevem os registos selecionados. Múltiplos recursos podem recolher tráfego ao mesmo tempo.

Utilize os filtros para focar nos fluxos que importam. Utilize agregação de registos de fluxo para resumir esses fluxos e personalize os seus campos de agrupamento para preservar as distinções de que as suas investigações precisam. Em conjunto, estes controlos permitem-lhe adaptar o que recolhe e a forma como é resumido. Reveja o volume de dados resultante: filtros mais estreitos podem reduzir a recolha, enquanto mais campos de agrupamento podem aumentar o número de registos.

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.

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

Use o Azure Monitor para consultas e dashboards integrados, ou mantenha o seu pipeline de registos existente.

Sem um pipeline de encaminhamento, os registos permanecem em ficheiros nó-locais rotativos e não são mantidos para investigações de longo prazo.

Principais capacidades do modo de armazenamento de logs

Personalize a sua observabilidade para corresponder às suas necessidades: escolha que tráfego recolher e que detalhes usar para distinguir ao agrupá-lo em registos armazenados.

• Filtros personalizáveis. Defina recursos personalizados ContainerNetworkLog para selecionar tráfego por namespace de origem ou destino, pod, etiqueta, endereço IP ou intervalo CIDR, identidade de segurança Cilium, protocolo ou veredicto. O tráfego que corresponde aos filtros de qualquer recurso configurado é elegível para recolha, dando-lhe controlo sobre o que recolhe e ajudando-o a gerir o volume de ingestão.

• Agregação de registos de fluxo personalizável. Utilize a agregação para reduzir o volume de logs armazenado, mantendo os detalhes necessários para investigações de rede. Por defeito, a agregação combina observações de fluxo com valores correspondentes de campos de agrupamento em registos resumidos a cada 30 segundos. Adicione campos de agrupamento para reter detalhes para além dos padrões do serviço. Mais campos de agrupamento podem produzir mais registos, por isso associe a agregação a filtros direcionados para equilibrar as necessidades de investigação com os custos de ingestão e armazenamento. Saiba mais sobre 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 registos no Log Analytics, ou use o painel para o plano da sua tabela. Revise as capacidades de consulta e retenção do plano antes de o escolher. Para mais detalhes, veja Visualize logs no portal Azure.

Visualize logs no portal do Azure

Para investigações detalhadas, abra Monitorização>Registos na página do seu cluster AKS no portal Azure. No espaço de trabalho Log Analytics de receção, consulte a ContainerNetworkLogs tabela.

Na página do seu cluster AKS no portal Azure, selecione Monitorização>Dashboards com Grafana para visualizar os dashboards de fluxo incorporados. Não precisa de uma instância Azure Managed Grafana, e não há custo adicional pelos dashboards. ACNS e taxas de ingestão e retenção de logs continuam a aplicar-se.

Escolha o painel de controlo que corresponde à sua ContainerNetworkLogs planta de mesas:

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.

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

• Visão geral da saúde da rede. Revise resumos de tráfego e observações encaminhadas ou descartadas, e depois use o grafo de dependência de serviço para identificar caminhos de comunicação que valem a pena investigar. Detalhes específicos do protocolo dependem da visibilidade e dos campos retidos. Contagens agregadas de observações não são contagens únicas de solicitações.

  

• 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.

  

  Os detalhes disponíveis no painel dependem do tráfego recolhido e da configuração de agregação. Para adaptar os detalhes nos seus registos armazenados, veja Personalizar a agregação de registos de fluxo.

  Utilize os carimbos temporais disponíveis e os detalhes de origem/destino para correlacionar registos com uma investigação. Um registo agregado não fornece um carimbo temporal separado para cada observação do seu grupo.

  

• 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.

  

Agregação de registos de fluxo

Cargas de trabalho intensivas podem gerar muitas observações repetidas de fluxo entre os mesmos pontos finais. Armazenar cada observação separadamente aumenta a quantidade de dados que deve ingerir, reter e pesquisar, mesmo quando a sua questão imediata é simplesmente que cargas de trabalho comunicaram entre si e se o tráfego foi encaminhado ou descartado.

A agregação fornece um ponto de partida de menor volume para investigações históricas da rede. Cada nó combina observações de fluxo selecionadas que partilham os mesmos valores de campo de agrupamento dentro de um intervalo de agregação. Em vez de escrever cada observação separadamente, escreve um registo resumido para cada grupo, incluindo contagens de observações de entrada, saída e direção desconhecida.

Exemplo: Antes e depois da agregação

Considere dois pods clientes, client-1 e client-2, a comunicar com um server pod através da porta 80 TCP durante uma janela de 30 segundos. Cada pod pertence a um workload separado com o mesmo nome. As observações seguintes ilustram a configuração da ligação, a transferência de dados e as respostas.

Antes da agregação: dez observações

Para esta ilustração, um nó observa cada registo uma vez nos pontos finais do cliente: as observações cliente-para-servidor são saída e as respostas são entrada. Todos os veredictos são FORWARDED, e os outros valores de agrupamento padrão são idênticos dentro de cada grupo mostrado abaixo.

Após agregação padrão: quatro registos resumidos

As dez observações tornam-se quatro registos, preservando todas as dez observações nas suas contagens. Ainda pode ver quais as cargas de trabalho que comunicaram entre si, as portas de destino e o volume observado em cada direção sem armazenar cada transição de flag TCP separadamente.

Os grupos mantêm-se separados pelas seguintes razões:

• Cargas de trabalho diferentes: os metadados da carga de trabalho de origem e destino são campos de agrupamento predefinidos.
• Tráfego e respostas originais: valores de endpoint originais, portas de destino e is_reply diferem, para que as duas direções não colapsem num só registo.
• Diferentes portas de destino de resposta:12345 e 23456 são mantidas como portas de destino no tráfego de resposta. Portas de origem, nomes individuais de pods e flags TCP não são mantidos pela configuração de agrupamento padrão.

Definições padrão de agregação

A agregação está ativada por defeito para registos armazenados, com um intervalo de agregação de 30 segundos e os campos de agrupamento por defeito listados na tabela seguinte. Dentro do intervalo de cada nó, observações com os mesmos valores para todos os campos de agrupamento são combinadas num registo resumido.

Um campo só pode conter um valor quando essa informação está disponível no fluxo original. O agrupamento por defeito não permite a inspeção DNS ou HTTP.

Estes padrões preservam a comunicação da carga de trabalho, portas de destino, veredictos e códigos de resposta. Não retêm todos os detalhes por fluxo: nomes individuais dos pods, endereços IP de origem e destino, portas de origem do cliente, nomes de consultas DNS e URLs HTTP não estão nesta lista predefinida.

Campos adicionais estendem esta lista; não a substituem. Utilize spec.aggregation.additionalFields para personalizar o agrupamento sem remover campos padrão ou alterar o intervalo de 30 segundos. Repetir um campo por defeito não adiciona outra cópia. Alterações afetam registos futuros e não é possível recuperar detalhes omitidos dos registos históricos.

Personalizar agregação de registos de fluxo

Adapte a agregação de registos de fluxo às suas necessidades operacionais e de investigação, escolhendo campos de agrupamento adicionais para além dos padrões do serviço. Controla quais as distinções que os seus registos resumidos preservam, desde a direção do tráfego e o tipo de pedido/resposta DNS até endereços IP individuais, nomes DNS ou URLs HTTP. Escolha qualquer campo suportado pelo esquema de fluxo do seu cluster para ajudar a responder às perguntas que lhe interessam.

Adicione campos a spec.aggregation.additionalFields num recurso ContainerNetworkLog para personalizar a agregação. Os campos adicionais tornam-se chaves de agrupamento: fluxos com valores diferentes para esses campos são armazenados em grupos separados.

Por exemplo, adicionar os seguintes campos separa observações que, de outra forma, partilhariam o mesmo grupo de agregação:

Estes campos são exemplos, não uma lista de permissões exaustiva. Pode especificar caminhos de campo válidos a partir da mensagem do Hubble Flow na definição flow.proto do Cilium. Utilize os campos suportados pela versão do Cilium em execução no seu cluster; o ramo associado main pode incluir campos que o seu cluster ainda não suporta. O fluxo original deve conter o valor de um campo para que este seja mantido.

Campos de maior cardinalidade, como endereços IP, nomes individuais de pods, portas de origem, nomes DNS e URLs HTTP, estão disponíveis quando precisa desse nível de detalhe. Como podem ter muitos valores distintos, a sua habilitação pode aumentar o volume de logs e os custos de ingestão e armazenamento em todo o cluster. Antes de os ativar, avalie o volume esperado, o custo e as implicações de dados sensíveis. Depois monitoriza o uso para equilibrar os detalhes de que precisas com o teu orçamento.

Registos que contêm os campos retidos são escritos em /var/log/acns/hubble/events.log em cada nó que observa o tráfego correspondente. Quando o encaminhamento do Azure Monitor está configurado, pode consultar os registos recolhidos no Log Analytics usando as colunas disponíveis na tabela ContainerNetworkLogs table, incluindo as propriedades retidas representadas nas suas colunas dinâmicas. Utilize o esquema da tabela para identificar a coluna ou propriedade dinâmica a referenciar na sua consulta.

Selecionar tráfego por identidade de segurança

Utilize identidades de segurança Cilium nos filtros de origem ou destino para escolher que tráfego registar. Combine os filtros de identidade com namespace, pod, protocolo ou critérios de veredicto. Por exemplo, selecione tráfego TCP de um namespace para endpoints que o Cilium classifica como world.

Uma identidade de segurança é a classificação de um endpoint feita pela Cilium, não uma identidade gerida pelo Azure nem uma identidade de utilizador. A configuração aceita IDs numéricos, não alias como world. Veja o exemplo de identidade e os valores.

Filtros personalizáveis e agregação oferecem controlos complementares: os filtros selecionam os fluxos a recolher, enquanto campos de agrupamento adicionais personalizam a forma como todos os fluxos selecionados no cluster são resumidos.

Compreenda o âmbito e o custo

Campos adicionais aplicam-se a todos os registos armazenados selecionados no cluster. Eles não estão limitados aos filtros do recurso que os solicita.

Por exemplo, se um recurso solicita l7.type e outro pede traffic_direction, ambos os campos passam a fazer parte da configuração de agrupamento do cluster. Eliminar o primeiro recurso só remove o seu campo se nenhum outro recurso válido o solicitar. Os campos fornecidos pelo serviço mantêm-se no local.

Valores de campo mais distintos podem produzir mais registos. Comece pelos campos necessários para a sua investigação, revise o volume de ingestão e remova adições temporárias quando terminar. Coordene mudanças com outras equipas que recolham registos do mesmo cluster.

Utilize Configurar registos de rede de contentores para exemplos completos de YAML e passos de verificação.

Registos a pedido

Registos on-demand permitem-lhe inspecionar registos de fluxo em tempo real sem definir um recurso de registo armazenado ou configurar armazenamento persistente. Ative o ACNS e ligue primeiro o cliente Hubble. Use este modo quando precisar de visibilidade imediata durante a resolução de problemas.

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.

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.

Principais benefícios dos logs sob demanda

• Não é necessária configuração de registo armazenado. Depois de ligar o Hubble ao seu cluster compatível com ACNS, inspecione os fluxos disponíveis sem definir um recurso ContainerNetworkLog.
• 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.
• Não é necessário armazenamento persistente. Inspecionar fluxos ativos sem configurar armazenamento histórico de registos. As taxas de serviço ACNS continuam a aplicar-se.

Recomendações para registos armazenados

1. Começa com um workload e uma pergunta clara. Selecione a aplicação e o tráfego necessários para a investigação. Verificar registos novos, rever o volume e depois expandir a coleção, se necessário. Evite ativar uma coleção ampla apenas para testar se o registo funciona.

2. Adapte a agregação às suas necessidades operacionais. Escolha campos de agrupamento adicionais que ajudem a responder às suas perguntas e avalie o seu volume e impacto no custo. Coordenar alterações a nível de cluster com outras equipas e remover adições temporárias quando a investigação terminar. Trate os nomes e URLs DNS como dados operacionais potencialmente sensíveis.

3. 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.

4. 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:

• Campos adicionais podem manter distinções, como endereços IP de origem e destino, URLs HTTP ou nomes de consultas DNS. O fluxo original deve conter os dados.
• Os campos aplicam-se a registos armazenados selecionados em todo o cluster e podem aumentar a contagem de registos e os custos de ingestão.
• As alterações afetam os dados recém-recolhidos. Eles não recuperam detalhes dos registos históricos, não alteram o esquema da tabela nem fornecem um carimbo temporal para cada evento num registo agregado. Utilize os logs a pedido para inspeção em tempo real 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

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

Conteúdo relacionado

• Identificar nomes DNS associados a falhas

• Configurar registos de redes de contentores

• Serviços Avançados de Rede de Contentores para AKS

• Observabilidade de Redes de Contentores em Serviços Avançados de Redes de Contentores

• Segurança de Redes de Contentores em Serviços Avançados de Redes de Contentores