Why Network Data Matters

The network carries everything. Every API call, every database query, every service-to-service interaction flows through it. Unlike logs (which show what an application chose to record) or metrics (which show aggregates over time), network traffic is the ground truth of what actually happened.

The Network as Source of Truth

In a Kubernetes environment, network traffic contains far more than connectivity data. It’s where your entire application executes.

Application & Business Logic

Your APIs don’t run in isolation—they run on the network. Every transaction, every user action, every business decision flows through as network traffic:

• Complete API payloads — Full request and response bodies, not just status codes
• Transaction flows — The actual sequence of calls that make up a user journey
• Service contracts in action — What services actually send vs. what’s documented
• Validation decisions — What gets accepted, what gets rejected, and the exact error returned
• State changes — Data transformations as information moves between services

Performance & Latency

Network traffic reveals performance characteristics that other observability tools miss or approximate:

• Actual latency at each hop — Not sampled, not averaged, the real time for every request
• Time decomposition — DNS resolution, TCP handshake, TLS negotiation, server processing, data transfer
• Payload impact — How request/response sizes affect throughput
• Retry behavior — Automatic retries, backoff patterns, timeout configurations in action
• Connection overhead — Keep-alive efficiency, connection pool behavior, cold start penalties

Security & Compliance

Network traffic is where security policies are enforced—or violated:

• Authentication in action — Tokens, credentials, API keys as they’re transmitted
• Authorization decisions — What’s allowed, what’s denied, access patterns over time
• Sensitive data flows — PII, payment data, healthcare records moving between services
• East-west traffic — Internal service communication often invisible to perimeter security
• Anomaly detection — Unusual access patterns, unexpected destinations, data exfiltration indicators

Infrastructure Health

The network layer reveals infrastructure problems before they become outages:

• TCP connection states — Handshake failures, resets, half-open connections
• DNS behavior — Resolution times, failures, caching effectiveness
• TLS health — Certificate issues, handshake failures, protocol mismatches
• Load distribution — Traffic patterns across replicas, hot spots, imbalanced routing
• Service discovery — How services find each other, registration/deregistration patterns

The Context Problem

Raw network packets contain valuable data, but they lack the context needed to make sense of it.

What Raw Packets Don’t Tell You

A captured packet shows:

• Source IP: 10.244.1.15
• Destination IP: 10.244.2.23
• Port: 8080
• Payload: {"user_id": 12345, "action": "checkout"}

But it doesn’t tell you:

• Which pod sent it? Which service?
• What namespace? What deployment?
• Which process inside the container?
• Is this normal behavior or anomalous?

Without Kubernetes context, you’re left correlating IP addresses manually—a task that’s nearly impossible in dynamic environments where pods come and go.

API Fragmentation

The problem compounds at the API layer. A single HTTP request might span multiple TCP segments, arrive out of order, or be interleaved with other requests on the same connection. Raw packet capture sees fragments; understanding the actual API call requires reconstruction.

The Two Worlds of Visibility

There are two approaches to Kubernetes observability, each with tradeoffs:

Network Tools (Wireshark, tcpdump)

• ✓ Complete payload visibility—every byte on the wire
• ✓ Every request captured, not sampled
• ✗ No Kubernetes context—just IPs and ports
• ✗ Manual correlation required

Observability Tools (OpenTelemetry, APM)

• ✓ Kubernetes context—pod, service, namespace
• ✓ Distributed tracing across services
• ✗ Sampled data—not every request
• ✗ No payload visibility—metrics and spans only
• ✗ Statistical/aggregated information

How Kubeshark Bridges the Gap

Kubeshark combines the depth of network tools with the context of observability platforms:

Kubeshark enriches network traffic by correlating across multiple layers:

The result: every API call is tagged with its complete Kubernetes identity, with full payload visibility.

Before (raw packet):
  10.244.1.15:43210 → 10.244.2.23:8080

After (Kubeshark enriched):
  frontend-7d4b8c6f9-x2k4m (namespace: production)
    → payment-service (namespace: production)
  Process: node (PID 1234)
  API: POST /api/v1/checkout
  Request body: {"user_id": 12345, "items": [...]}
  Response body: {"order_id": "abc-123", "status": "confirmed"}
  Latency: 145ms
  Status: 200 OK

The Observability Gap

Modern observability relies on three pillars: logs, metrics, and traces. Each has limitations that network data fills.

Network traffic complements these pillars by providing:

• Complete coverage — Captures everything, not just what’s instrumented
• Zero code changes — Works with any application, any language, any framework
• Exact reproduction — See the precise request that caused a failure
• Historical record — Go back in time to any moment in your traffic history

Who Benefits

Site Reliability Engineers (SREs)

When production breaks at 3 AM, SREs need answers fast. Network data provides:

• The exact API call that triggered the incident
• Full request/response context, not just “500 error occurred”
• Upstream and downstream impact—what else was affected
• Timeline reconstruction—what happened in what order

Instead of: Correlating logs across 12 services, guessing which request failed With network data: See the exact failed request, its payload, and the error response

DevOps & Platform Engineers

Infrastructure decisions should be based on actual usage, not assumptions:

• Real service dependencies from traffic patterns
• Actual resource utilization per endpoint
• Traffic flows that inform network policy decisions
• Capacity planning based on real request volumes and sizes

Instead of: Maintaining outdated architecture diagrams With network data: Generate accurate service maps from actual traffic

Security Teams

Security requires visibility into what’s actually happening, not what should be happening:

• All data flows, including internal east-west traffic
• Authentication and authorization patterns
• Sensitive data exposure in API payloads
• Anomalous behavior compared to baselines

Instead of: Relying on perimeter logs and hoping internal traffic is safe With network data: Complete visibility into every service interaction

Developers

Debugging distributed systems is hard. Network data makes it easier:

• See exactly what your service received and what it sent back
• Verify headers, payloads, and response codes match expectations
• Debug integration issues by comparing actual vs. expected traffic
• Test API contracts against real production behavior

Instead of: Adding debug logs, redeploying, reproducing the issue With network data: Inspect the exact request that caused the bug

The Accessibility Challenge

This wealth of information exists in every Kubernetes cluster. The challenge is accessing it effectively.

Traditional approaches require:

• Deep expertise in packet analysis and protocol internals
• Complex query languages with steep learning curves
• Manual correlation across thousands of concurrent requests
• Time—which is scarce during incidents

The result: Most teams underutilize their network data, or ignore it entirely, falling back to logs and metrics that tell only part of the story.

Kubeshark addresses this by providing an intuitive Dashboard and AI-powered analysis that makes network data accessible to everyone on the team.

What’s Next

• Installation — Get Kubeshark running in your cluster
• Dashboard — Explore the Kubeshark interface
• AI Integration — Use AI to query your network data