AKS-netwerkproblemen met Advanced Container Networking Services vaststellen en oplossen

Deze handleiding begeleidt u bij het vaststellen en oplossen van echte netwerkproblemen in Azure Kubernetes Service (AKS) met behulp van Advanced Container Networking Services (ACNS). Elk playbook begint met een symptoom (DNS-fouten, pakketuitval, verkeersonbalans, L7-fouten), geeft aan welk signaal u eerst moet controleren en geeft aan wanneer u inzoomt op logboeken.

De handleiding is georganiseerd rond taken, niet functies. Lees het mentale model eenmaal en ga dan rechtstreeks naar het draaiboek dat overeenkomt met uw symptoom.

Wat deze handleiding u helpt oplossen

• DNS-omzettingsfouten in pods (NXDOMAIN, SERVFAILontbrekende antwoorden).
• Pakketuitval veroorzaakt door onjuist geconfigureerd netwerkbeleid, het bijhouden van verbindingen of het verminderen van de connectiviteit.
• Verkeersonbalans tussen pods of naamruimten (hete pods, ongelijke verdeling van belasting).
• L7-toepassingsfouten (HTTP 4xx/5xx, gRPC-fouten, Kafka-druppels).
• Clusterbrede netwerkstatusbewaking en capaciteitsplanning.
• Kostenbeheer voor waarneembaarheid via gerichte metrische gegevens en logboekverzameling.

Mentaal model: hoe metrische gegevens, logboeken en filteren bij elkaar passen

ACNS geeft u drie signalen. Elke vraag beantwoordt een andere vraag.

Zie De metrische gegevens van het containernetwerk, containernetwerklogboeken en het filteren van metrische gegevens configureren voor een uitgebreidere functie.

Standaardstroom voor probleemoplossing

Gebruik deze lus voor elk netwerkincident:

1. Begin in de dashboards voor metrieken. Bevestig de anomalie: een piek in dalingen, fouten, TCP-resets of DNS-fouten. Identificeer het betreffende knooppunt, de naamruimte of de workload.
2. Schakel over naar opgeslagen logboeken. Filter de ContainerNetworkLogs tabel op de naamruimte en het tijdvenster uit stap 1. Logboeken vertellen u het oordeel, de reden, de bron-/doelworkloads en de L7-statuscodes die metrische gegevens niet bevatten.
3. Reproduceer live met logboeken op aanvraag. Als het probleem intermitterend is of al is opgelost in de opgeslagen gegevens, gebruik dan de Hubble CLI of Hubble UI om livestromen voor die workload te captureren.
4. Valideer de oplossing. Controleer hetzelfde deelvenster met metrische gegevens opnieuw en voer dezelfde KQL-query opnieuw uit. De anomalie moet weg zijn.
5. Muziekverzameling Als u tijdens het incident te veel hebt verzameld, beperkt u uw ContainerNetworkLog CRD of past u een ContainerNetworkMetric filter toe, zodat u alleen vastlegt wat u nodig hebt.

Ingebouwde dashboards in één oogopslag

Stel dit één keer in met Container Network Observability instellen. U verwijst ernaar in de playbooks.

Playbook 1: DNS-omzettingsfouten vaststellen

Symptoom. Pods loggen fouten zoals DNS_PROBE_FINISHED_NXDOMAIN, SERVFAIL, of dat ze vastlopen tijdens het oplossen van servicenamen.

Doel. Bepaal of de fout zich voordoet bij de upstream (CoreDNS of externe resolver), door het beleid (FQDN blokkeren), of workloadspecifiek is.

Stap 1: De anomalie in dns-metrische gegevens bevestigen

Open het DNS-dashboard (cluster). Zoek naar plotselinge wijzigingen in het aanvraagvolume, het antwoordvolume of aanvragen die geen antwoord hebben %. In de samenvattingsvensters worden de meest voorkomende query's, de meest voorkomende antwoordcodes en de knooppunten weergegeven die de meeste fouten genereren.

Waar moet u naar zoeken: Een aanhoudende toename van foutreacties, een daling van geslaagde antwoorden of een enkel knooppunt dat het aantal fouten overneemt. Noteer de tijdstempel van de anomalie.

Stap 2: De pods met de meeste geluidsoverlast identificeren

Schuif omlaag op hetzelfde dashboard naar het deelvenster dat pods rangschikt op DNS-fouten in alle naamruimten. De bovenste vermeldingen zijn uw vermoedelijke verdachten.

Beslissingspunt.

• Als er fouten zijn geconcentreerd in CoreDNS-pods, gaat u naar het DNS (Werkload)-dashboard met kube-system / coredns geselecteerd: CoreDNS zelf of zijn upstream-resolver is het probleem.
• Als fouten zijn geconcentreerd in een applicatieworkload, genereert die workload foute query's of wordt door een FQDN-beleid geweigerd.

Stap 3: De betrokken workload nader onderzoeken

Open het DNS-dashboard (Workload) voor de werkbelasting die u hebt geïdentificeerd.

• DNS-aanvragen/DNS-antwoordenpanels. Een hoog ontbrekende responsen % van aanvragen duidt op upstream time-outs of overbelasting van query's.

  

• DNS-fouten per type. Koppel de piek aan een code:

  • NXDOMAIN — onjuiste of verouderde domeinnaam in app-configuratie.
  • SERVFAIL — upstream-oplossingsprobleem.
  • Query geweigerd : FQDN-beleid of DNS-configuratie komt niet overeen.

  

• DNS-antwoord-IP-adressen geretourneerd. Bevestigt een geslaagde oplossingsfrequentie. Een daling betekent meestal dat CoreDNS de upstream niet kan bereiken; een plotselinge piek kan duiden op een query-storm.

• DNS-antwoordtabel. Gebruik dit om patronen te herkennen, zoals 'A records mislukken, maar AAAA-records slagen', wat meestal verwijst naar een stack die onjuist is geconfigureerd voor IPv4-omgevingen.

  

Stap 4: Bevestigen met opgeslagen logboeken

Voer deze KQL-query uit in uw Log Analytics werkruimte om DNS-foutpatronen weer te geven. Samengevoegde rijen behouden Verdict, naamruimten, workloads en Layer7.dns.rcode, zodat deze query werkt op basis van de standaardtabel (geaggregeerd 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

Vervang <start-time> en <end-time> door tijdstempels in de notatie 2026-04-30T15:00:00Z.

Wat u moet controleren in de resultaten:

• Oordeel. DROPPED betekent dat een FQDN- of netwerkbeleid de query blokkeert. FORWARDED met een niet-NOERRORDnsRcode, bijvoorbeeld NXDOMAIN of SERVFAIL, betekent dat de upstream-resolver een fout heeft geretourneerd.
• Bron- en doelwerkbelastingen. Controleer of verkeer naar de verwachte CoreDNS-workload gaat.
• DnsRcode. De DNS-antwoordcode identificeert in één oogopslag de foutmodus.

U kunt dezelfde stromen ook visualiseren in de Azure-portal onder AKS-cluster>Insights>Networking>Stroomlogboeken.

Stap 5: Reproduceer live als het probleem af en toe optreedt

Als de piek al voorbij is en u deze niet kunt vastleggen in opgeslagen logboeken, gebruik dan de Hubble CLI op aanvraag.

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

Stap 6: De oplossing valideren

Nadat u het FQDN-beleid hebt bijgewerkt, moet u het DNS-dashboard (Workload) opnieuw openen om de configuratie van de toepassing te herstellen of CoreDNS te schalen. De foutsnelheid moet binnen een paar minuten dalen. Voer de KQL-query opnieuw uit voor hetzelfde tijdvenster om te bevestigen dat de mislukte query's zijn verdwenen.

Playbook 2: Pakketverlies onderzoeken

Symptoom. Services kunnen elkaar niet bereiken. Tests mislukken. Verbindingen verlopen. Drop counters stijgen in dashboards.

Doel. Bepaal of dalingen worden veroorzaakt door netwerkbeleid, uitputting van verbindingen of problemen met upstream-connectiviteit, en welke werkbelasting verantwoordelijk is.

Stap 1: Zoek de dalingen op het niveau van de naamruimte

Open Pod Flows (Namespace). De heatmaps laten namespaces en pods zien met de hoogste uitgaande en binnenkomende pakkettenverliespercentages.

Helderdere cellen geven hogere dalingspercentages aan. Noteer de naamruimte en het tijdvenster.

Stap 2: Inzoomen op de betrokken workload

Open Drops (werkbelasting) en selecteer de werkbelasting die u hebt geïdentificeerd.

• Momentopname van workload toont maximale/minimale uitgaande pakketverliezen per seconde. Gebruik het om de ernst te meten.

  

• Verwijderd verkeer per reden is het belangrijkste deelvenster. De reden geeft aan wat u moet oplossen:

  • Beleid geweigerd : een NetworkPolicy of CiliumNetworkPolicy blokkeert het verkeer.
  • CT: Kaartinvoeging is mislukt — de verbindingstraceringstabel is vol; knooppunt schalen of het verbindingsomzet verminderen.
  • Niet-ondersteund L3-protocol / Ongeldig pakket — toepassing of proxy verzendt onjuist verkeer.

  

• Heatmap van binnenkomende/uitgaande dalingen. Hiermee wordt aangegeven welke specifieke podparen verkeer verliezen.

  

• Gestapeld totaal aantal druppels per bronpod. Rangschikt de daders zodat u weet welke replica u eerst moet bekijken.

  

Stap 3: Bevestig de vervallen verkeersstromen in de opgeslagen logboeken

Zoek de exacte bron- en doelworkloads van het verwijderde verkeer. Verdict, DropReason, naamruimten en workloads bevinden zich allemaal in de aggregatiesleutel, dus deze query werkt op geaggregeerde gegevens:

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

Vermalen tot één naamruimte nadat u deze hebt geïdentificeerd:

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

In het dashboard Stroomlogboeken in de Azure-portal worden dezelfde gegevens visueel weergegeven, inclusief een grafiek voor serviceafhankelijkheid waarin geblokkeerde paden worden gemarkeerd.

Stap 4: Verifiëren met beleidsrichtlijnen

Zodra u de bronpod en doelpod kent:

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

De mislukte stroom vergelijken met regels voor inkomend/uitgaand verkeer. De meest voorkomende oorzaak is een standaard-ontkenningsbeleid dat is toegevoegd zonder een toestemmingsregel voor een legitiem pad.

Stap 5: De oplossing valideren

Nadat u het beleid hebt aangepast, moet de Dropped Traffic by Reason grafiek plat zijn voor beleid geweigerd. Voer de KQL-query opnieuw uit — DROPPED er moeten geen resultaten meer worden weergegeven voor dat bron/doelpaar.

Playbook 3: Verkeersonbalansen en hot pods zoeken

Symptoom. Een paar pods van een Deployment zijn het CPU of netwerk aan het verzadigen terwijl anderen inactief zijn. TCP herstelt klim. Latentierapporten zijn afkomstig van gebruikers (latentie zelf is niet zichtbaar in metrische ACNS-gegevens, zie de opmerking in het mentale model).

Doel. Bepaal welke pods onevenredig verkeer dragen en of resets duiden op overbelasting of onjuist geconfigureerde taakverdeling.

Stap 1: Verkeer op podniveau vergelijken

Podstromen (Workload) openen. De momentopname van de workload bevat een overzicht van uitgaand/binnenkomend verkeer en dalingen.

In het venster 'Verkeer per traceringstype' wordt de verkeersvorm in de loop van de tijd weergegeven. Een brede kloof tussen uitgaand en binnenkomend volume verwijst vaak naar een downstreamknelpunt.

Stap 2: Identificeer warme pods met warmtekaarten

De heatmaps op podniveau maken onbalans duidelijk. Als één pod (bijvoorbeeld default/tcp-client-0) wordt weergegeven in zowel de uitgaande als binnenkomende heatmaps met veel donkerdere cellen dan de replica's, is het verkeer daar geconcentreerd.

Veelvoorkomende oorzaken:

• Service sessionAffinity: ClientIP die clients aan één pod bindt.
• Headless service met permanente DNS-resolutie.
• Externe load balancer-hashing op een veld met lage kardinaliteit.

Stap 3: TCP-resets gebruiken als een verzadigingssignaal

Open de TCP-resetstatistiekenpanelen.

• Heatmap van uitgaande TCP RST per bronpod. Een dynamische bronpod die ook RST's genereert, wordt overbelast. De toepassing sluit verbindingen agressief.

  

• Heatmap van binnenkomende TCP RST per doelpod. Een pod die RST's van veel bronnen ontvangt, betekent meestal dat nieuwe verbindingen niet snel genoeg kunnen worden geaccepteerd (achterstand vol, listener traag).

  

• Gestapeld totaal RST per bron/doel. Trends in de loop van de tijd geven aan of resets een incident of een nieuwe stabiele status zijn.

Stap 4: Bevestigen met logboeken

Identificeer de drukste werklasten door het totale stroomvolume. Gebruik de kolommen met het samengevoegde aantal stromen in plaats count()van , waarmee alleen geaggregeerde rijen worden geteld, niet de onderliggende stromen:

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

Stap 5: De oplossing valideren

Na het schalen van de workload, het opnieuw verdelen van de service of het herstellen van affiniteitsregels, moet de heatmap gelijkmatig over meer pods worden verlicht en moet de TCP RST-snelheid dalen.

Playbook 4: Netwerkstatus voor het hele cluster bewaken

Gebruik dit wanneer u een vlootweergave nodig hebt: capaciteitsplanning, dashboards aanroepen of een snelle statuscontrole in veel clusters.

Open Kubernetes/Netwerken/Clusters.

Signalen om te kijken en wat ze betekenen:

Als er iets op dit dashboard verkeerd uitziet, gaat u naar het overeenkomende playbook (Playbook 1 voor DNS, Playbook 2 voor druppels, Playbook 3 voor hot pods).

Playbook 5: Fouten in de toepassingslaag (L7) vaststellen

Symptoom. HTTP 4xx/5xx foutpercentages stijgen. gRPC-aanroepen mislukken. Kafka-consumentenachterstand. Beschikbaar voor Cilium-clusters waarvoor het afdwingen van L7-beleid is ingeschakeld en die CiliumNetworkPolicy L7-regels bevat . Zie Een laag 7-beleid configureren.

Doel. Bepaal of L7-fouten afkomstig zijn van onjuist geconfigureerde clients, fouten aan de serverzijde of geweigerde stromen.

Stap 1: Het L7-dashboard openen

Gebruik Kubernetes/Netwerken/L7 (workload) voor één service of L7 (naamruimte) voor een hele tenant.

Stap 2: Verworpen versus doorgestuurd HTTP-verkeer onderscheiden

In het verdictvenster wordt HTTP-verkeer gesplitst in doorgestuurde en verwijderde stromen. Een piek in verwijderde HTTP betekent meestal dat een CiliumNetworkPolicy de aanvraag op L7 weigert (bijvoorbeeld een pad of methode blokkeren).

Stap 3: Statuscodes bijhouden in de loop van de tijd

In het deelvenster statuscode wordt aangegeven of fouten client- of serverzijde zijn. Een piek in 4xx verwijst naar ongeldige invoer, verlopen tokens of geweigerde paden. Een piek in 5xx punten bij back-endfouten.

Stap 4: De probleemgevend/ storende pods zoeken

In de heatmap 4xx ziet u welke bronpods de meest mislukte aanvragen genereren. Een enkele pod die helder gloeit, betekent meestal een vastgelopen lus voor opnieuw proberen van de client of een onjuist geconfigureerde replica.

Stap 5: Bevestigen met KQL

HTTP-verkeer ophalen en uitsplitsen per statuscode. Layer7.http.code maakt deel uit van de aggregatiesleutel, dus dit werkt op basis van geaggregeerde rijen:

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

Voor gRPC en Kafka wordt de protocolspecifieke lading Layer7 meegestuurd, alleen http.code en dns.rcode zijn aggregatiesleutels. Filter op Verdict en de workloadidentiteit en gebruik logboeken op aanvraag wanneer u de gRPC-methode of het Kafka-onderwerp nodig hebt:

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

Waar moet u zich op richten tijdens L7 RCA

• Verkeersvolume en -vorm. Gebruik heatmaps om onevenwichtigheid te vinden; in één dynamische replica wordt vaak de foutfrequentie uitgelegd.
• Trend van statuscode. 4xx versus 5xx beperkt het onderzoek naar de client- of serverzijde.
• Oordeel.Afgewezen L7-stromen betekenen dat een L7-beleid de aanvraag weigert. Lees het beleid en bevestig de bedoeling ervan.

Diepgaande functieverkenning (wanneer te gebruiken)

Gebruik dit gedeelte als snelle referentie zodra u de playbooks kent.

Metrische gegevens van containernetwerk

• Gebruik voor: anomaliedetectie, dashboards, waarschuwingen, capaciteitsplanning.
• Overslaan voor: oorzaak die identificatie nodig heeft (welke pod, welk pad, welk besluit).
• Granulariteit: knooppuntniveau op alle gegevensvlakken; pod-niveau op Linux.
• Kostengevoelige workloads: pas filters voor metrische gegevens toe op Cilium-clusters om alleen de naamruimten, labels en metrische gegevenstypen te behouden die u belangrijk vindt. Filteren vindt plaats voor scrape, dus ongewenste reeksen bereiken Nooit Prometheus.

Containernetwerklogboeken (opgeslagen)

• Gebruik voor: hoofdoorzaakanalyse, historische trends, naleving/controle.

• Alleen gegevensvlak:Cilium. Opgeslagen logboeken zijn niet beschikbaar op niet-Cilium-clusters.

• Verplichte stap: definieer een ContainerNetworkLog CRD die het gewenste verkeer selecteert. Zonder dit worden er geen logboeken verzameld. Zie Netwerklogboeken voor containers instellen.

• Waar logboeken terechtkomen: Cilium schrijft standaard stroomrecords naar /var/log/acns/hubble/events.log elk knooppunt (50 MB roterende buffer). Van daaruit hebt u twee opslagpaden:

  • nl-NL: Azure Log Analytics (beheerd, aanbevolen): Container Insights verzendt logboeken naar de ContainerNetworkLogs-tabel voor KQL-query's en geïntegreerde Azure portaldashboards.
  • Bring your own collector — wijs een met OpenTelemetry compatibele agent (Splunk, Datadog, Elastic, elke OTel-collector) aan op het hostlogboekpad om stromen door te sturen naar uw bestaande waarneembaarheidsstack in plaats van of naast Log Analytics.

• Kostenbeheer: met aggregatie van stroomlogboeken worden vergelijkbare stromen samengevouwen in een venster van 30 seconden, waarbij patronen behouden blijven terwijl het volume wordt geknipt. Combineer met smal includeFilters voor de beste resultaten.

• Visualization: kunt u de Flow Logs - Analytics Tier of Flow Logs - Basic Tier dashboards gebruiken onder Azure>Insights>Containers>Networking.

  

  

Containernetwerklogboeken (op aanvraag)

• Gebruik voor: live-incidenten, onregelmatige problemen, ad-hoc onderzoek zonder de configuratie van de verzameling te wijzigen.

• Gegevensvlak:alleen Cilium.

• Tools: Hubble CLI voor terminalfiltering; Hubble UI voor visuele service-naar-service-kaarten.

• Geen permanente opslag, geen extra kosten, geen installatie buiten het inschakelen van ACNS.

  

Filteren van metrische gegevens (Ciliumclusters)

Pas een ContainerNetworkMetric CRD toe om te bepalen welke Hubble-metrische gegevens per knooppunt worden geëxporteerd. Dit is handig wanneer u brede waarneembaarheid nodig hebt voor een paar kritieke naamruimten, maar niet wilt betalen voor reeksen met hoge kardinaliteitsstromen in al deze.

Algemene patronen:

• Dns behouden en metrische gegevens over het hele cluster verwijderen; metrische stroomgegevens beperken tot productienaamruimten.
• Sluit systeemnaamruimten met een hoog volume uit, zoals kube-system van metrische stroomgegevens.
• Beperk tenant-naamruimtes tot hun eigen filterblokken.

Zie voor volledige CRD-voorbeelden Configureer het filteren van metrische gegevens voor het containernetwerk.

Beste praktijken

• Begin breed en werk dan naar detail. Schakel een paar dagen brede logboeken/metrische gegevens in, bekijk wat u daadwerkelijk gebruikt, en verscherp vervolgens ContainerNetworkLog en ContainerNetworkMetric filters.
• Houd de tijdvensters voor metrische gegevens en logboeken uitgelijnd. Wanneer u een incident onderzoekt, gebruikt u dezelfde begin- en eindtijd in het dashboard en de KQL-query, zodat signalen op een schone manier correleren.
• Geef de voorkeur aan de vooraf gebouwde dashboards. Ze hebben betrekking op de meest voorkomende vragen. Aangepaste panelen zijn meestal alleen nodig zodra u de eerste sortering hebt verstreken.
• Rangschikken ContainerNetworkLogs op basis van behoefte. Overschakelen naar de Basic-laag voor kostengevoelige workloads; gebruik het overeenkomende dashboard voor de Basic-laag. Zie Log Analytics tabellen.
• Behandel geaggregeerde logboeken en logboeken op aanvraag als aanvullingen. Geaggregeerde logboeken zijn ideaal voor trend- en patroondetectie, maar sla details per stroom over. Gebruik on demand (Hubble) voor fijnmazige inspectie.
• Valideer oplossingen met hetzelfde paneel dat het probleem heeft gemeld. Als hetzelfde paneel vlak is na uw wijziging, hebt u een echte oplossing.

Veelvoorkomende valkuilen

• Vergeet de ContainerNetworkLog CRD. Het inschakelen van containernetwerklogboeken in het cluster verzamelt niets totdat u ten minste één CRD toepast die verkeer selecteert.
• Probeert opgeslagen logboeken te gebruiken voor live-incidenten die al voorbij zijn. Als logboeken niet zijn ingeschakeld vóór het incident of buiten het vastgelegde filter vallen, schakelt u over naar Hubble-stromen op aanvraag voor het volgende exemplaar.
• L7-dashboards leeg op een Cilium-cluster. L7-metrische gegevens vereisen zowel --acns-advanced-networkpolicies L7 op het cluster als een CiliumNetworkPolicy met L7-regels. CCNP biedt geen ondersteuning voor L7-regels. Zie L7-beleid toepassen.
• DNS-metrieken leeg op Cilium. Voor DNS-zichtbaarheid is een CiliumNetworkPolicy met een dns-regel vereist (meestal naast toFQDNs). FQDN/ DNS-proxy is niet compatibel met knooppunt-lokale DNS of AKS Lokale DNS. Het uitvoeren van een van beide schakelt DNS-proxying en de resulterende metrische gegevens uit. Zie beperkingen voor FQDN-filtering.
• matchPattern: "*" blokkeert alle DNS. Een bare wildcard wordt niet ondersteund. Gebruik een wildcard-patroon met voorloopteken zoals *.example.com of app*.example.com. Zie FQDN-filterbeleid toepassen.

Netwerkobserveerbaarheid opgenomen in Azure Monitoring

Wanneer u de beheerde Azure Monitor-service voor Prometheus inschakelt op een AKS-cluster, worden de metrische gegevens voor basisknooppuntnetwerkbewaking standaard verzameld via het networkobservabilityRetina doel. Dit biedt:

• Metrische netwerkgegevens op basisniveau op knooppuntniveau: Essentiële zichtbaarheid van netwerkverkeer op knooppuntniveau
• Standaard Prometheus-doelen: metrische gegevens voor netwerkobservabiliteit worden automatisch gesroot door Azure Monitor
• Azure Monitor-integratie: naadloze integratie met Azure Monitor; metrische gegevens worden automatisch verzameld en kunnen worden gevisualiseerd in Grafana
• Er is geen extra installatie vereist: automatisch ingeschakeld wanneer Azure Monitor beheerde Prometheus is geconfigureerd
• Microsoft-ondersteuning: ondersteund als onderdeel van Azure Monitor en AKS

Opmerking: Hiervoor moet de beheerde Azure Monitor-service voor Prometheus zijn ingeschakeld op uw AKS-cluster, waarvoor mogelijk kosten zijn verbonden.

Aan de slag: Schakel de beheerde Azure Monitor-service in voor Prometheus op uw AKS-cluster via Azure Portal of CLI. Metrische gegevens over netwerkobserveerbaarheid worden automatisch verzameld en beschikbaar voor visualisatie in Azure Managed Grafana.

Netwerkobserveerbaarheid met Retina OSS

Hoewel Advanced Container Networking Services (ACNS) een betaald aanbod is dat uitgebreide mogelijkheden voor netwerkobservabiliteit biedt, biedt Microsoft ook ondersteuning voor netwerkobserveerbaarheid met Retina OSS, een opensource-platform voor waarneembaarheid van netwerken dat essentiële mogelijkheden voor netwerkbewaking biedt.

Retina OSS is het opensource-waarneembaarheidsplatform dat beschikbaar is op retina.sh en GitHub. Het biedt:

• Op eBPF gebaseerde netwerkobserveerbaarheid: maakt gebruik van eBPF-technologieën om inzichten te verzamelen met minimale overhead
• Uitgebreide verkeersanalyse met Kubernetes-context: Uitgebreide opname en analyse van netwerkverkeersstromen met volledige Kubernetes-integratie
• Geavanceerde verzameling metrische gegevens: Metrische gegevens van laag 4, DNS-metrische gegevens en mogelijkheden voor gedistribueerde pakketopname
• Uitbreidbaarheid op basis van invoegtoepassingen: functionaliteit aanpassen en uitbreiden via een invoegtoepassingsarchitectuur
• Met Prometheus compatibele metrische gegevens: uitgebreide netwerkmetrieken exporteren in Prometheus-indeling met configureerbare metrische modi
• Gedistribueerde pakketopname: pakketopnamen op aanvraag op meerdere knooppunten voor uitgebreide probleemoplossing
• Platform- en CNI-agnostisch: werkt met elk Kubernetes-cluster (AKS, arc, on-premises), elk besturingssysteem (Linux/Windows) en eventuele CNI's
• Communityondersteuning: Opensource met communitygestuurde ondersteuning en bijdragen
• Zelfbeheerd: Volledige controle over implementatie en configuratie
• Hubble-integratie: integreert met hubble van Cilium voor aanvullende netwerkinzichten

Aan de slag: Implementeer Retina OSS met Helm-grafieken of Kubernetes-manifesten vanuit de officiële Retina-opslagplaats. Stel Prometheus en Grafana in om metrische gegevens te visualiseren, configureer deep traffic analysis met Kubernetes-context, schakel gedistribueerde pakketopname in voor geavanceerde probleemoplossing en pas functionaliteit aan met behulp van de architectuur op basis van de invoegtoepassing voor specifieke use cases.

Vergelijking van netwerkobserveerbaarheidsaanbiedingen

Meer informatie

Advanced Container Networking Services (ACNS)

• Platformoverzicht:Wat is Advanced Container Networking Services voor AKS?
• Waarneembaarheid instellen:Waarneembaarheidvan containernetwerk instellen
• Overzicht van metrische gegevens van containernetwerk:Overzicht van metrische gegevens van containernetwerk
• Containernetwerklogboeken:Overzicht van containernetwerklogboeken en containernetwerklogboeken instellen
• Filteren van metrische gegevens (Cilium):Filteren van metrische gegevens voor containernetwerk configureren

Diagnostische gegevens op basis van AI

• Container Network Insights-agent (preview):Overzicht en de agent instellen
• AKS MCP-server:AKS Model Context Protocol-server

Container Network Security (Cilium)

• FQDN-filtering:Concepten en FQDN-filterbeleid toepassen
• Laag 7-beleid:Concepten en L7-beleid toepassen
• Wederzijdse TLS (Cilium):Concepten en wederzijdse TLS configureren
• In-transit-versleuteling:WireGuard-versleutelingsconcepten

Gegevensvlak en -platform

• Azure CNI powered by Cilium:Configure Azure CNI powered by Cilium
• Routeringsprestaties van eBPF-host: Netwerkprestatiesvan containers met eBPF-hostroutering
• Log Analytics tabelplannen:Keuze van een tabelplan op basis van gegevensgebruik

Opensource-hulpprogramma's

• Retina:retina.sh en de opslagplaats Microsoft Retina GitHub
• Hubble (Cilium-project):Hubble-documentatie