CNI-Observability: Pflicht-Metriken

CNI-Observability: Pflicht-Metriken ist in Kubernetes-Umgebungen der Unterschied zwischen „wir raten“ und „wir wissen“, warum Netzwerkprobleme auftreten. Viele Incidents wirken zunächst wie Applikationsfehler: Timeouts, sporadische Retries, DNS-Flakiness, unerklärliche 5xx oder stark schwankende Latenzen. In Wirklichkeit entstehen sie häufig in der Netzwerkschicht: Drops durch Policy, MTU-Mismatch, überfüllte Conntrack-Tabellen, überlastete CNI-Daemons, Node-spezifische Routing-Probleme oder ein CNI-Datapath, der unter Last anders reagiert als im Normalbetrieb. Ohne saubere Metriken endet die Analyse meist bei „kann alles sein“ – und Maßnahmen werden zu riskanten Änderungen an Firewalls, NetworkPolicies oder Load-Balancern. CNI-Observability bedeutet dabei nicht „möglichst viele Dashboards“, sondern wenige, belastbare Pflicht-Metriken, die früh signalisieren, was gerade kippt: Datenpfad vs. Control Plane, Netzwerkverlust vs. Überlast, DNS vs. Service-Routing, Node-spezifisch vs. clusterweit. Dieser Artikel beschreibt praxisnah, welche Metriken in einer produktiven CNI-Observability nicht fehlen dürfen, wie Sie sie sinnvoll gruppieren, welche Labels/Dimensionen entscheidend sind und wie Sie aus Metriken konkrete Handlungsschritte ableiten – ohne in Monitoring-Lärm zu ertrinken.

Was unter „CNI-Observability“ wirklich fällt

Im Kubernetes-Kontext umfasst „CNI“ mehr als das CNI-Plugin an sich. Je nach Stack gehören dazu:

• Datapath: iptables/ipvs, eBPF-Programme, Tunnel (VXLAN/Geneve/IP-in-IP), Routing (BGP), Node-Firewall.
• Control Plane/Agenten: CNI-Daemonsets (z. B. calico-node, cilium-agent), Controller, IPAM, Policy-Compiler.
• Kubernetes-Komponenten mit Netzbezug: kube-proxy (falls genutzt), CoreDNS, ggf. Ingress/Gateway-Controller.
• Kernel-Subsysteme: Conntrack, Neighbor Table (ARP/NDP), NIC-Queues, Offloading, Socket-Queues.

„Pflicht-Metriken“ sollten deshalb nicht nur CNI-spezifische Counter sein, sondern ein Minimum an Signalen aus diesen Schichten, die zusammen ein vollständiges Bild ergeben.

Prinzipien: Wie Pflicht-Metriken ausgewählt werden sollten

Bevor Sie Metriken sammeln, definieren Sie, wofür sie genutzt werden. In der Praxis haben Pflicht-Metriken drei Aufgaben: frühes Erkennen, schnelle Eingrenzung und sichere Mitigation.

• Frühwarnung: Signale, die vor Nutzerimpact kippen (z. B. Drop-Rate, Conntrack-Pressure, DNS-Latenz).
• Lokalisierung: Erkennen, ob ein Problem node-spezifisch, zonal oder clusterweit ist.
• Ursachentrennung: Datapath vs. Control Plane (Policy-Programmierung vs. Paketverarbeitung).

Ein gutes Pflicht-Metrik-Set ist klein genug, um im Incident lesbar zu sein, und reich genug, um nicht im Nebel zu enden. Als konzeptioneller Hintergrund zu Kubernetes-Netzwerkpfaden ist diese Übersicht hilfreich: Kubernetes Networking Concepts.

Pflicht-Metriken Gruppe 1: Paketverlust und Drops im Datapath

Wenn Sie nur eine Kategorie konsequent messen, dann Drops. Drops sind das härteste Signal, dass Pakete nicht dort ankommen, wo sie sollen. In Kubernetes treten Drops häufig nicht auf „der Leitung“ auf, sondern durch Policy, Conntrack oder Ressourcenengpässe.

• Drop-Count nach Richtung: Ingress vs. Egress, möglichst pro Node und idealerweise pro Interface/Datapath-Hook.
• Drop-Rate: Drops pro Sekunde relativ zur Paketrate (damit Lastspitzen nicht falsch interpretiert werden).
• Drop-Reason: wenn verfügbar, kategorisieren (Policy deny, invalid state, no route, MTU/fragment, CT drop).
• Retransmits-Indikatoren: TCP-Retransmits als indirektes Signal für Verlust oder starke Jitter/Queueing.

Warum das Pflicht ist: Viele „sporadische“ Incidents sind eigentlich wenige Prozent Drops – genug für Timeouts und Retries, aber zu wenig, um auf Durchsatzgrafiken sichtbar zu sein.

Pflicht-Metriken Gruppe 2: Conntrack-Pressure und NAT-Kapazität

Conntrack ist in vielen Kubernetes-Setups ein limitierender Faktor, insbesondere bei SNAT/Masquerade und bei vielen kurzlebigen Outbound-Verbindungen (Image Pulls, externe APIs, DNS, Telemetrie). Wenn Conntrack kippt, sehen Sie häufig Timeouts ohne klare Ursache.

• Conntrack-Einträge aktuell: Anzahl der aktiven Einträge pro Node.
• Conntrack-Limit und Auslastung: Verhältnis „current / max“ als Prozentwert.
• Conntrack-Drops: Drops, weil keine Einträge mehr angelegt werden können oder Tabellen überlaufen.
• NAT-Port-Pressure (falls ableitbar): Indikatoren für Ephemeral-Port-Exhaustion bzw. hohe SNAT-Portnutzung.

Als einfache Daumenregel ist nicht der absolute Wert entscheidend, sondern die Nähe zum Limit und die Änderungsrate. Ein stabiles System hält ausreichend Abstand, besonders während Deployments und HPA-Scale-outs.

Ein einfaches Verhältnis als Alarmanker

Ein gut verständlicher KPI ist die Conntrack-Auslastung:

$\mathrm{ConntrackAuslastung}=\frac{\mathrm{ConntrackAktuell}}{\mathrm{ConntrackMax}}$

In der Praxis sind Alarme oft sinnvoll, bevor 1,0 erreicht wird, weil kurze Bursts sonst sofort ins Limit laufen.

Pflicht-Metriken Gruppe 3: Policy-Impact und Policy-Durchsetzung

NetworkPolicies oder CNI-spezifische Policies sind eine häufige Ursache für blockierten Traffic – aber die „Blockade“ ist ohne Metriken schwer zu beweisen. Pflicht ist daher eine messbare Sicht auf Policy-Drops und Policy-Programmierung.

• Policy-Drops (Count/Rate): wie viele Pakete/Flows werden durch Policy verworfen.
• Top Talkers der Denies: welche Quell-/Zielpaare sind am stärksten betroffen (soweit datenschutzkonform).
• Policy-Update-Latenz: Zeit von Policy-Änderung bis tatsächlicher Durchsetzung auf Nodes.
• Policy-Compile/Apply-Fehler: Fehler beim Rendern/Installieren von Regeln, inklusive Retries.

Das Ziel ist nicht, jedes Paket zu erklären, sondern den Unterschied zu erkennen zwischen „Policy blockt“ und „Netzwerk verliert“. Grundlagen zu Kubernetes NetworkPolicies: Kubernetes Network Policies.

Pflicht-Metriken Gruppe 4: Service-Routing und kube-proxy/eBPF-Gesundheit

Viele Produktionsfehler entstehen im Service-Pfad: VIP → Endpoint-Translation, NAT und Load Balancing. Je nach Stack passiert das über kube-proxy (iptables/ipvs) oder eBPF-Mechanismen im CNI. Pflicht-Metriken in diesem Bereich helfen, Service-Probleme von Applikationsproblemen zu trennen.

• Service-Translation-Fehler: z. B. fehlende Endpoints, inkonsistente Regeln, Update-Errors.
• Load-Balancing-Verteilung: ob Requests/Flows gleichmäßig über Endpoints gehen oder Hotspots entstehen.
• Healthchecks/Endpoint-Flaps: häufiges Hinzufügen/Entfernen von Endpoints als Instabilitätsindikator.
• Node-spezifische Abweichungen: gleiche Services, aber andere Fehler-/Latenzraten pro Node.

Referenz zu kube-proxy (falls im Einsatz): kube-proxy Referenz.

Pflicht-Metriken Gruppe 5: DNS als „Netzwerk-Multiplikator“

DNS ist in Kubernetes nicht nur ein Hilfsdienst, sondern ein Multiplikator: Wenn DNS langsam oder fehlerhaft ist, sehen Sie Probleme quer über alle Services. Pflicht ist deshalb eine klare, messbare DNS-Gesundheit – idealerweise getrennt nach CoreDNS und Upstream.

• DNS-Query-Latenz (P50/P95/P99): getrennt nach erfolgreichen und fehlgeschlagenen Antworten.
• DNS-Fehlerraten: SERVFAIL, NXDOMAIN (bei unerwartetem Anstieg), Timeouts.
• CoreDNS-Resource-Signale: CPU/Memory, Queueing/Concurrency, falls verfügbar.
• Cache-Hit-Rate: niedrige Hit-Rate kann bei Burst-Last zu Upstream-Überlast führen.

Ein stabiler DNS-Stack reduziert die Wahrscheinlichkeit, dass Netzwerkprobleme „wie Applikationsfehler“ aussehen. Hintergrund: DNS for Services and Pods.

Pflicht-Metriken Gruppe 6: MTU/Fragmentierungsindikatoren und „Small works, large fails“

MTU-Probleme sind berüchtigt, weil sie oft nur große Pakete betreffen. Viele Teams messen MTU gar nicht, obwohl sie eine der häufigsten Ursachen für sporadische Timeouts, TLS-Probleme und gRPC-Instabilität ist – besonders bei Tunneln, Verschlüsselung oder Multi-Cluster-Verbindungen.

• ICMP „Packet Too Big“ / „Fragmentation Needed“ Counts: sofern sichtbar, sind sie ein direkter Hinweis.
• Fragmentierungs- und Reassembly-Indikatoren: ungewöhnliche Fragmentierung kann ein Warnsignal sein.
• Retransmits korreliert mit Payload-Größe: wenn große Responses häufiger retried werden, ist MTU ein Kandidat.

Als technische Grundlage für PMTUD sind die IETF-Dokumente hilfreich: RFC 1191 und RFC 8201.

Pflicht-Metriken Gruppe 7: CNI-Control-Plane-Gesundheit (Daemons, Controller, IPAM)

Ein Datapath kann technisch korrekt sein, aber die Control Plane liefert falsche oder verspätete Programmierung. Typische Beispiele: IPAM-Probleme, Policy-Updates, BGP-Peering-Flaps, Agent-Restarts. Pflicht-Metriken sollten die „Steuerung“ sichtbar machen.

• Agent/Daemon Uptime und Restarts: häufige Restarts sind fast immer ein Vorbote von Netzwerkproblemen.
• Reconcile-/Sync-Latenz: wie schnell werden Kubernetes-Objekte (Endpoints, Policies) in Datapath-Regeln umgesetzt.
• IPAM-Auslastung: freie IPs pro Pool/Node, Fehler bei IP-Zuteilung, Leak-Indikatoren.
• Queue-Längen / Work-Queues: steigende Queues deuten auf Überlast oder Blockaden in der Control Plane hin.

IP-Engpässe wirken häufig wie Scheduling- oder Deployment-Probleme, sind aber ein CNI-/IPAM-Thema. Eine früh sichtbare IPAM-Auslastung verhindert lange Debugging-Schleifen.

Pflicht-Metriken Gruppe 8: Node-Netzwerk-Baselines (die „unsichtbare“ Infrastruktur)

Viele CNI-Probleme sind eigentlich Node-Probleme: NIC-Queues, Kernel-Drops, Neighbor Table Overflow, CPU-Pressure. Diese Signale sind nicht CNI-spezifisch, aber ohne sie ist CNI-Observability unvollständig.

• Interface Drops/Errors: RX/TX Drops, CRC Errors, Discards pro Interface.
• Packet Rate und Byte Rate: zur Einordnung von Drops (Drops ohne Last sind alarmierender).
• CPU SoftIRQ/Net RX/TX: hoher SoftIRQ-Anteil kann Netzwerkverarbeitung limitieren.
• Neighbor Table (ARP/NDP) Auslastung: Overflows führen zu schwer erklärbaren Reachability-Problemen.

Diese Metriken sind Pflicht, weil sie erklären, ob der Node als Plattform das Netzwerk überhaupt sauber verarbeiten kann.

Pflicht-Metriken Gruppe 9: Latenz am Netzwerkpfad, aber richtig dimensioniert

„Netzwerklatenz“ ist ein gefährlicher Begriff, weil er oft zu grob gemessen wird. Pflicht ist nicht „ein Ping“, sondern eine Latenzsicht, die den Pfad aufschlüsselt, wenn möglich:

• DNS-Latenz: getrennt messen (siehe DNS-Gruppe), sonst wird alles zu „Netzwerk“.
• TCP Connect Time: Indikator für Routing/Firewall/Queueing-Probleme.
• TLS Handshake Time: Indikator für MTU, Zertifikats-/Proxy-Probleme, CPU-Overload.
• RTT/Latency pro Nodepair (optional): besonders wertvoll bei Node-to-Node-Problemen.

Wenn Sie nur End-to-End-Latenz messen, sehen Sie zwar „es ist langsamer“, aber nicht „wo“ und „warum“. Pflicht-Metriken sollten mindestens zwei bis drei Teilzeiten enthalten, die häufige Ursachen abtrennen.

Labels und Dimensionen: Ohne die richtigen Aufschlüsselungen sind Metriken wenig wert

Viele Teams sammeln Metriken, aber ohne die Dimensionen, die im Incident entscheidend sind. Pflicht ist daher nicht nur „welche Metrik“, sondern „wie sie geschnitten werden kann“. Typische Pflicht-Dimensionen:

• Node / Nodepool / Zone: um node-spezifische Probleme sofort zu sehen.
• Namespace: zur Zuordnung von Policy- und Traffic-Problemen zu Ownership.
• Direction: ingress/egress, ggf. src/dst Kontext.
• Reason/Code: Drop-Reason, DNS-Response-Code, Conntrack-Drop-Reason (soweit verfügbar).
• Interface/Datapath-Hook: underlay vs. overlay vs. host-veth (wenn praktikabel).

Wichtig: Dimensionen müssen datenschutz- und sicherheitskonform sein. „Top Talkers“ sind nützlich, aber nicht jede Organisation darf IP/Service-Details breit sichtbar machen. Dann sind Aggregationen pro Namespace oder Serviceklasse oft der richtige Kompromiss.

Alarmierung: Pflicht-Alerts, die wirklich helfen

Pflicht-Metriken sollten nicht nur gesammelt, sondern mit wenigen, hochwertigen Alerts verbunden sein. Sonst entsteht Alarmmüdigkeit. Ein praxistaugliches Pflicht-Alert-Set umfasst typischerweise:

• Drop-Rate-Anstieg: absolut und relativ (z. B. Drops pro Paketrate), pro Node und clusterweit.
• Conntrack-Auslastung hoch: plus „Conntrack drops > 0“ als sofortiger Incident-Trigger.
• DNS P99 Latenz hoch oder Timeout-Rate steigt: getrennt nach CoreDNS und Upstream, wenn möglich.
• CNI-Agent-Instabilität: Restarts/CrashLoops, Sync-Lag oder Queue Backlog.
• IPAM-Pool knapp: freie IPs unter Schwellwert, IPAM-Errors > 0.
• Interface Errors/Drops: Hardware-/Treiberindikatoren, die oft übersehen werden.

Diese Alerts sind bewusst „infra-nah“. Applikationsalerts sind wichtig, aber sie sagen selten, ob das CNI die Ursache ist. Pflicht-Alerts sollen die Infrastruktur als Root Cause früh sichtbar machen.

Dashboards: Eine sinnvolle Minimalstruktur für CNI-Observability

Ein häufiges Problem ist ein „Mega-Dashboard“ ohne klare Reihenfolge. Bewährt hat sich eine Minimalstruktur in drei Ebenen, die einem Incident-Flow entspricht:

• Ebene 1: Cluster Health Snapshot (Drops, Conntrack, DNS, Agent-Restarts, IPAM-Freiheit)
• Ebene 2: Node Vergleich (Top 10 Nodes nach Drop-Rate/Conntrack-Auslastung/DNS-Latenz)
• Ebene 3: Ursachenfenster (Drop-Reasons, Policy-Denies, Service/Endpoint-Flaps, MTU-Indikatoren)

So vermeiden Sie, dass das Team im Incident „irgendwo“ anfängt. Es gibt einen festen Pfad: erst global, dann lokal, dann Ursache.

Tooling-Hinweise: Woher die Metriken typischerweise kommen

Die konkreten Metric-Namen variieren je CNI (Calico, Cilium, Antrea, Flannel, Cloud-CNI) und je Observability-Stack. Dennoch sind die Quellenklassen stabil:

• CNI-Agent-Metriken: über Prometheus-Endpunkte der Daemonsets/Controller.
• Kernel-/Node-Metriken: Node Exporter, eBPF-basierte Exporter oder OS-telemetry.
• DNS-Metriken: CoreDNS Prometheus-Metriken, ggf. NodeLocal DNSCache-Signale.
• Flow-Visibility: eBPF/Flow-Logs als Ergänzung (nicht als Pflicht, aber oft als nächster Schritt).

Wenn Sie eine standardisierte Service- und Gateway-Schicht nutzen, kann auch die Gateway API helfen, Observability konsistent zu strukturieren: Kubernetes Gateway API.

Praktische Ableitungen: Was Pflicht-Metriken im Incident konkret beantworten

Ein gutes Pflicht-Metrik-Set sollte im Incident schnell Antworten auf wenige Schlüsselfragen liefern. Diese Fragen sind bewusst so formuliert, dass sie operational helfen:

• Gehen Pakete verloren? (Drops/Drop-Rate, Retransmits, Interface Drops)
• Ist es ein einzelner Node oder ein Muster? (Node/Zone-Verteilung der Fehler)
• Blockt Policy oder verliert der Datapath? (Policy-Drops vs. andere Drop-Reasons)
• Ist DNS der Multiplikator? (DNS-Latenz/Timeouts korreliert mit Applikationsfehlern)
• Ist Conntrack/NAT am Limit? (Auslastung, Drops, Burst-Verhalten)
• Hinkt die Control Plane hinterher? (Sync-Lag, Agent-Restarts, Queue Backlog)

Wenn Sie diese Fragen in wenigen Minuten beantworten können, haben Sie CNI-Observability im produktiven Sinne erreicht.

Outbound-Quellen für vertiefende Informationen

• Kubernetes Networking Concepts: Einordnung von CNI, Datenpfaden und Netzwerkmodellen
• Kubernetes Network Policies: Grundlagen zu Policy-Durchsetzung und Blockaden
• DNS for Services and Pods: DNS-Verhalten als zentrale Abhängigkeit
• kube-proxy Referenz: Service-Routing und mögliche Failure Patterns
• RFC 1191: Path MTU Discovery (IPv4) als Grundlage für MTU-Fehlerbilder
• RFC 8201: Path MTU Discovery (IPv6) als Grundlage für MTU-Fehlerbilder
• Kubernetes Gateway API: Standards für Gateway- und Routing-Observability

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.