Che cosa sono le metriche di rete dei contenitori?

Ogni pod, servizio e nodo in un cluster Kubernetes genera costantemente attività di rete: connessioni di apertura, pacchetti inoltrati o eliminati, query DNS che risolvono o hanno esito negativo. Comprendere che l'attività è essenziale per il debug, la pianificazione della capacità e mantenere integri i servizi. Tuttavia, la maggior parte delle configurazioni di monitoraggio non soddisfa in due modi:

  • Visibilità insufficiente. Le aggregazioni a livello di nodo indicano un errore, ma non dove. Senza suddivisioni a livello di pod che includono il contesto di origine e di destinazione, isolare un carico di lavoro problematico significa indovinare.
  • Troppi dati su larga scala. Un cluster che esegue centinaia di microservizi può produrre migliaia di serie temporali delle metriche per nodo. La raccolta di tutti gli elementi determina i costi di archiviazione e rallenta i dashboard.

Le metriche di rete dei container in Servizi di rete dei container avanzati per Servizio Azure Kubernetes (AKS) affrontano entrambi. La funzionalità raccoglie le metriche di rete a livello di nodo e il livello del pod tra i piani dati Cilium e non Cilium supportati, in Linux e Windows.

Nei cluster Cilium è possibile procedere ulteriormente con il filtro a livello di origine, che consente di selezionare esattamente gli spazi dei nomi, i carichi di lavoro e i tipi di metrica raccolti prima che i dati lascino il nodo.

Il filtro delle metriche dei contenitori è un controllo di pre-inserimento per i dati di osservabilità. Invece di raccogliere tutte le metriche e i filtri disponibili in un secondo momento nei dashboard o nelle query, è possibile definire gli elementi da raccogliere nell'origine. In questo modo si mantengono metriche di valore elevato per i carichi di lavoro di cui si è interessati ed evita l'inserimento di serie temporali con valore basso o rumoroso.

Risultato: osservabilità della rete pratica su qualsiasi piano dati supportato, con un filtro facoltativo conveniente su Cilium.

Le metriche di rete dei contenitori offrono una visibilità approfondita a livello di carico di lavoro per la risoluzione dei problemi e la pianificazione, mentre il filtro a livello di origine su Cilium consente di mantenere i costi di osservabilità proporzionali ai carichi di lavoro business critical.

Raccolta e filtro a colpo d'occhio

Usare questa tabella per comprendere rapidamente dove è disponibile un'ampia raccolta e dove è disponibile un filtro con granularità fine:

Capability Cluster di Cilium Cluster non-Cilium
Raccolta di metriche a livello di nodo ✅ ✅
Raccolta di metriche a livello di pod ✅ (Linux) ✅ (Linux)
Filtro a livello di origine per namespace, etichetta del pod e tipo di metrica ✅ ❌
Controllo dei costi tramite il filtro di pre-inserimento ✅ ❌

Important

A partire dal 30 novembre 2025, il servizio Azure Kubernetes non supporta più o fornisce aggiornamenti della sicurezza per Azure Linux 2.0. L'immagine del nodo Linux 2.0 di Azure è bloccata alla versione 202512.06.0. A partire dal 31 marzo 2026, le immagini dei nodi verranno rimosse e non sarà possibile ridimensionare i pool di nodi. Eseguire la migrazione a una versione di Linux di Azure supportata aggiornando i pool di nodi a una versione di Kubernetes supportata o eseguendo la migrazione ad osSku AzureLinux3. Per altre informazioni, vedere il problema di ritiro di GitHub e l'annuncio di ritiro degli aggiornamenti di Azure. Per rimanere informati sugli annunci e sugli aggiornamenti, seguire le note di rilascio di AKS.

Vantaggi principali

  • Granularità a livello di nodo e pod. Tenere traccia del volume del traffico, dei tassi di abbandono e degli stati di connessione a livello di nodo per l'integrità dell'infrastruttura. Eseguire il drill-down in singoli pod con etichette di origine e di destinazione per individuare l'esatto carico di lavoro che causa un problema.

  • Risoluzione dei problemi più rapida. Quando un servizio inizia a perdere pacchetti o le query DNS falliscono, le metriche a livello di pod consentono di isolare il problema a un pod, in uno spazio dei nomi o in un protocollo specifico nell'arco di secondi anziché ore.

  • Visualizzazione flessibile. Archiviare le metriche in Azure Prometheus gestito e visualizzarle in Grafana con gestione Azure (completamente gestito) o usare un'infrastruttura Prometheus e Grafana personalizzata.

  • Scalabile per progettazione. La pipeline gestisce cluster dinamici di grandi dimensioni con centinaia di nodi e migliaia di pod senza dover scegliere tra volumi di dati completi e gestibili.

  • Osservabilità mirata (cluster Cilium). Nei cluster Cilium, il filtro a livello di origine consente di definire gli spazi dei nomi, le etichette dei pod o i tipi di metrica interessati e raccogliere solo quelli. Non è richiesta alcuna rifinitura post-raccolta.

  • Riduzione dei costi di inserimento delle metriche (cluster Cilium). Poiché il filtro avviene alla fonte su ogni nodo, le serie temporali delle metriche indesiderate non vengono mai catturate, trasmesse o inserite nel back-end Prometheus. Si paga solo per le metriche effettivamente necessarie. Nei cluster di grandi dimensioni in cui la raccolta non filtrata può produrre migliaia di serie temporali per nodo, il filtro a livello di origine può ridurre significativamente i costi di inserimento e archiviazione di Prometheus gestiti Azure.

Come funziona

Diagramma dell'architettura dell'osservabilità della rete dei container.

Lo stack di agenti in ogni nodo dipende dal piano dati, come illustrato nel diagramma.

I nodi Cilium Linux usano uno stack basato su eBPF a più livelli: gli hook del kernel eBPF acquisiscono dati di traffico non elaborati, Cilium li elabora e Hubble le espone come metriche in formato Prometheus. Poiché Hubble si trova tra il nodo e l'endpoint di raccolta, il filtraggio a livello di origine avviene a questo livello. Si possono selezionare i namespaces, le etichette dei pod e i tipi di metrica esportati prima che i dati lascino il nodo.

Linux non-Cilium nodes usano hook kernel eBPF che inviano dati a Microsoft Retina, con uno strato Hubble al di sopra per l'ispezione dei flussi. Microsoft Retina gestisce la raccolta delle metriche ed esporta le metriche a livello di nodo e a livello di pod in formato Prometheus.

Da tutti i percorsi, le metriche vengono raccolte in formato Prometheus e inserite in Prometheus gestito di Azure o nel proprio backend Prometheus, quindi visualizzate in Grafana gestito di Azure o nel proprio stack Grafana.

Per iniziare, configurare le metriche di rete dei contenitori e quindi configurare il filtro delle metriche di rete dei contenitori per i cluster Cilium.

Quando usare le metriche di rete dei contenitori

Le metriche di rete dei contenitori sono progettate per i team che necessitano di dati di rete mirati e interattivi anziché dati di telemetria non elaborati. Gli scenari comuni includono:

  • Debug di un carico di lavoro specifico. Usare le metriche a livello di pod per isolare le eliminazioni di pacchetti, le reimpostazioni TCP o gli errori DNS per un determinato servizio. Nei cluster Cilium, il filtro può restringere la raccolta solo a tale spazio dei nomi o etichetta del pod, riducendo il rumore a livello di cluster.
  • Monitoraggio di cluster multi-tenant. Tenere traccia dell'integrità della rete per ogni namespace in modo che ogni team abbia visibilità dei propri modelli di traffico. Nei cluster di Cilium, il filtraggio di ambito limita la raccolta ai namespace specifici del tenant.
  • Pianificazione della capacità. Tenere traccia dei conteggi dei byte inoltrati e eliminati per ogni nodo per identificare i collegamenti saturi o il posizionamento sbilanciato del carico di lavoro.
  • Monitoraggio dell'integrità DNS. Evidenziare errori di query DNS e tempi di risoluzione lenti per intercettare i problemi prima che degenerino in errori applicativi.
  • Riduzione dei costi di osservabilità su larga scala. In cluster di grandi dimensioni, la raccolta non filtrata può generare migliaia di serie temporali per nodo. Nei cluster Cilium, il filtro a livello di origine rimuove le serie indesiderate prima dell'inserimento in modo che i costi rimangano allineati ai carichi di lavoro e ai tipi di metrica scelti.

Come scegliere cosa raccogliere (cluster Cilium)

Usare questo modello di implementazione per bilanciare la visibilità e i costi:

  1. Iniziare con un'ampia raccolta in uno spazio dei nomi non di produzione per stabilire una linea di base.
  2. Mantenere le metriche relative alla perdita di pacchetti, al DNS e allo stato TCP per i namespace critici.
  3. Definire l'ambito delle metriche di flusso ad alta cardinalità esclusivamente per i carichi di lavoro critici per il business.
  4. Esaminare le tendenze di inserimento di Prometheus e perfezionare i filtri settimanalmente.

Questo approccio consente di mantenere le metriche ad alto valore controllando al contempo la crescita delle serie temporali e i costi di inserimento.

Prima di esaminare le tabelle delle metriche

Tieni in considerazione i seguenti punti:

  • Le metriche a livello di nodo sono disponibili nei piani dati Cilium e non Cilium supportati.
  • Le metriche a livello di pod sono disponibili in Linux.
  • Il filtro a livello di origine è disponibile solo nei cluster Cilium.
  • Nei cluster Cilium le metriche DNS richiedono un criterio di rete FQDN Cilium.

Informazioni di riferimento sulle metriche

Metriche a livello di nodo

Le metriche a livello di nodo forniscono statistiche di traffico aggregate per nodo, ovvero pacchetti inoltrati e eliminati, conteggi dei byte e stati di connessione. Queste metriche vengono archiviate in formato Prometheus e possono essere visualizzate in Grafana.

Le metriche seguenti vengono aggregate per ciascun nodo. Tutte le metriche includono queste etichette:

  • cluster
  • instance (nome nodo)

Per i cluster del piano dati Cilium, le metriche a livello di nodo sono disponibili solo in Linux. Cilium espone le metriche seguenti usate dalle metriche di rete dei contenitori:

Nome della metrica di misura Description Etichette aggiuntive Linux Windows
cilium_forward_count_total Numero totale di pacchetti inoltrati direction ✅ ❌
cilium_forward_bytes_total Totale conteggio byte inoltrati direction ✅ ❌
cilium_drop_count_total Totale conteggio pacchetti eliminati direction, reason ✅ ❌
cilium_drop_bytes_total Totale conteggio byte eliminati direction, reason ✅ ❌

Metriche a livello di pod (metriche Hubble)

Le metriche a livello di pod includono informazioni sui pod di origine e di destinazione, quindi è possibile individuare i problemi di rete a livello di singolo carico di lavoro. Queste metriche riguardano il volume del traffico, i pacchetti eliminati, le reimpostazioni TCP e i flussi di livello 4/livello 7.

Le metriche DNS (conteggi delle query, codici di risposta ed errori) vengono raccolte per impostazione predefinita nei piani dati che non utilizzano Cilium. Nei piani dati Cilium, le metriche DNS richiedono un criterio di rete FQDN Cilium. È anche possibile risolvere i problemi relativi al DNS in tempo reale usando l'interfaccia della riga di comando di Hubble.

La tabella seguente descrive le metriche aggregate per ogni pod (le informazioni sul nodo vengono mantenute).

Tutte le metriche includono etichette:

  • cluster

  • instance (nome nodo)

  • source o destination

    • Per il traffico in uscita, l'etichetta source indica il nome e lo spazio dei nomi del pod di origine.

    • Per il traffico in ingresso, un'etichetta destination segnala il namespace e il nome del pod di destinazione.

Nome della metrica di misura Description Etichette aggiuntive Linux Windows
hubble_dns_queries_total Totale richieste DNS per query source o destination, query, qtypes (tipo di query) ✅ ❌
hubble_dns_responses_total Risposte DNS totali per query/risposta source o destination, query, qtypes (tipo di query), rcode (codice restituito), ips_returned (numero di indirizzi IP) ✅ ❌
hubble_drop_total Totale conteggio pacchetti eliminati source o destination, protocol, reason ✅ ❌
hubble_tcp_flags_total Numero totale di pacchetti TCP per flag source o destination, flag ✅ ❌
hubble_flows_processed_total Flussi di rete totali elaborati (traffico di livello 4/livello 7) source o destination, protocol, verdict, type, subtype ✅ ❌

Limitations

Piattaforma e piano dati:

  • Le metriche a livello di pod sono disponibili solo in Linux.
  • Il piano dati Cilium è supportato a partire dalla versione 1.29 di Kubernetes.
  • Il filtro delle metriche a livello di origine è disponibile solo nei cluster Cilium.
  • Le etichette delle metriche hanno differenze sottili tra i cluster Cilium e non Cilium.

Metriche DNS:

  • Nei cluster Cilium le metriche DNS richiedono criteri di rete FQDN Cilium oppure è possibile usare l'interfaccia della riga di comando di Hubble per la risoluzione dei problemi DNS in tempo reale.

Problemi noti:

  • Se un agente del nodo Hubble diventa inattivo, l'Hubble relay potrebbe arrestarsi in modo anomalo, che può interrompere le sessioni CLI di Hubble.

Supporto FIPS (solo per piani di dati non Cilium):

  • FIPS non è disponibile nei nodi Ubuntu 20.04 a causa di restrizioni del kernel. Usare invece un pool di nodi Linux Azure. Questa limitazione non si applica ai piani dati Cilium. Per gli aggiornamenti, vedere il tracker dei problemi di AKS.
Sistema operativo Supporto FIPS
Azure Linux 3.0 Yes
Azure Linux 2.0 Yes
Ubuntu 20.04 No

Scala:

Pricing

Important

Servizi avanzati di rete per contenitori è un'offerta a pagamento.

Per altre informazioni sui prezzi, vedere Servizi di rete dei contenitori avanzati - Prezzi.

Contenuti correlati

  • Last updated on