Wat zijn metrische gegevens van het containernetwerk?

Elke pod, service en knooppunt in een Kubernetes-cluster genereert voortdurend netwerkactiviteit: verbindingen die worden geopend, pakketten worden doorgestuurd of verwijderd, DNS-query's worden omgezet of mislukt. Begrijpen dat activiteit essentieel is voor foutopsporing, capaciteitsplanning en het gezond houden van services. Maar de meeste monitoringssystemen schieten op twee manieren tekort.

  • Onvoldoende zichtbaarheid. Aggregaties op knooppuntniveau geven aan dat er iets mis is, maar niet waar. Zonder uitsplitsingen op podniveau die bron- en doelcontext bevatten, betekent het isoleren van een mislukte workload het raden.
  • Te veel gegevens op schaal. Een cluster met honderden microservices kan duizenden metrische tijdreeksen per knooppunt produceren. Als u alles verzamelt, worden de opslagkosten hoger en worden dashboards vertraagd.

Metrische gegevens van containernetwerken in Advanced Container Networking Services voor Azure Kubernetes Service (AKS) pakken beide aan. De functie verzamelt metrische netwerkgegevens op knooppuntniveau en het podniveau op ondersteunde Cilium- en niet-Cilium-gegevensvlakken, op Linux en Windows.

In Cilium-clusters kunt u een stap verder gaan met filteren op bronniveau, waarmee u precies kunt selecteren welke naamruimten, workloads en metrische gegevenstypen worden verzameld voordat gegevens het knooppunt verlaten.

Filteren van metrische gegevens voor containers is een controle voor vooraf opnemen voor waarneembaarheidsgegevens. In plaats van alle beschikbare metrische gegevens te verzamelen en later in dashboards of query's te filteren, definieert u wat u moet verzamelen bij de bron. Hierdoor blijven metrische gegevens van hoge waarde voor de werkbelastingen die u belangrijk vindt, behouden en worden er geen tijdreeksen met een lage waarde of ruis opgenomen.

Het resultaat: bruikbare netwerkobserveerbaarheid op elk ondersteund gegevensvlak, met optionele kostenefficiënte filtering op Cilium.

Metrische gegevens over containernetwerk bieden u uitgebreide zichtbaarheid op workloadniveau voor probleemoplossing en planning, terwijl filteren op bronniveau op Cilium helpt om de waarneembaarheidskosten evenredig te houden met bedrijfskritieke workloads.

Verzameling en filteren in één oogopslag

Gebruik deze tabel om snel te begrijpen waar brede verzameling beschikbaar is en waar fijnmazige filters beschikbaar zijn:

Vermogen Cilium-clusters Niet-Cilium-clusters
Verzameling metrische gegevens op knooppuntniveau ✅ ✅
Verzameling metrische gegevens op podniveau ✅ (Linux) ✅ (Linux)
Filteren op bronniveau: namespace, podlabel en metrictype ✅ ❌
Kostenbeheer door voorafgaande filtering bij inname ✅ ❌

Important

Vanaf 30 november 2025 ondersteunt Azure Kubernetes Service (AKS) geen beveiligingsupdates meer voor Azure Linux 2.0. De installatiekopieën van het Azure Linux 2.0-knooppunt zijn bevroren bij de release 202512.06.0. Vanaf 31 maart 2026 worden knooppuntafbeeldingen verwijderd en kunt u uw knooppoolen niet schalen. Migreer naar een ondersteunde Versie van Azure Linux door uw knooppuntgroepen te upgraden naar een ondersteunde Kubernetes-versie of door te migreren naar osSku AzureLinux3. Zie het Probleem met buitengebruikstelling van GitHub en de aankondiging van de buitengebruikstelling van Azure Updates voor meer informatie. Als u op de hoogte wilt blijven van aankondigingen en updates, volg de AKS-release-opmerkingen.

Belangrijkste voordelen

  • Granulariteit op knooppunt- en podniveau. Houd het verkeersvolume, de dalingspercentages en de verbindingsstatussen bij op knooppuntniveau voor de status van de infrastructuur. Zoom in op afzonderlijke pods met bron- en doellabels om de exacte workload te bepalen die een probleem veroorzaakt.

  • Snellere probleemoplossing. Wanneer een service pakketten laat vallen of DNS-query's mislukken, kunt u met pod-niveau metrische gegevens het probleem isoleren tot een specifieke pod, naamruimte of protocol in seconden, en niet in uren.

  • Flexibele visualisatie. Sla metrische gegevens op in Azure Beheerde Prometheus en visualiseer deze in Azure Managed Grafana (volledig beheerd) of breng uw eigen Prometheus- en Grafana-infrastructuur mee.

  • Schaalbaar per ontwerp. De pijplijn verwerkt grote, dynamische clusters met honderden knooppunten en duizenden pods zonder dat u hoeft te kiezen tussen uitgebreide dekking en beheerbare gegevensvolumes.

  • Gerichte waarneembaarheid (Ciliumclusters). Op Cilium-clusters kunt u met filteren op bronniveau de naamruimten, podlabels of metrische typen definiëren die u belangrijk vindt en alleen deze verzamelen. Geen bijsnijding na verzameling vereist.

  • Lagere opnamekosten voor metrische gegevens (Cilium-clusters). Omdat filteren op de bron op elk knooppunt plaatsvindt, worden ongewenste metrische tijdreeksen nooit geschraapt, verzonden of opgenomen in uw Prometheus-back-end. U betaalt alleen voor de metrische gegevens die u daadwerkelijk nodig hebt. In grote clusters waarin niet-gefilterde verzameling duizenden tijdreeksen per knooppunt kan produceren, kan filteren op bronniveau aanzienlijk verminderen Azure beheerde Prometheus-opname- en opslagkosten.

Hoe werkt het?

Diagram van de containernetwerkobservabiliteitsarchitectuur.

De agentstack op elk knooppunt is afhankelijk van het gegevensvlak, zoals weergegeven in het diagram.

Linux-Cilium-knooppunten maken gebruik van een gelaagde stack op basis van eBPF: eBPF-kernelhook legt onbewerkte verkeersgegevens vast, Cilium verwerkt deze en Hubble maakt het beschikbaar als metrische gegevens van Prometheus-indeling. Omdat Hubble zich tussen het knooppunt en het scrape-eindpunt bevindt, wordt filteren op bronniveau uitgevoerd op deze laag. U selecteert welke naamruimten, podlabels en metrische gegevenstypen worden geëxporteerd voordat gegevens het knooppunt verlaten.

Linux niet-Cilium-knooppunten gebruiken eBPF-kernelhaken die worden ingevoerd in Microsoft Retina, met een Hubble-laag bovenaan voor stroominspectie. Microsoft Retina verwerkt metrische gegevensverzameling en exporteert metrische gegevens op knooppunt- en podniveau in Prometheus-indeling.

Vanuit alle paden worden metrische gegevens in Prometheus-indeling verzameld en opgenomen in Azure Beheerde Prometheus of uw eigen Prometheus-back-end, en vervolgens gevisualiseerd in Azure Beheerde Grafana of uw eigen Grafana-stack.

Om aan de slag te gaan, stelt u metrische gegevens voor het containernetwerk in en configureert u vervolgens het filteren van metrische gegevens voor containernetwerk voor Cilium-clusters.

Wanneer gebruikt u metrische gegevens van containernetwerk

Metrische gegevens van containernetwerk zijn ontworpen voor teams die gerichte, bruikbare netwerkgegevens nodig hebben in plaats van onbewerkte telemetrie. Veelvoorkomende scenario's zijn onder andere:

  • Fouten opsporen in een specifieke workload. Gebruik metrische gegevens op podniveau om pakketuitval, TCP-resets of DNS-fouten voor een bepaalde service te isoleren. Op Cilium-clusters kan filteren de verzameling beperken tot alleen die naamruimte of podlabels, waardoor clusterruis wordt verminderd.
  • Clusters met meerdere tenants bewaken. Houd de netwerkstatus per naamruimte bij, zodat elk team inzicht heeft in zijn eigen verkeerspatronen. Op Cilium-clusters zorgt gerichte filtering ervoor dat de verzameling beperkt blijft tot naamruimten die voor specifieke tenants zijn bestemd.
  • Capaciteitsplanning. Volg doorgestuurde en gedropte byteaantallen per knooppunt om verzadigde verbindingen of onevenwichtige werkbelastingplaatsing te identificeren.
  • DNS-statuscontrole. Identificeer DNS-queryfouten en trage resolutietijden om problemen te signaleren en te voorkomen voordat deze uiteinden in toepassingsfouten resulteren.
  • Kosten voor waarneembaarheid op schaal verminderen. In grote clusters kan niet-gefilterde verzameling duizenden tijdreeksen per knooppunt genereren. Bij Cilium-clusters verwijdert filteren op bronniveau ongewenste reeksen voordat deze worden opgenomen, zodat de kosten afgestemd blijven op de workloads en metrische typen die u kiest.

Kiezen wat u wilt verzamelen (Cilium-clusters)

Gebruik dit implementatiemodel om de zichtbaarheid en kosten te verdelen:

  1. Begin met een brede verzameling in een niet-productienaamruimte om een basislijn tot stand te brengen.
  2. Bewaar metrische gegevens over pakketuitval, DNS en TCP-status voor kritieke naamruimten.
  3. Beperk flow-metrieken met hoge cardinaliteit tot uitsluitend bedrijfskritieke workloads.
  4. Bekijk prometheus-opnametrends en verfijn wekelijks filters.

Met deze aanpak kunt u metrische gegevens van hoge waarde behouden terwijl u de groei en opnamekosten van tijdreeksen beheert.

Voordat u de tabellen met metrische gegevens bekijkt

Houd rekening met deze punten:

  • Metrische gegevens op knooppuntniveau zijn beschikbaar voor ondersteunde Cilium- en niet-Cilium-gegevensvlakken.
  • Metrische gegevens op podniveau zijn beschikbaar in Linux.
  • Filteren op bronniveau is alleen beschikbaar voor Cilium-clusters.
  • Voor Cilium-clusters is voor DNS-metrische gegevens een Cilium FQDN-netwerkbeleid vereist.

Referentie metrische gegevens

Metrische gegevens op knooppuntniveau

Metrische gegevens op knooppuntniveau bieden statistische verkeersstatistieken per knooppunt, doorgestuurde en verwijderde pakketten, byteaantallen en verbindingsstatussen. Deze metrische gegevens worden opgeslagen in prometheus-indeling en kunnen worden gevisualiseerd in Grafana.

De volgende metrische gegevens worden per knooppunt samengevoegd. Alle metrische gegevens bevatten deze labels:

  • cluster
  • instance (knooppuntnaam)

Voor Cilium-gegevensvlakclusters zijn metrische gegevens op knooppuntniveau alleen beschikbaar op Linux. Cilium exposeert de volgende metrieken die worden gebruikt door het containernetwerk:

Naam van meetwaarde Description Extra etiketten Linux Windows
cilium_forward_count_total Totaal aantal doorgestuurde pakketten direction ✅ ❌
cilium_forward_bytes_total Totaal aantal doorgestuurde bytes direction ✅ ❌
cilium_drop_count_total Totaal aantal gedropte pakketten direction, reason ✅ ❌
cilium_drop_bytes_total Totaal aantal verwijderde byte direction, reason ✅ ❌

Metrische gegevens op podniveau (Hubble-metrische gegevens)

Metrische gegevens op podniveau bevatten bron- en doelpodgegevens, zodat u netwerkproblemen op het niveau van de afzonderlijke werkbelasting kunt vaststellen. Deze metrische gegevens hebben betrekking op verkeersvolume, verwijderde pakketten, TCP-resets en Laag 4/Laag 7-stromen.

DNS-metrische gegevens (queryaantallen, antwoordcodes en fouten) worden standaard verzameld op niet-Cilium-gegevensvlakken. Voor Cilium-gegevensvlakken is voor DNS-metrische gegevens een Cilium-FQDN-netwerkbeleid vereist. U kunt ook in realtime problemen met DNS oplossen met behulp van de Hubble CLI.

In de volgende tabel worden de metrische gegevens beschreven die per pod worden geaggregeerd (knooppuntgegevens blijven behouden).

Alle metrische gegevens bevatten labels:

  • cluster

  • instance (knooppuntnaam)

  • source of destination

    • Voor uitgaand verkeer geeft een source label de naamruimte en naam van de bronpod aan.

    • Voor binnenkomend verkeer geeft een destination label de naamruimte en naam van de doelpod aan.

Naam van meetwaarde Description Extra etiketten Linux Windows
hubble_dns_queries_total Totaal aantal DNS-aanvragen per query source of destination, query, qtypes (querytype) ✅ ❌
hubble_dns_responses_total Totaal aantal DNS-antwoorden per query/antwoord source of destination, , query( qtypes querytype), rcode (retourcode), ips_returned (aantal IP-adressen) ✅ ❌
hubble_drop_total Totaal aantal gedropte pakketten sourceof destination, protocolreason ✅ ❌
hubble_tcp_flags_total Totaal aantal TCP-pakketten per vlag source of destination, flag ✅ ❌
hubble_flows_processed_total Totaal aantal verwerkte netwerkstromen (laag 4/laag 7-verkeer) source of destination, protocol, verdict, type, subtype ✅ ❌

Limitations

Platform en gegevensvlak:

  • Metrische gegevens op podniveau zijn alleen beschikbaar in Linux.
  • Het gegevensvlak Cilium wordt ondersteund vanaf Kubernetes versie 1.29.
  • Filteren op metrische gegevens op bronniveau is alleen beschikbaar voor Cilium-clusters.
  • Metrische labels hebben subtiele verschillen tussen Cilium- en niet-Cilium-clusters.

DNS-metrieken:

  • Voor Cilium-clusters is voor DNS-metrische gegevens een Cilium FQDN-netwerkbeleid vereist of kunt u de Hubble CLI gebruiken voor realtime DNS-probleemoplossing.

Bekende problemen:

  • Als een Hubble-knooppuntagent uitvalt, kan de Hubble-relay vastlopen, waardoor Hubble CLI-sessies kunnen worden onderbroken.

FIPS-ondersteuning (alleen niet-Cilium-gegevensvlakken):

  • FIPS is niet beschikbaar op Ubuntu 20.04-knooppunten vanwege kernelbeperkingen. Gebruik in plaats daarvan een Azure Linux-knooppuntgroep. Deze beperking geldt niet voor Cilium-gegevensvlakken. Zie de AKS-probleemtracker voor updates.
besturingssysteem FIPS-ondersteuning
Azure Linux 3.0 Yes
Azure Linux 2.0 Yes
Ubuntu 20.04 No

Scale:

Pricing

Important

Advanced Container Networking Services is een betaald aanbod.

Zie Advanced Container Networking Services - Prijzen voor meer informatie over prijzen.

Verwante inhoud

  • Last updated on