What is KubeSpend
KubeSpend is a Kubernetes cost optimization platform. A small agent runs in each cluster and reports CPU and memory usage plus Kubernetes events. A server prices that usage against real published AWS rates and serves a console that shows where the money goes and what to change.
It is built around one constraint: no access to your cloud bill. KubeSpend never asks for Cost and Usage Reports, billing exports, or cross-account billing roles. Prices come from the public AWS Price List API and EC2 spot price history, which the KubeSpend server fetches with its own read-only credentials.
The three moving parts
| Component | Runs where | What it does | Tier |
|---|---|---|---|
kubespend-agent | your cluster, one Deployment | reads node/pod CPU + memory from metrics-server, collects events, PV/PVC inventory, and HPA config | Free — 100,000 snapshots plus 5,000 grace, max 3 clusters |
kubespend-ebpf-agent | your cluster, a DaemonSet | per-node network flow capture via eBPF, attributed to pods | Free trial — 50 million flow records; uncapped with the paid network add-on |
| server + console | KubeSpend SaaS, or self-hosted in your VPC | pricing, cost attribution, recommendations, UI | — |
Agents connect outbound to an ingest endpoint with an API key. Nothing needs to reach into your cluster.
What it actually tells you
Three things, in order of how much they are worth:
Where compute cost lands. Every node's hourly price split across the pods that requested capacity on it, rolled up per workload and per namespace, with idle capacity reported as its own line rather than spread across workloads. See Cost attribution.
What to shrink. Workloads requesting materially more CPU or memory than they have ever used, with a suggested request and the monthly dollar figure that reclaiming it represents. See Rightsizing.
What to change about the nodes themselves. Instance downsizing, Graviton migration, family changes for CPU- versus memory-bound fleets, spot conversion, and node consolidation plans. See Node & instance optimization.
What it will not do
It will not show you a number it cannot derive from a real price. Where a rate cannot be resolved the figure reads unavailable rather than $0, and the console labels it as such instead of drawing a misleading chart. If one node group cannot be priced, its node-hours are excluded from the total rather than guessed at, and the response reports how much was left out.
It will not give you network cost per workload. With the eBPF agent installed, cross-AZ transfer and internet egress are priced and folded into the cluster total, but only as a cluster-level daily figure; per-workload output stays as bytes split by zone. Flows whose peer has no resolvable zone are left unpriced rather than assumed, so a cluster with a large unclassified share reports a network floor rather than a total. NAT gateway and inter-region transfer are not modelled at all. See What we measure for the precise state, and AWS network costs for what the charges are and why they are hard to see.
Design decisions worth knowing
- Requests, not usage, are the cost denominator. A pod is charged for what it reserved, because that is what stops another pod from being scheduled. Usage drives recommendations, not billing.
- Node-hours are counted, not assumed. Cost is derived from distinct
(node, hour)observations, so a spot node alive for one hour is charged for one hour rather than a full day. - State lives in the server, not the agent. Agents are stateless collectors, so restarting one loses nothing and never needs a volume.
- Identity is proven, not asserted. An
org_idin an agent payload is ignored; the server resolves it from the API key.
Next
- Architecture — how the pieces connect
- What we measure — the honest coverage inventory
- Quickstart — get a cluster reporting