Introducing Network Intelligence

Compute costs get all the attention because they show up as one obvious number on the bill: the node spend. Network costs hide somewhere else entirely. Cross-AZ traffic between two services that happened to land on different availability zones. Internet egress to a third-party API nobody's mapped to a team. A chatty internal call that crosses a zone boundary a few million times a day and never shows up as a line item you can trace back to a workload.

Today we're introducing Network Intelligence: a map of every workload-to-workload connection in your cluster, priced against the same published cloud rates your provider bills you with, down to the individual API call.

Beta status

Network Intelligence is in beta. Cost figures are estimated (marked with ≈) from published rates, $0.01/GB for cross-AZ transfer and $0.09/GB for internet egress, applied to observed byte counts. As our network agent finishes rolling out across cluster types, these numbers will reconcile against your actual bill. Treat today's figures as directionally accurate, not as an invoice.

Where the money actually goes

The overview starts with four numbers: network cost month-to-date, cross-AZ cost, internet egress, and recoverable savings, the last one tied to specific actions you can take right now. Every flow gets matched against your cluster topology and classified as same node, same zone, cross-zone, or internet egress. If a destination can't be resolved, we don't ignore it; we bill it at the egress rate as a conservative ceiling, and we tell you what percentage of traffic falls into that bucket so you know how much of the picture is still fuzzy.

A map you can click into

The Flow Map lays your traffic out as a tiered diagram, ingress on one side, application and data services in the middle, egress on the other, instead of a tangle of lines that looks the same on every cluster. Click a workload and you get its flows, services, and charts. Click a connection between two workloads and you get a cost and performance strip for that specific edge: monthly cost, cost per thousand requests, requests per month, p95 latency, error rate, and cross-AZ bytes, plus a locality bar showing how much of that traffic is free (same zone) versus billed (cross zone). Zoom in on any node and its two-hop neighborhood stays sharp while the rest of the map dims out of the way.

Cost per API call, not just per namespace

Namespace-level cost is a start. It doesn't tell you which endpoint is actually expensive. The Endpoints view breaks cost down per method and path, with a self, downstream, and inclusive cost waterfall for each one, so you can see whether an endpoint is expensive because of its own work or because of what it calls downstream. Every number carries an attribution method, measured, allocated, correlated, or sampled, so you always know how directly it was observed versus estimated.

Ask it a question instead of writing a query

Flow Explorer runs on a query language built for this data (CEL), with autocomplete that stages itself field, then operator, then value, so you're not memorizing syntax. If you'd rather not write a query at all, "Ask AI" translates a plain-language request into one for you: "expensive cross-AZ traffic with retransmits," "internet egress to datadoghq.com," "NXDOMAIN storms in production." Once you've found the traffic pattern you're looking for, one click generates a CiliumNetworkPolicy from the egress destinations you actually observed:

1apiVersion: cilium.io/v2
2kind: CiliumNetworkPolicy
3metadata:
4  name: checkout-egress-allowlist
5spec:
6  endpointSelector:
7    matchLabels:
8      app: checkout
9  egress:
10    - toFQDNs:
11        - matchName: api.stripe.com
12        - matchName: datadoghq.com
13      toPorts:
14        - ports:
15            - port: "443"
16              protocol: TCP

It's generated from what we've observed, not a guess. Review it before you apply it, the same way you'd review any policy someone else drafted for you.

From visibility to a rollout plan

Seeing the cost is one thing. Acting on it safely is another, and that's a separate, more hands-on flow at the cluster level. Instead of a single "apply this" button, Network Costs walks you through a short set of questions: how much HA impact you'll tolerate (zero, for production; staged moves are fine; or maximize savings), which workloads and namespaces are in scope, whether you want to opt into service-mesh locality routing, and whether you'd rather roll this out in one shot or over several weeks.

The output is a plan broken into numbered waves, each one becoming its own pull request, gated on health and cost metrics before the next wave starts. Kubeadapt never writes to your cluster directly. Every change goes through your own GitOps pipeline, reviewed the same way any other change to your infrastructure would be.

What's next

Two more views are built and waiting on the network agent's rollout to open up fully: a Traffic tab with per-protocol throughput, latency percentiles, and eBPF-sampled connection quality (retransmits, RTT, resets), and an External Spend view that breaks internet egress down by destination domain, complete with DNS churn tracking so a misbehaving client spamming NXDOMAIN lookups doesn't hide in the noise.

Try Kubeadapt or check the docs to turn on Network Intelligence for your own clusters.