Diagnosticare e risolvere i problemi di rete di Azure Kubernetes Service (AKS) con i Servizi avanzati di rete per container

Questa guida illustra come diagnosticare e risolvere i problemi di rete reali in Servizio Azure Kubernetes (AKS) usando Servizi di rete contenitori avanzati (ACNS). Ogni playbook inizia da un sintomo (errori DNS, gocce di pacchetti, squilibri del traffico, errori L7), mostra il segnale da controllare per primo e indica quando eseguire il drill-in dei log.

La guida è organizzata in base alle attività, non alle funzionalità. Leggi il modello mentale una volta, poi passa direttamente al manuale che corrisponde al tuo sintomo.

Come questa guida ti aiuta a risolvere

• Errori di risoluzione DNS nei pod (NXDOMAIN, SERVFAIL, risposte mancanti).
• Le eliminazioni dei pacchetti causate da criteri di rete configurati in modo errato, rilevamento delle connessioni o riduzione della connettività.
• Squilibrio del traffico tra pod o namespace (pod caldi, distribuzione del carico non uniforme).
• Errori dell'applicazione L7 (HTTP 4xx/5xx, errori gRPC, eliminazione di Kafka).
• Monitoraggio dell'integrità della rete a livello di cluster e pianificazione della capacità.
• Controllo dei costi di osservabilità tramite la raccolta di log e metriche mirate.

Modello mentale: modalità di adattamento delle metriche, dei log e del filtro

ACNS offre tre segnali. Ogni risposta a una domanda diversa.

Per informazioni di riferimento sulle funzionalità più approfondite, vedere Metriche di rete dei contenitori, log di rete dei contenitori e Configurare il filtro delle metriche.

Flusso di risoluzione dei problemi standard

Usare questo ciclo per qualsiasi evento imprevisto di rete:

1. Iniziare nei dashboard delle metriche. Confermare l'anomalia: un picco di interruzioni, errori, reimpostazioni TCP o errori DNS. Identificare il nodo, lo spazio dei nomi o il carico di lavoro interessati.
2. Spostarsi sui log archiviati. Filtrare la tabella ContainerNetworkLogs in base dallo spazio dei nomi e all'intervallo di tempo del passaggio 1. I log riportano il verdetto, la ragione di eliminazione, i carichi di lavoro di origine/destinazione e i codici di stato L7 che non vengono riportati dalle metriche.
3. Riprodurre dal vivo con i log su richiesta. Se il problema è intermittente o già risolto nei dati archiviati, usare l'interfaccia della riga di comando di Hubble o l'interfaccia utente di Hubble per acquisire flussi live per tale carico di lavoro.
4. Convalidare la correzione. Controllare nuovamente lo stesso pannello delle metriche ed eseguire nuovamente la stessa query KQL. L'anomalia dovrebbe essere scomparsa.
5. Ottimizzare la raccolta. Se hai raccolto troppo durante l'incidente, restringi il ContainerNetworkLog CRD o applica un ContainerNetworkMetric filtro in modo da acquisire solo ciò che è necessario.

Dashboard integrati a colpo d'occhio

Configurare queste impostazioni una sola volta con Configura Container Network Observability. Si farà riferimento a loro durante tutto il playbook.

Playbook 1: Diagnosticare gli errori di risoluzione DNS

Sintomo. I pod registrano errori come DNS_PROBE_FINISHED_NXDOMAIN, SERVFAILo si bloccano durante la risoluzione dei nomi dei servizi.

Obiettivo. Identificare se l'errore è upstream (CoreDNS o resolver esterno), basato su criteri (negazione FQDN) o specifico del carico di lavoro.

Passaggio 1: Confermare l'anomalia nelle metriche DNS

Aprire il dashboard DNS (cluster). Cercare modifiche improvvise nel volume delle richieste, nel volume delle risposte o nel % delle richieste senza risposta. I pannelli di riepilogo illustrano le query più comuni, i codici di risposta più comuni e i nodi che generano la maggior parte degli errori.

Cosa cercare: Aumento prolungato delle risposte di errore, un calo delle risposte riuscite o un singolo nodo che domina il conteggio degli errori. Prendere nota del timestamp dell'anomalia.

Passaggio 2: Identificare i pod più rumorosi

Scorrere verso il basso nello stesso dashboard fino al pannello che classifica i pod in base agli errori DNS in tutti i namespace. Le voci principali sono i tuoi sospetti iniziali.

Punto decisionale.

• Se gli errori sono concentrati nei pod CoreDNS, vai al dashboard DNS (Carichi di lavoro) con kube-system / coredns già selezionato: CoreDNS stesso o il sistema di risoluzione upstream è il problema.
• Se gli errori si concentrano in un carico di lavoro dell'applicazione, quel carico genera query non valide o viene negato da una politica FQDN.

Passaggio 3: Esaminare il carico di lavoro interessato

Aprire il dashboard DNS (carico di lavoro) per il carico di lavoro identificato.

• Pannelli delle Richieste DNS / Pannelli delle Risposte DNS. Una percentuale alta di Richieste Senza Risposta indica timeout a monte o sovraccarico di query.

  

• Errori DNS per tipo. Associare il picco a un codice

  • NXDOMAIN : nome di dominio errato o non aggiornato nella configurazione dell'app.
  • SERVFAIL — problema del sistema di risoluzione upstream.
  • Query rifiutata : criterio FQDN o mancata corrispondenza della configurazione DNS.

  

• INDIRIZZI IP di risposta DNS restituiti. Conferma il tasso di successo nella risoluzione. Un calo significa in genere che CoreDNS non può raggiungere il server upstream; un picco improvviso può indicare una raffica di richieste di query.

• Tabella di risposta DNS. Usare questa opzione per individuare modelli come "I record A hanno esito negativo ma i record AAAA hanno esito positivo", che in genere punta a uno stack non configurato correttamente per gli ambienti solo IPv4.

  

Passaggio 4: Confermare con i log archiviati

Eseguire questa query KQL nell'area di lavoro Log Analytics per individuare i modelli di errore DNS. Le righe aggregate mantengono Verdict, gli spazi dei nomi, i carichi di lavoro e Layer7.dns.rcode, quindi questa query funziona sulla tabella aggregata predefinita: 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

Sostituire <start-time> e <end-time> con timestamp nel formato 2026-04-30T15:00:00Z.

Cosa controllare nei risultati:

• Verdetto. DROPPED indica che un FQDN o un criterio di rete impedisce la query. FORWARDED con un valore nonNOERRORDnsRcode (ad esempio, NXDOMAIN, SERVFAIL) indica che il sistema di risoluzione upstream ha restituito un errore.
• Carichi di lavoro di origine/destinazione. Verificare che il traffico sia destinato al carico di lavoro CoreDNS previsto.
• DnsRcode. Il codice di risposta DNS identifica immediatamente la modalità di errore.

È anche possibile visualizzare gli stessi flussi nel portale di Azure nel cluster AKS>Insights>Networking>Flow Logs.

Passaggio 5: Riprodurre live se il problema è intermittente

Se il picco è già passato e non è possibile acquisirlo nei log archiviati, usare l'interfaccia della riga di comando di Hubble su richiesta:

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

Passaggio 6: Convalidare la correzione

Dopo aver aggiornato i criteri FQDN, correggere la configurazione dell'applicazione o ridimensionare CoreDNS, riaprire il dashboard DNS (Carico di lavoro). La frequenza degli errori deve scendere entro un minuto o due. Eseguire di nuovo la query KQL per la stessa finestra temporale per verificare che le query non riuscite non siano più presenti.

Playbook 2: Investigare le perdite di pacchetti

Sintomo. I servizi non possono raggiungere l'un l'altro. Le sonde falliscono. Timeout delle connessioni. I contatori di rilascio salgono nei dashboard.

Obiettivo. Identificare se le perdite sono causate da criteri di rete, dall'esaurimento del tracciamento delle connessioni o da problemi di connettività upstream e quale carico di lavoro ne è responsabile.

Passaggio 1: Individuare i drop al livello di spazio dei nomi

Aprire i flussi pod (Spazio dei Nomi). Le mappe di calore evidenziano i namespace e i pod con i tassi di perdita in uscita e in entrata più elevati.

Le celle più luminose indicano frequenze di rilascio più elevate. Prendere nota dello spazio dei nomi e dell'intervallo di tempo.

Passaggio 2: Esaminare il carico di lavoro interessato

Apri Drops (carico di lavoro) e seleziona il carico di lavoro identificato.

• La visualizzazione del carico di lavoro mostra le eliminazioni massime/minime in uscita di pacchetti al secondo. Utilizzarlo per valutare la gravità.

  

• Il traffico eliminato per motivo è il pannello più importante. Il motivo indica cosa correggere:

  • Politica negata — un oggetto NetworkPolicy o CiliumNetworkPolicy blocca il traffico.
  • CT: inserimento mappa non riuscito : la tabella di rilevamento della connessione è piena; ridimensionare il nodo o ridurre la varianza della connessione.
  • Protocollo L3 non supportato/Pacchetto non valido : l'applicazione o il proxy inviano traffico in formato non valido.

  

• Mappa termica delle gocce in ingresso/in uscita. Identifica le coppie di pod specifiche che stanno perdendo traffico.

  

• Totale accumulato delle perdite per pod di origine. Classifica i trasgressori in modo da sapere quale replica esaminare per prima.

  

Passaggio 3: Confermare i flussi eliminati nei log archiviati

Trovare i carichi di lavoro di origine e di destinazione esatti del traffico eliminato. Verdict, DropReason, namespace e workload sono tutti nella chiave di aggregazione, quindi questa query funziona sui dati aggregati.

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

Restringi il namespace una volta che l'hai identificato:

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

Il dashboard Flow Logs nel portale di Azure mostra gli stessi dati visivamente, incluso un grafico delle dipendenze del servizio che evidenzia i percorsi bloccati.

Passaggio 4: Verifica incrociata con i criteri

Dopo aver appreso il pod di origine e il pod di destinazione:

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

Confronta il flusso non riuscito con le regole di ingresso/uscita. La causa più comune è un criterio di negazione predefinito aggiunto senza una regola di autorizzazione per un percorso legittimo.

Passaggio 5: Convalidare la correzione

Dopo aver modificato i criteri, il Dropped Traffic by Reason grafico dovrebbe essere flat per i criteri negati. Rieseguire la query KQL. DROPPED I verdetti per la coppia di origine e destinazione dovrebbero cessare di apparire.

Playbook 3: Trovare squilibri di traffico e hot pod

Sintomo. Alcuni pod di un Deployment stanno saturando la CPU o la rete mentre altri sono inattivi. Le reimpostazioni TCP scalano. I report di latenza provengono dagli utenti (la latenza stessa non è visibile nelle metriche ACNS). Vedere la nota in Modello mentale.

Obiettivo. Identificare i pod che trasportano traffico sproporzionato e se le reimpostazioni indicano l'overload o il bilanciamento del carico non configurato correttamente.

Passaggio 1: Confrontare il traffico a livello di pod

Aprire flussi pod (carico di lavoro). Lo snapshot del carico di lavoro riepiloga il traffico in uscita/in ingresso e le eliminazioni.

Il pannello del traffico per tipo di traccia mostra l'andamento del traffico nel tempo. Un ampio divario tra il volume in uscita e quello in ingresso spesso indica un collo di bottiglia a valle.

Passaggio 2: Individuare i pod più attivi con le heatmap

Le mappe di calore dell'intero pod mettono in evidenza lo squilibrio. Se un pod (ad esempio, default/tcp-client-0) viene visualizzato sia nelle mappe heatmap in uscita che in ingresso con celle molto più scure rispetto alle repliche, il traffico viene concentrato in tale posizione.

Screenshot della mappa termica affiancata del traffico in uscita e in ingresso che mostra un pod che gestisce la maggior parte del traffico.

Cause comuni:

• Servizio sessionAffinity: ClientIP che associa i client a un pod.
• Servizio headless con risoluzione DNS persistente.
• Hash del servizio di bilanciamento del carico esterno in un campo a cardinalità bassa.

Passaggio 3: Usare la reimpostazione TCP come segnale di saturazione

Aprire i pannelli delle metriche di reimpostazione TCP .

• Mappa termica dell'RST TCP in uscita per pod di origine. Un pod di origine caldo che genera anche RST è sovraccarico — l'applicazione sta chiudendo le connessioni in modo aggressivo.

  

• Mappa termica dell'RST TCP in ingresso per pod di destinazione. Un pod che riceve RST da molte origini significa in genere che non può accettare nuove connessioni abbastanza velocemente (backlog pieno, listener lento).

  

• RST totale in pila per origine/destinazione. Le tendenze nel tempo indicano se le reimpostazioni sono un evento imprevisto o un nuovo stato stabile.

Passaggio 4: Confermare con i log

Identificare i carichi di lavoro più attivi in base al volume di flusso totale. Usare le colonne di conteggio dei flussi aggregate anziché count(), che conta solo le righe aggregate, non i flussi sottostanti:

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

Passaggio 5: Convalidare la correzione

Dopo il ridimensionamento dei carichi di lavoro, il ribilanciamento del servizio o la correzione delle regole di affinità, la mappa termica dovrebbe illuminarsi in modo uniforme tra più pod e la frequenza TCP RST dovrebbe diminuire.

Playbook 4: Monitorare l'integrità della rete a livello di cluster

Usare questa opzione quando è necessaria una visualizzazione della flotta: pianificazione della capacità, dashboard per le chiamate o una rapida verifica dello stato di salute di molti cluster.

Apri Kubernetes / Reti / Cluster.

Segnali da guardare e cosa significano:

Quando si verifica un problema in questo dashboard, passare al playbook corrispondente (Playbook 1 per DNS, Playbook 2 per le gocce, Playbook 3 per i pod ad accesso frequente).

Playbook 5: Diagnosticare gli errori del livello applicativo (L7)

Sintomo. I tassi di errore HTTP 4xx/5xx salgono. Le chiamate gRPC hanno esito negativo. Ritardo dei consumatori Kafka. Disponibile nei cluster Cilium con l'applicazione delle policy L7 abilitata e un CiliumNetworkPolicy elemento che include le regole L7 . Vedere Configurare una policy di livello 7.

Obiettivo. Identificare se gli errori L7 provengono da client non configurati correttamente, errori sul lato server o flussi negati.

Passaggio 1: Aprire il dashboard L7

Usare Kubernetes/Rete/L7 (carico di lavoro) per un singolo servizio o L7 (spazio dei nomi) per un intero tenant.

Passaggio 2: Separare il traffico HTTP scartato da quello inoltrato

Il pannello verdetto suddivide il traffico HTTP in flussi inoltrati e eliminati. Un picco nelle richieste HTTP rifiutate significa di solito che un CiliumNetworkPolicy sta negando la richiesta a livello L7, ad esempio bloccando un percorso o un metodo.

Passaggio 3: Tenere traccia dei codici di stato nel tempo

Il pannello del codice di stato indica se gli errori sono lato client o lato server. Un picco nei 4xx indica un input non valido, token scaduti o percorsi non autorizzati. Un picco di codici di errore 5xx a causa di guasti del back-end.

Passaggio 4: Trovare i pod che causano l'errore

La mappa termica 4xx mostra quali pod di origine generano il maggior numero di richieste fallite. Un singolo pod che emette luce di solito indica un client bloccato in un ciclo di ripetizioni o una replica mal configurata.

Screenshot di una heatmap delle richieste HTTP che restituiscono errori 4xx, raggruppate per pod di origine.

Passaggio 5: Confermare con KQL

Eseguire il pull del traffico HTTP suddiviso in base al codice di stato. Layer7.http.code fa parte della chiave di aggregazione, quindi funziona su righe aggregate:

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

Per gRPC e Kafka, Layer7 contiene il payload specifico del protocollo, ma solo http.code e dns.rcode sono chiavi di aggregazione. Filtrare in base Verdict all'identità del carico di lavoro e usare i log su richiesta quando è necessario il metodo gRPC o l'argomento 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

Su cosa concentrarsi durante L7 RCA

• Volume e forma del traffico. Usare le mappe di calore per trovare uno squilibrio; una replica ad accesso frequente spesso spiega il tasso di errore.
• Tendenza dei codici di stato. 4xx e 5xx focalizzano l'indagine sul lato client o server.
• Verdetto.Flussi L7 scartati indicano che un criterio L7 rifiuta la richiesta. Leggere il criterio e confermare la finalità.

Analisi dettagliata delle funzionalità (quando usare cosa)

Usare questa sezione come riferimento rapido una volta che si conoscono i playbook.

Metriche di rete dei contenitori

• Usare per: rilevamento anomalie, dashboard, avvisi, pianificazione della capacità.
• Ignora per: causa principale che necessita di identificazione (quale pod, quale percorso, quale verdetto).
• Granularità: a livello di nodo in tutti i piani dati; a livello di pod in Linux.
• Carichi di lavoro sensibili ai costi: applica filtri delle metriche nei cluster Cilium per mantenere solo gli spazi dei nomi, le etichette e i tipi di metrica che ti interessano. Il filtraggio avviene prima dello scrape, quindi le serie indesiderate non raggiungono mai Prometheus.

Log di rete dei contenitori (archiviati)

• Usare per: analisi della causa radice, tendenze cronologiche, conformità/controllo.

• Solo piano dati:Cilium. I log archiviati non sono disponibili nei cluster non Cilium.

• Passaggio obbligatorio: definire un ContainerNetworkLog CRD che seleziona il traffico desiderato. Senza di esso, non vengono raccolti log. Vedere Configurare i log di rete dei contenitori.

• Dove atterrano i log: per impostazione predefinita, Cilium scrive i record di flusso in /var/log/acns/hubble/events.log su ogni nodo (buffer rotante di 50 MB). Da qui sono disponibili due percorsi di archiviazione:

  • Log Analytics di Azure (gestito, consigliato): Container Insights inserisce i log nella tabella ContainerNetworkLogs per le query KQL e i dashboard predefiniti del portale di Azure.
  • Bring your own collector: indirizzare un agente compatibile con OpenTelemetry (Splunk, Datadog, Elastic, qualsiasi collector OTel) al percorso dei log dell'host per inoltrare i flussi nel proprio stack di osservabilità esistente anziché, oppure anche, Log Analytics.

• Controllo dei costi: l'aggregazione dei log di flusso comprime flussi simili su una finestra di 30 secondi, mantenendo i modelli durante il taglio del volume. Combinare con narrow includeFilters per ottenere risultati ottimali.

• Visualizzazione: usa i dashboard Flow Logs - Tier Analitico o Flow Logs - Tier Base nei Azure>Insights>Containers>Networking.

  

  

Log di rete dei contenitori (su richiesta)

• Usare per: eventi imprevisti in tempo reale, problemi intermittenti, indagine ad hoc senza modificare la configurazione della raccolta.

• Piano dei dati:Solo Cilium.

• Strumenti: Interfaccia della riga di comando di Hubble per il filtro del terminale; Interfaccia utente hubble per le mappe visive da servizio a servizio.

• Nessuna risorsa di archiviazione permanente, nessun costo aggiuntivo, nessuna configurazione oltre all'abilitazione di ACNS.

  

Filtro delle metriche (cluster Cilium)

Applicare un ContainerNetworkMetric CRD per controllare quali metriche hubble vengono esportate per nodo. Utile quando è necessaria un'ampia osservabilità in alcuni namespace critici, ma non si vuole pagare per le serie di flussi di cardinalità elevata in tutti loro.

Modelli comuni:

• Mantenere DNS ed eliminare le metriche a livello cluster; limitare le metriche del flusso ai namespace di produzione.
• Escludere namespace di sistema con volumi elevati, come kube-system dalle metriche di flusso.
• Definire l'ambito degli spazi dei nomi per tenant in blocchi di filtro personalizzati.

Per esempi CRD completi, vedere Configurare il filtro delle metriche di rete dei contenitori.

Procedure consigliate

• Inizia ampio, poi restringi. Abilitare log e metriche generali per alcuni giorni, esaminare ciò che si usa effettivamente, quindi restringere ContainerNetworkLog e ContainerNetworkMetric filtri.
• Mantenere allineate le finestre temporali delle metriche e del log. Quando si esamina un evento imprevisto, usare la stessa ora di inizio/fine nel dashboard e la query KQL in modo che i segnali siano correlati in modo pulito.
• Preferisce i dashboard predefiniti. Trattano le domande più comuni. I pannelli personalizzati sono in genere necessari solo dopo aver superato la valutazione iniziale.
• Livello ContainerNetworkLogs per necessità. Passare al livello Basic per i carichi di lavoro sensibili ai costi; usare il dashboard di livello Basic corrispondente. Consulta i piani della tabella di Log Analytics.
• Considerare i log aggregati e i log su richiesta come complementi. I log aggregati sono ideali per il rilevamento delle tendenze e dei modelli, ma ignorano i dettagli per flusso. Utilizzare la modalità su richiesta (Hubble) per un'ispezione dettagliata.
• Convalidare le correzioni con lo stesso pannello che ha riscontrato il problema. Se lo stesso pannello diventa piatto dopo la modifica, hai una correzione reale.

Insidie comuni

• Dimenticando il ContainerNetworkLog CRD. L'abilitazione dei log di rete dei container nel cluster non raccoglie alcun dato finché non si applica almeno un CRD che selezioni il traffico.
• Tentativo di utilizzare i registri archiviati per incidenti in tempo reale che si sono già verificati. Se i log non sono stati abilitati prima dell'evento imprevisto o non rientrano nel filtro acquisito, passare ai flussi Hubble su richiesta per l'occorrenza successiva.
• Dashboard L7 vuoti in un cluster Cilium. Le metriche L7 richiedono sia su un cluster --acns-advanced-networkpolicies L7 in un CiliumNetworkPolicy con regole L7. CCNP non supporta le regole L7. Consulta Applicare le politiche L7.
• Metriche DNS vuote in Cilium. La visibilità DNS richiede un CiliumNetworkPolicy con una regola dns (solitamente utilizzato con toFQDNs). Il proxy FQDN/DNS non è compatibile con il DNS locale del nodo o con il DNS locale di AKS — l'esecuzione di uno di essi disabilita il proxy DNS e le metriche risultanti. Vedere Limitazioni del filtro FQDN.
• matchPattern: "*" blocca tutto il DNS. Un carattere jolly semplice non è supportato. Usare un modello con caratteri jolly iniziali, come *.example.com o app*.example.com. Vedere Applicare criteri di filtro FQDN.

Osservazione della rete inclusa in Monitoraggio di Azure

Quando si abilita il servizio gestito di Monitoraggio di Azure per Prometheus in un cluster del servizio Azure Kubernetes, le metriche di monitoraggio della rete dei nodi di base vengono raccolte per impostazione predefinita tramite la destinazione networkobservabilityRetina. In questo modo sono disponibili le opzioni seguenti:

• Metriche di rete di base a livello di nodo: visibilità del traffico di rete essenziale a livello di nodo
• Destinazioni Prometheus predefinite: metriche di osservabilità di rete raschiate automaticamente da Monitoraggio di Azure
• Integrazione di Monitoraggio di Azure: integrazione perfetta con Monitoraggio di Azure; le metriche vengono raccolte automaticamente e possono essere visualizzate in Grafana
• Nessuna configurazione aggiuntiva necessaria: abilitata automaticamente quando è configurato Prometheus gestito da Monitoraggio di Azure
• Supporto tecnico Microsoft: supportato come parte di Monitoraggio di Azure e servizio Azure Kubernetes

Nota: è necessario abilitare il servizio gestito di Monitoraggio di Azure per Prometheus nel cluster del servizio Azure Kubernetes, che potrebbe avere costi associati.

Introduzione: abilitare il servizio gestito di Monitoraggio di Azure per Prometheus nel cluster del servizio Azure Kubernetes tramite il portale di Azure o l'interfaccia della riga di comando. Le metriche di osservabilità della rete verranno raccolte automaticamente e disponibili per la visualizzazione in Grafana con gestione Azure.

Osservabilità di rete con OSS Retina

Anche se i servizi avanzati di rete per contenitori (ACNS) rappresentano un'offerta a pagamento che offre funzionalità complete di osservabilità della rete, Microsoft supporta anche l'osservabilità di rete con OSS Retina, una piattaforma open source di osservabilità di rete che fornisce funzionalità essenziali di monitoraggio della rete.

OSS Retina è la piattaforma open source di osservabilità disponibile in retina.sh e GitHub. Fornisce:

• Osservabilità della rete basata su eBPF: usa tecnologie eBPF per raccogliere informazioni dettagliate con overhead minimo
• Analisi approfondita del traffico con il contesto Kubernetes: acquisizione e analisi completa dei flussi di traffico di rete con integrazione completa di Kubernetes
• Raccolta di metriche avanzate: metriche di livello 4, metriche DNS e funzionalità di acquisizione di pacchetti distribuiti
• Estendibilità basata su plug-in: personalizzare ed estendere le funzionalità tramite un'architettura di plug-in
• Metriche compatibili con Prometheus: esportare metriche di rete complete in formato Prometheus con modalità di metrica configurabili
• Acquisizione di pacchetti distribuiti: acquisizione di pacchetti su richiesta in più nodi per la risoluzione dei problemi più approfondita
• Indipendente dalla piattaforma e dall'interfaccia CNI: funziona con qualsiasi cluster Kubernetes (servizio Azure Kubernetes, abilitato per Arc, locale), qualsiasi sistema operativo (Linux/Windows) e qualsiasi CNI
• Supporto della community: open source con supporto e contributi basati sulla community
• Autogestito: controllo completo sulla distribuzione e sulla configurazione
• Integrazione di Hubble: si integra con Hubble di Cilium per informazioni di rete aggiuntive

Introduzione: distribuire OSS Retina usando grafici Helm o manifesti Kubernetes dal repository Retina ufficiale. Configurare Prometheus e Grafana per visualizzare le metriche, configurare l'analisi approfondita del traffico con il contesto Kubernetes, abilitare l'acquisizione di pacchetti distribuita per la risoluzione dei problemi avanzata e personalizzare le funzionalità usando l'architettura basata su plug-in per casi d'uso specifici.

Confronto delle offerte di osservabilità di rete

Ulteriori informazioni

Advanced Container Networking Services (ACNS)

• Panoramica della piattaforma:Che cos'è Servizi di Rete Avanzata per Container per AKS?
• Configurare l'osservabilità:Configurare l'osservabilità della rete dei contenitori
• Metriche di rete dei contenitori:Panoramica delle metriche di rete del contenitore
• Log di rete dei contenitori:Panoramica dei log di rete del contenitore e Configurare i log di rete dei contenitori
• Filtro delle metriche (Cilium):Configurare il filtro delle metriche di rete dei contenitori

Diagnostica basata sull'intelligenza artificiale

• Agente Container Network Insights (anteprima):Panoramica e Configurazione dell'agente
• Server MCP AKS:Server del protocollo di contesto del modello AKS

Sicurezza di rete dei contenitori (Cilium)

• Filtro FQDN:Concetti e Applica criteri di filtro FQDN
• Criteri di livello 7:Concetti e Applicazione dei criteri L7
• Mutual TLS (Cilium):Concetti e Configurare il Mutual TLS
• Crittografia in transito:Concetti relativi alla crittografia WireGuard

Piano dati e piattaforma

• Azure CNI con tecnologia Cilium:Configurare Azure CNI con tecnologia Cilium
• Prestazioni del routing dell'host eBPF: prestazionidi rete del contenitore con routing dell'host eBPF
• Log Analytics table plans:Scegliere un piano di tabella in base all'utilizzo dei dati

Strumenti open source

• Retina:retina.sh e il repository Microsoft Retina GitHub
• Hubble (progetto Cilium):Documentazione di Hubble