understanding network i/o for kubernetes pods: a simple guide

what rx and tx bytes actually mean in kubernetes

rx (receive) bytes is the total data flowing into the pod from the network — API requests arriving at your service, responses coming back from databases or upstream APIs, messages arriving from a message broker. tx (transmit) bytes is the data your pod is sending out — responses to clients, requests to downstream services, data being written to object storage.

in kubernetes, these numbers are measured at the network interface level inside the pod's network namespace. they include traffic to other pods within the cluster (east-west) and traffic to external endpoints (north-south). kubernetes itself doesn't distinguish between internal and external traffic in the pod-level metric, so a high tx number could be heavy inter-service communication OR unexpected internet egress — you need other signals to tell the difference.

common network i/o problems and what they look like

a retry storm is one of the most common network problems in microservice architectures. if a downstream service is slow or unavailable, clients with aggressive retry logic can multiply traffic dramatically. you'll see tx bytes spike on the calling pod (sending repeated requests) and rx bytes spike on the called pod (receiving a flood of retries). cpu on the called pod may spike too, but the network i/o is usually the clearest signal.

unexpected egress is another common issue: a container that shouldn't be making external calls suddenly appears with high tx bytes to an external IP. this can be a bug (wrong endpoint configured), a security issue (data exfiltration), or a misconfigured third-party library making unexpected calls. per-pod network monitoring surfaces this quickly; host-level network monitoring can't attribute the traffic to a specific container.

how gromitor shows kubernetes pod network i/o

the gromitor dashboard shows per-pod rx and tx bytes as a rate (bytes per second) plotted over time, alongside cpu and memory on the same view. you can see all pods in a namespace together (useful for spotting which service is dominating network traffic) or drill down to a single pod for detailed trend analysis.

alert thresholds for network i/o work the same way as cpu and memory: pick a pod or pod name pattern, set a tx or rx bytes/second threshold, and get notified when it's breached. this is particularly useful for services where network traffic is expected to be low and a sudden spike is always anomalous.

• per-pod rx bytes/s and tx bytes/s, live and historical
• namespace-level network i/o aggregation to see which services dominate
• alert thresholds on rx or tx rate per pod or pod name pattern
• works without network policy configuration or CNI plugin changes
• no additional network taps or packet capture — uses kubelet summary API data

baselines and what to alert on

effective network i/o alerting requires knowing what's normal first. spend a week watching your pods' network patterns before setting alert thresholds. most application pods have a fairly consistent traffic pattern during business hours and lower traffic overnight — deviations from that pattern are the signal.

a useful approach: alert on a 10x or greater spike relative to a rolling 24-hour average. this catches genuine anomalies (retry storms, data exfiltration) while ignoring expected growth from increasing traffic. gromitor's rolling average alerting helps here — alerts fire on sustained deviations, not momentary spikes from a large batch job or cache warmup.

network i/o in the context of full container monitoring

network i/o is most useful when read alongside cpu and memory. a pod with high tx bytes AND high cpu is likely processing many requests legitimately. a pod with high tx bytes but low cpu might be proxying traffic or sending data without doing much computation — worth investigating. a pod with high rx bytes but low cpu might be receiving data it's not processing (a consumer falling behind a queue).

gromitor shows all four dimensions (cpu, memory, network i/o, disk i/o) in the same pod view, which makes these combined interpretations straightforward. for the full picture on kubernetes monitoring, the kubernetes resource monitoring saas article covers the broader context, and the cross-platform container monitoring saas piece explains how this works across docker and kubernetes in one view.