K8s Network Observability: Pflicht-Metriken (DNS, Drops, Conntrack)

K8s Network Observability ist die Grundlage dafür, Netzwerkprobleme in Kubernetes schnell, sauber und reproduzierbar zu diagnostizieren – ohne sich auf Bauchgefühl, Zufalls-Fixes oder zeitaufwendige Packet Captures zu verlassen. In modernen Clustern entstehen Störungen selten „nur“ durch ein defektes Kabel; häufiger sind es komplexe Wechselwirkungen aus DNS-Latenz, Paketverlusten (Drops) auf Nodes, conntrack-Sättigung, NAT-Effekten, überlasteten Ingress-Controllern, Service-Routing (kube-proxy oder eBPF) und Nebenwirkungen durch Sidecars oder NetworkPolicies. Das Resultat sieht an der Oberfläche oft gleich aus: Timeouts, sporadische Verbindungsabbrüche, erhöhte P99-Latenz oder „kann Host nicht auflösen“. Mit den richtigen Pflicht-Metriken – insbesondere für DNS, Drops und Conntrack – lässt sich jedoch in Minuten eingrenzen, ob die Ursache im Namenauflösen, im Datapath (CNI/Kernel), in der Zustandsverwaltung (conntrack) oder in der Applikationsschicht liegt. Dieser Artikel zeigt praxisnah, welche Kennzahlen Sie wirklich brauchen, wie Sie sie strukturieren, welche typischen Muster auf konkrete Root Causes hindeuten und wie Sie daraus robuste Alerts und Runbooks ableiten.

Warum Netzwerk-Observability in Kubernetes anders ist als „klassisches“ Monitoring

Kubernetes abstrahiert Netzwerke stark: Pods sind kurzlebig, IPs ändern sich, Services verschleiern Backends, und Datenpfade variieren je nach CNI, kube-proxy-Modus, eBPF-Nutzung, Overlay/Underlay und Cloud-Integration. Zudem sind viele Netzwerkfehler „intermittierend“: Ein Pod funktioniert, der nächste nicht; ein Node zeigt Drops, ein anderer nicht; nur bestimmte Ziel-Ports sind betroffen. Deshalb reichen klassische Host-Metriken (CPU, RAM) allein nicht aus. Sie benötigen ein Modell, das Netzwerkbeobachtung in Ebenen gliedert und Signale aus allen Ebenen korreliert.

• Control Plane Signale: DNS (CoreDNS), Service Discovery, Policy-Events
• Datapath Signale: Drops, Retransmits, Queueing, MTU/Fragmentation
• State Signale: conntrack-Auslastung, NAT-Portverbrauch, Table-Overflows
• Service Signale: SLOs, HTTP/gRPC-Errors, Upstream-Connect-Time

Pflicht-Metriken als Minimal-Set: Was „nicht verhandelbar“ ist

Ein sinnvolles Minimal-Set ist klein genug, um überall ausrollbar zu sein, aber vollständig genug, um die häufigsten Netzwerkausfälle abzudecken. Für K8s Network Observability empfiehlt sich ein Kernset aus drei Pflichtblöcken: DNS, Drops und Conntrack. Ergänzend kommen TCP/Socket- und Service-Routing-Metriken dazu, damit Sie Ursache und Wirkung sauber trennen.

DNS-Observability: Die wichtigsten CoreDNS-Metriken und was sie bedeuten

DNS ist in Kubernetes ein hochkritischer Dependency-Layer: Selbst wenn Netzwerk und Applikation „gesund“ sind, führt langsames oder fehlerhaftes DNS zu Timeouts, Retry-Stürmen und unnötiger Last. Viele Incidents beginnen mit „kann Service X nicht erreichen“ und sind am Ende „DNS war langsam“ oder „SERVFAIL-Spike“. Mit CoreDNS-Metriken bekommen Sie die Kontrolle zurück.

Pflicht-Metriken für DNS

• DNS Request Rate: Anzahl Queries pro Sekunde (gesamt und nach Query-Typ/Zone)
• DNS Latenz: Request-Duration (P50/P95/P99), idealerweise getrennt nach Upstream/Cache
• Response Codes: Anteil NXDOMAIN, SERVFAIL, REFUSED, FORMERR
• Cache-Effizienz: Cache Hits/Misses, Cache Size/TTL-Behavior
• Forwarder-Gesundheit: Timeouts/Errors beim Forwarding zu Upstream-Resolvern
• CoreDNS Ressourcen: CPU/Memory, Threading/Concurrency, ggf. Goroutines

Interpretationsmuster, die in der Praxis schnell helfen

• Hoher SERVFAIL-Anteil + steigende DNS-Latenz: Upstream-Resolver instabil oder Netzwerkpfad zu Upstream gestört
• NXDOMAIN-Spike: Fehlkonfiguration (falsche Namen), kaputte Service Discovery oder „typo storms“ durch Deployments
• Cache Misses steigen + QPS steigt: TTL zu niedrig, zu viele einzigartige Namen, oder Cache wird durch Memory-Pressure verdrängt
• DNS-Latenz steigt nur auf einzelnen Nodes/Namespaces: Node-lokale Probleme (CNI, Drops) oder egress/policy-spezifische Einschränkungen

Für die Grundlagen zu DNS- und Service-Networking-Konzepten in Kubernetes sind die offiziellen Docs hilfreich: Kubernetes Services & Networking. Für CoreDNS-Konfiguration und Plugins: CoreDNS Projektseite.

Drops-Observability: Paketverluste sichtbar machen, ohne PCAP zu benötigen

„Drops“ sind der direkteste Hinweis darauf, dass der Datapath nicht zuverlässig arbeitet. Wichtig ist: Drops können auf vielen Ebenen passieren – NIC-Ring, Kernel-Queues, tc/eBPF, iptables, CNI-Datapath, Overlay-Tunnel, virtio, oder durch Policy/Firewall. Eine gute Metrikstrategie trennt deshalb wo gedroppt wird und warum (Queue voll, Policy, Invalid Packet, MTU, conntrack).

Pflicht-Metriken für Drops auf Node-/Interface-Ebene

• Interface RX/TX Drops: Drops auf Netzwerkinterface-Ebene (pro Node, pro Interface)
• RX/TX Errors: CRC, frame errors, overruns (Hinweis auf Treiber/NIC/MTU/Offload-Probleme)
• Kernel Packet Drops: Drops durch Kernel-Queueing (z. B. backlog/softnet)
• TCP Retransmits: Retransmit-Rate als indirektes Signal für Loss/Jitter

Pflicht-Metriken für Drops im Kubernetes-Datapath (CNI/Service/Policy)

• Policy Drops: explizit geblockter Traffic (NetworkPolicy, CNI-Policy, eBPF-Policy)
• Forwarding Drops: Drops beim Weiterleiten (Routing, Tunnel, Encapsulation)
• Service-LB Drops/Failures: Fehlgeschlagene Service-Translation oder Backend-Unreachable
• Encap/Decap Errors: VXLAN/IPIP/WireGuard-Fehler, wenn Overlays verwendet werden

Node-Exporter ist in vielen Setups die Basis, um Interface- und Kernel-nahe Metriken über Prometheus zu sammeln: Prometheus Node Exporter. Wenn Sie ein eBPF-basiertes CNI nutzen, liefern dessen Telemetrie-Features oft deutlich präzisere Drop-Reasons als reine Interface-Counter.

Conntrack-Observability: Der häufigste „unsichtbare“ Engpass

Conntrack (Connection Tracking) ist in Kubernetes-Umgebungen besonders relevant, weil NAT und Stateful Firewalling in vielen Pfaden genutzt werden: NodePort/LoadBalancer, Egress NAT/Masquerade, teilweise auch Service-Routing (abhängig vom Setup). Wenn conntrack voll läuft oder stark churnt, äußert sich das in schwer zu deutenden Symptomen: neue Verbindungen schlagen fehl, DNS wird langsam, einzelne Pods verlieren „zufällig“ Konnektivität, und Retries verstärken das Problem. Daher ist Conntrack ein Pflichtblock für K8s Network Observability.

Pflicht-Metriken für conntrack

• Aktuelle conntrack-Entries: aktuelle Anzahl aktiver Einträge
• conntrack-Maximum: Kapazitätslimit (max entries) und Auslastungsquote
• Insert/Drop/Fail Counter: fehlgeschlagene Inserts oder Drops wegen Full Table
• Conntrack-Churn: Rate neuer Entries pro Sekunde (Spikes sind oft gefährlich)
• NAT-Related Counters: Indikatoren für Port-Erschöpfung (je nach Plattform/Export verfügbar)

Einfacher Health-Indikator: conntrack-Auslastung als Ratio

Ein praktisch nutzbarer Indikator ist die Auslastungsquote. Wenn Sie diese dauerhaft überwachen, erkennen Sie kritische Zustände, bevor Verbindungen ausfallen:

$\mathrm{conntrack\_utilization}=\frac{\mathrm{nf\_conntrack\_count}}{\mathrm{nf\_conntrack\_max}}$

Als Faustregel ist eine dauerhaft hohe Auslastung riskant, weil kurze Bursts (z. B. nach Deployments, DNS-Flaps oder Retry Storms) die Tabelle abrupt füllen können. Die Kernel-Dokumentation und Hintergrundinfos zu conntrack/nf_conntrack sind ein guter Einstieg: Netfilter / conntrack Dokumentation.

TCP- und Socket-Metriken: Das Bindeglied zwischen Drops/Conntrack und „App langsam“

DNS, Drops und Conntrack erklären viele Ursachen. Um diese Ursachen sauber mit App-Symptomen zu verbinden, brauchen Sie zusätzlich TCP-/Socket-Signale. Sie sind oft der schnellste Weg, „Netzwerk“ von „Applikation“ zu trennen: Wenn Retransmits steigen, SYN-Backlog überläuft oder Listen-Queues voll sind, ist die App häufig nicht der eigentliche Flaschenhals – oder sie ist es, aber über Netzwerk sichtbar.

• TCP Retransmits: steigt bei Paketverlust, Jitter, Überlast oder MTU-Problemen
• TCP Out-of-Order: Hinweis auf Reordering oder asymmetrische Pfade
• SYN/SYN-ACK Fehler: Verbindungsaufbau-Probleme (Firewall, conntrack, Drops)
• Socket Errors/Resets: RST-Spikes können auf Overload, Timeouts oder Policy-Interaktion hindeuten
• Listen Queue Saturation: wenn Backends Verbindungen nicht schnell genug annehmen

Service-Routing und kube-proxy: Pflichtsignale bei ClusterIP/NodePort-Fehlerbildern

Viele Verbindungsprobleme in Kubernetes entstehen nicht auf „L2/L3“, sondern im Service-Routing: kube-proxy (iptables oder IPVS) oder eBPF-basierte Service-Load-Balancer entscheiden, wohin ein Paket geht. Bei hoher Last kann die Translation CPU kosten, bei Fehlkonfiguration können Backends scheinbar „random“ ausfallen. Deshalb ist es sinnvoll, Service-Pfade gezielt mit Metriken zu instrumentieren.

• Service-Backend-Errors: Backend nicht erreichbar, Connection Refused/Timeout auf Upstream-Ebene
• Node CPU SoftIRQ: hoher SoftIRQ-Anteil kann Service-Routing und Packet Processing limitieren
• IPVS/iptables Indikatoren: je nach Modus unterschiedliche Signale (z. B. conntrack-Abhängigkeit, Rule Explosion)

Für Hintergründe zum kube-proxy und dessen Betriebsmodi: kube-proxy Referenz.

CNI-spezifische Observability: Calico, Cilium & Co. sinnvoll nutzen

Das CNI ist in Kubernetes der Datapath. Unterschiedliche CNIs liefern unterschiedliche Telemetrie-Qualität. Wichtig ist nicht, jede Metrik zu sammeln, sondern die Metriken, die Drop-Reasons und Policy-Entscheidungen erklärbar machen. Gerade bei NetworkPolicies ist „Traffic blocked“ ohne Reason wertlos; mit Drop-Reason wird es ein 5-Minuten-Fix.

Beispiel: eBPF-Observability mit Cilium

• Drop Counters nach Reason: Policy denied, invalid packet, CT related drops
• Flow Visibility: L3/L4/L7 Flows (wer spricht mit wem, welcher Port, welcher Verdict)
• DNS Visibility (optional): DNS-Queries auf Flow-Ebene als Ergänzung zu CoreDNS

Wenn Sie Cilium einsetzen, sind die offiziellen Observability- und Hubble-Dokumentationen relevant: Cilium Dokumentation.

Beispiel: Calico-Observability

• Policy-Entscheidungen: Drops/Allows, häufige Deny-Rules
• Felix-/Dataplane-Indikatoren: Hinweis auf Dataplane-Probleme oder Rule-Programmierung
• BGP-Status (falls genutzt): Peers down, Route Flaps als Root-Cause-Signal

Für Calico-Konzept und Betrieb: Calico Dokumentation.

DNS, Drops, Conntrack gemeinsam korrelieren: Drei typische Incident-Patterns

Die Pflicht-Metriken entfalten ihren Wert erst in Kombination. In der Praxis reichen oft wenige Muster, um die Richtung klar zu machen.

Pattern: „DNS wird langsam, dann folgen Timeouts“

• Beobachtung: DNS P95/P99 steigt, danach steigen App-Timeouts
• Wahrscheinliche Ursachen: Upstream-Resolver-Latenz, CoreDNS CPU-Throttling, Drops auf Nodes, conntrack-Churn
• Pflichtcheck: DNS Response Codes (SERVFAIL), CoreDNS CPU, Node Drops, conntrack utilization

Pattern: „Neue Verbindungen scheitern, bestehende laufen“

• Beobachtung: Sporadische Connection Timeouts beim Verbindungsaufbau, langlaufende Streams ok
• Wahrscheinliche Ursachen: conntrack voll, NAT-Portdruck, SYN Drops, Policy/Firewall
• Pflichtcheck: conntrack inserts failed, utilization, TCP SYN-Fehler, Drops auf Node

Pattern: „Nur bestimmte Nodes betroffen“

• Beobachtung: Pods auf Node A haben Probleme, auf Node B nicht
• Wahrscheinliche Ursachen: NIC/Treiber, IRQ-Überlast, lokale Drops, conntrack-Limit kleiner/anders, Kernel-Queueing
• Pflichtcheck: Interface Drops/Errors pro Node, softnet/backlog, conntrack count/max, CPU softirq

Alerts und Schwellenwerte: Wie Sie aus Pflicht-Metriken handlungsfähige Signale machen

Alerts sollten nicht „alles, was sich bewegt“ melden, sondern klare Handlung auslösen. In Netzwerk-Observability sind Ratio- und Trend-Alerts oft besser als absolute Werte, weil Clustergrößen und Workload-Profile variieren. Gleichzeitig müssen Alerts die häufigsten, kritischen Failure Modes abdecken: DNS-Ausfälle, Drop-Spikes, conntrack-Sättigung.

DNS Error Rate als Ratio

Ein pragmatischer Alert ist die Fehlerrate bei DNS-Antworten (z. B. SERVFAIL-Anteil). Das ist robuster als „QPS hoch“:

$\mathrm{dns\_error\_rate}=\frac{\mathrm{dns\_errors}}{\mathrm{dns\_total}}$

Drop Spike als Change-Rate

• Signal: Drop-Rate steigt abrupt gegenüber Baseline (z. B. 5–10× innerhalb weniger Minuten)
• Aktion: Node identifizieren, Workload/Deployment-Korrelation prüfen, CNI/Policy-Änderungen prüfen

Conntrack Near-Full

• Signal: conntrack utilization dauerhaft hoch oder schnell ansteigend
• Aktion: Connection Churn senken (Keep-Alive/HTTP2), NAT/egress prüfen, conntrack tuning und Node-Kapazität prüfen

Dashboards, die sich bewährt haben: Struktur statt Metrik-Wildwuchs

Ein gutes Dashboard folgt dem Diagnose-Flow: „Ist es DNS? Sind es Drops? Ist es conntrack? Oder ist es Service-Routing?“ Wenn Sie diese Reihenfolge abbilden, verkürzt sich MTTR spürbar. Ein weiterer Erfolgsfaktor ist die Aufteilung nach Scope: Cluster-Übersicht, Node-Drilldown, Namespace/Workload, und Traffic-Pfad (Ingress/Egress).

• Cluster Overview: DNS Latenz & Error Rate, Drop Rate gesamt, conntrack utilization Top-N Nodes
• Node Detail: Interface drops/errors, softirq, retransmits, conntrack count/max, CPU throttling
• Workload/Namespace: DNS QPS pro Namespace, egress connection rate, policy denies
• Path Views: Ingress-Errors/Upstream connect time, Service backend health, egress NAT pressure

Implementierungs-Checkliste: So bauen Sie K8s Network Observability pragmatisch auf

• CoreDNS instrumentieren: DNS Latenz, Response Codes, Cache, Forwarder-Health
• Node-Level Telemetrie: Interface drops/errors, TCP retransmits, softirq/backlog, CPU throttling
• Conntrack exportieren: nf_conntrack_count/max, near-full Alerts, churn-Indikatoren
• CNI-Telemetrie aktivieren: Policy verdicts, drop reasons, optional flow visibility
• Dashboards standardisieren: Cluster → Node → Workload → Pfad, nicht „alles auf eine Seite“
• Runbooks verknüpfen: Jeder Alert zeigt: welche Metriken prüfen, welche Hypothesen testen, welche Sofortmaßnahmen möglich sind

Für die Grundlagen zu Service Discovery und Netzwerkpfaden in Kubernetes: DNS für Pods und Services. Für Prometheus-basierte Metrik-Erfassung und Exporter-Ansätze: Prometheus Übersicht.

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.