Updated 8:48 BST, January 22, to correct Polar Signals name throughout, because we are idiots and need a copy editor.
A company called Polar Signals claims to have slashed its cross-zone traffic costs in the cloud by 50% using an OSS project that it developed called Kubezonnet, which uses eBPF to help trace Kubernetes network packets.
Cross-availability zone (AZ) data transfers regularly account for at least 25% of public cloud users’ production costs, and getting those costs down aggressively is not uncommonly a priority when the bills start landing.
Polar Signals, an incident analysis and cloud optimisation specialist, in 2024 realised that cross-AZ costs were “nearly half” of its cloud costs.
A new case study from the non-profit eBPF Foundation emphasises that “the existing tools provided by their cloud provider [which it does not name] offered limited visibility, only reporting daily aggregated costs without granularity at the pod or workload level. This lack of detailed insights made it challenging to… implement targeted optimizations.”
See also: As Cisco swoops on Cilium, community efforts look critical
Polar Signals built and open-sourced (Apache 2.0) Kubezonnet in response.
The software has two key components:
Kubezonnet-agent: Collects traffic statistics, using eBPF with a netfilter postrouting hook, about all Pod [compute] network traffic.
kubezonnet-server: Aggregates the statistics sent from the agents and resolves the actual pod, node and zone relationships, and then exposes the statistics on a Prometheus metrics endpoint.
It requires users to be running Cilium as the CNI ("in Legacy host routing mode, otherwise netfilter won't work correctly, GKE dataplane v2 clusters use this mode") and Linux Kernel 6.4+ ("netfilter eBPF programs were only added in 6.4.")
Kubezonnet: Explain…
Kubezonnet is a little raw (it lacks IPv6 support for example) but what it can do is use netfilter (code that does network filtering in the Linux kernel) hooks and eBPF to traces network packets leaving Kubernetes pods (compute), aggregating traffic data over 10-second intervals.
That data, the eBPF Foundation said, is sent to a central server, which resolves the source and destination IPs to Kubernetes pods and nodes – to determine which cloud zones they are in and identify cross-AZ traffic.
That server then serves up Prometheus metrics to monitor total cross-zone traffic by pod and “flow logs to provide detailed insights into traffic patterns between specific pods,” the foundation’s case study said.
The case study comes from the eBPF Foundation because the OSS uses extended Berkeley Packet Filter (eBPF) to power this set of capabilities.
eBPF, for those new to it, lets developers run programs directly in the Linux kernel, without changing the kernel code or loading extra modules, using highly efficient sandboxed virtual machines. It has become increasingly popular due to its programmability and performance, and can be used in a range of ways; not least to connect, secure, and load-balance containerised applications efficiently and ensure fine-grained network policies for communication between containers.
As The Stack earlier noted, for many, the journey to running and managing containerised applications in Kubernetes has often been one of building the plane whilst it’s in flight: K8s is great for scheduling containers to run on a given cluster according to resource needs but many have found themselves building networking and security capabilities on the fly, which can leave some real visibility gaps.
Readers can explore more on the repository.
