Network Observability: See Every Connection & DNS Query in the Cluster

Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.

Originaltext der Quelle (nicht übersetzt) – die deutsche Zusammenfassung findest du im Tab „Kurzfassung".

You've probably experienced this: an app throws a timeout or a failed request, and the real cause turns out to be a dropped connection somewhere in the cluster or a DNS lookup gone wrong, but you can’t see it from inside the app itself. Most teams don't have a clear, real-time view into their own network traffic, pod to pod, namespace to namespace, or workload to the outside world, until something breaks and they have to dig through logs to figure out what's actually calling what. In a typical microservices cluster, traffic crosses namespaces all the time: an ecommerce workload calling payments, a workload egressing to an external HTTPS endpoint, one path suddenly carrying a lot more traffic than the rest. Without enrichment, you'll see pod IPs and ports, but you won't see workload identity, and you can't tell which connections need prioritization. The addition of Network Observability to Fairwinds Insights changes that. It turns cluster flow and DNS telemetry into a workload-aware service map and a drillable event stream, so you can see who's talking to whom, identify what's leaving the cluster, and debug dependencies in Kubernetes terms: pod, namespace, and workload owner. It's captured through eBPF via Inspektor Gadget. Instead of an address like 10.244.0.104:40015, you see ecommerce/Deployment/backend, so you can separate real application traffic from platform noise and follow a dependency straight into the event stream. How Network Observability Works in Fairwinds Insights Network Observability runs as two components. The agent, network-flow, is a DaemonSet …

Vollständiger Originalartikel ↗

• Betroffenheit im eigenen Stack prüfen: Versionen/Komponenten abgleichen.
• Originalquelle / Hersteller-Advisory lesen: https://www.fairwinds.com/blog/network-observability-see-every-connection-dns-query-in-the-cluster
• Verfügbaren Patch oder Workaround einspielen und dokumentieren.