O que são métricas de redes de contentores?

Cada pod, serviço e nó num cluster Kubernetes está constantemente a gerar atividade de rede: abertura de ligações, pacotes a serem encaminhados ou descartados, consultas DNS a serem resolvidas ou falhadas. Compreender essa atividade é essencial para a depuração, planeamento de capacidade e manutenção dos serviços saudáveis. Mas a maioria dos sistemas de monitorização falha em dois aspetos:

• Visibilidade insuficiente. Agregados ao nível dos nós dizem que algo está errado, mas não onde. Sem análises detalhadas ao nível do pod que incluam contexto de origem e destino, isolar uma falha na carga de trabalho significa adivinhar.
• Demasiados dados à escala. Um cluster que executa centenas de microserviços pode produzir milhares de séries métricas temporais por nó. Recolher tudo aumenta os custos de armazenamento e atrasa os dashboards.

Métricas de rede de contentores em Advanced Container Networking Services para Azure Kubernetes Service (AKS) abordam ambas as questões. A funcionalidade recolhe métricas de rede tanto ao nível do nó como ao nível do pod nos planos de dados Cilium e não-Cilium suportados, em Linux e Windows.

Nos clusters Cilium, pode-se ir um passo além com o filtro ao nível da fonte, que permite selecionar exatamente quais os namespaces, cargas de trabalho e tipos de métricas que são recolhidos antes de os dados saírem do nó.

A filtragem de métricas de contentores é um mecanismo de controlo precedente à ingestão para dados de observabilidade. Em vez de recolher todas as métricas disponíveis e filtrar depois em dashboards ou consultas, defines o que recolher na origem. Isto mantém métricas de alto valor para as cargas de trabalho que lhe interessam e evita ingerir séries temporais de baixo valor ou ruidosas.

O resultado: observabilidade acionável da rede em qualquer plano de dados suportado, com filtragem opcional e económica no Cilium.

As métricas de rede de contentores proporcionam uma visibilidade profunda ao nível da carga de trabalho, facilitando a resolução de problemas e o planeamento, enquanto o filtro a nível de fonte no Cilium ajuda a manter os custos de observabilidade proporcionais às cargas de trabalho críticas para o negócio.

Recolha e filtros num relance

Use esta tabela para compreender rapidamente onde está disponível uma coleção ampla e onde está disponível a filtragem de granulação fina:

Principais benefícios

• Granularidade ao nível de nós e de pods. Acompanhe o volume de tráfego, as taxas de queda e os estados de ligação ao nível do nó para a saúde da infraestrutura. Analisa cada pod individual com etiquetas de origem e destino para identificar exatamente a carga de trabalho que está a causar o problema.

• Resolução de problemas mais rápida. Quando um serviço começa a perder pacotes ou as consultas DNS falham, métricas ao nível do pod permitem isolar o problema num pod, namespace ou protocolo específico em segundos, não em horas.

• Visualização flexível. Armazene métricas no Azure Managed Prometheus e visualize no Azure Managed Grafana (totalmente gerido), ou traga a sua própria infraestrutura Prometheus e Grafana.

• Escalável desde a conceção. O pipeline gere grandes clusters dinâmicos com centenas de nós e milhares de pods sem que precise de escolher entre cobertura abrangente e volumes de dados geríveis.

• Observabilidade direcionada (aglomerados de cílio). Nos clusters Cilium, o filtragem ao nível da fonte permite-lhe definir os namespaces, etiquetas de pod ou tipos de métricas que lhe interessam e recolher apenas esses. Não é necessário aparar após a recolha.

• Menores custos de ingestão de métricas (clusters de Cilium). Como a filtragem ocorre na origem de cada nó, as séries temporais de métricas indesejadas nunca são coletadas, transmitidas ou armazenadas no seu backend do Prometheus. Pagas apenas pelas métricas de que realmente precisas. Em grandes clusters onde a recolha não filtrada pode produzir milhares de séries temporais por nó, a filtragem ao nível da fonte pode reduzir significativamente os custos de ingestão e armazenamento do Azure Managed Prometheus.

Como funciona

A pilha de agentes em cada nó depende do plano de dados, como mostrado no diagrama.

Os nós Cilium do Linux usam uma pilha em camadas baseada em eBPF: os hooks do kernel eBPF capturam dados de tráfego brutos, o Cilium processa-os e o Hubble expõe-os como métricas no formato Prometheus. Uma vez que o Hubble está entre o nó e o endpoint de scrape, a filtragem ao nível da origem corre nesta camada — seleciona-se quais os namespaces, rótulos de pod e tipos de métricas que são exportados antes que os dados saiam do nó.

Nós não-Cilium do Linux usam ganchos de kernel eBPF que alimentam o Microsoft Retina, com uma camada Hubble por cima para inspeção de fluxo. O Microsoft Retina gere a recolha de métricas e exporta métricas ao nível dos nós e pods no formato Prometheus.

A partir de todos os caminhos, as métricas são extraídas no formato Prometheus e enviadas para o Azure Managed Prometheus ou para o seu próprio backend Prometheus, sendo depois visualizadas no Azure Managed Grafana ou na sua própria stack Grafana.

Para começar, Configurar métricas de rede de contentores e depois, configure a filtragem de métricas de rede de contentores para clusters Cilium.

Quando usar métricas de rede de contentores

As métricas de redes de contentores são concebidas para equipas que necessitam de dados de rede focados e acionáveis, em vez de telemetria bruta. Cenários comuns incluem:

• Depurar uma carga de trabalho específica. Use métricas ao nível do pod para isolar quedas de pacotes, resets TCP ou falhas DNS para um serviço específico. Em clusters Cilium, a filtragem pode restringir a recolha apenas a esse namespace ou etiqueta de pod, cortando ruído em todo o cluster.
• Monitoramento de clusters multi-tenant. Acompanhe a saúde da rede por namespace para que cada equipa tenha visibilidade sobre os seus próprios padrões de tráfego. Nos clusters Cilium, a filtragem com escopo mantém a coleção limitada a namespaces específicos de cada inquilino.
• Planeamento de capacidade. Rastreie as contagens de bytes encaminhados e perdidos por nó para identificar ligações saturadas ou colocação desequilibrada da carga de trabalho.
• Monitorização da saúde do DNS. Falhas nas consultas DNS do Surface e tempos lentos de resolução para detetar problemas antes que se transformem em erros de aplicação.
• Reduzir os custos de observabilidade em grande escala. Em grandes clusters, a recolha não filtrada pode gerar milhares de séries temporais por nó. Nos clusters Cilium, a filtragem ao nível da fonte remove séries indesejadas antes da ingestão, para que os custos se mantenham alinhados com as cargas de trabalho e tipos de métricas que escolher.

Como escolher o que colecionar (clusters Cilium)

Use este modelo de implementação para equilibrar visibilidade e custo:

1. Comece com uma coleção ampla num espaço de nomes não produtivo para estabelecer uma linha de base.
2. Mantenha as métricas de estado de pacotes descartados, DNS e TCP nos espaços de nomes críticos.
3. Definir métricas de fluxo de alta cardinalidade apenas para cargas de trabalho críticas para o negócio.
4. Revise as tendências de ingestão do Prometheus e aperfeiçoe os filtros semanalmente.

Esta abordagem ajuda-o a manter métricas de alto valor enquanto controla o crescimento das séries temporais e os custos de ingestão.

Antes de rever as tabelas de métricas

Tenha em consideração estes pontos:

• Métricas ao nível dos nós estão disponíveis em planos de dados Cilium e não-Cilium suportados.
• Métricas ao nível dos pods estão disponíveis no Linux.
• A filtragem ao nível da fonte está disponível apenas em clusters de Cilium.
• Nos clusters Cilium, as métricas DNS requerem uma política de rede Cilium FQDN.

Referência de métricas

Métricas no nível do nó

Métricas ao nível do nó fornecem estatísticas agregadas de tráfego por nó — pacotes encaminhados e perdidos, contagem de bytes e estados de ligação. Estas métricas estão armazenadas no formato Prometheus e podem ser visualizadas no Grafana.

As métricas a seguir são agregadas por nó. Todas as métricas incluem estes rótulos:

• cluster
• instance (nome do nó)

Métricas no nível do pod (métricas do Hubble)

Métricas ao nível do pod incluem informação de origem e de destino do pod, para que possa identificar problemas de rede ao nível da carga de trabalho individual. Estas métricas abrangem volume de tráfego, pacotes perdidos, resets TCP e fluxos da Camada 4/Camada 7.

Métricas DNS (contagens de consultas, códigos de resposta e erros) são recolhidas por defeito em planos de dados que não são Cilium. Nos planos de dados Cilium, as métricas DNS requerem uma política de rede Cilium FQDN. Também podes resolver problemas de DNS em tempo real usando a CLI do Hubble.

A tabela seguinte descreve as métricas que são agregadas por pod (as informações do nó são preservadas).

Todas as métricas incluem rótulos:

• cluster

• instance (nome do nó)

• source ou destination

  • Para o tráfego de saída, um source rótulo indica o namespace e o nome do pod de origem.

  • Para o tráfego recebido, uma destination etiqueta indica o espaço de nomes e o nome do pod de destino.

Limitations

Plataforma e plano de dados:

• As métricas de nível de pod estão disponíveis apenas no Linux.
• O plano de dados Cilium é suportado a partir do Kubernetes versão 1.29.
• A filtragem de métricas ao nível da fonte está disponível apenas em clusters Cilium.
• Os rótulos métricos têm diferenças sutis entre clusters de Cilium e não-Cilium.

Métricas DNS:

• Nos clusters Cilium, métricas DNS requerem uma política de rede Cilium FQDN, ou pode usar a CLI do Hubble para resolução de problemas DNS em tempo real.

Problemas conhecidos:

• Se um agente de nó do Hubble falhar, o relé do Hubble pode falhar, o que pode interromper as sessões de CLI do Hubble.

Suporte FIPS (apenas planos de dados não-Cilium):

• O FIPS não está disponível nos nós Ubuntu 20.04 devido a restrições do kernel. Use um pool de nós Azure Linux em vez disso. Esta limitação não se aplica aos planos de dados Cilium. Para atualizações, consulte o rastreador de problemas do AKS.

Dimensionamento:

• O serviço gerenciado do Prometheus no Azure Monitor e no Azure Managed Grafana impõe limitações de escala específicas do serviço. Para obter mais informações, consulte Coletar métricas do Prometheus em escala no Azure Monitor.

Pricing

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

Conteúdo relacionado

• Configurar métricas de rede de contentores
• Configurar a filtragem de métricas de rede 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