Concepts

AttributionCopy Anchor Link

Who is spending, and on what? Every pod is priced from the node it runs on: its share of the node — max(requests, measured usage) for CPU and memory — times the node's price. The price comes from a node annotation you set (kubehero.io/node-hourly-usd), the pricing engine's live cloud price lists, or an estimate, and the source is recorded. GPU nodes attribute most of their price to accelerators by GPU count.

What's left of a node's price after its pods is idle cost, which you can keep separate or share back. Network transfer and log volume are attributed to the workload that produced them. See Cost allocation.

Allocation is an estimate reconciled to node prices, not to your invoice.

SignalsCopy Anchor Link

Cost, logs, profiles, flows, container usage and cluster events all land in one ClickHouse store with the same labels: cluster, namespace, workload, workload_kind, pod, container, node, team, zone. That shared vocabulary is what lets a dashboard page, an alert rule or an investigation move from a cost spike to the log pattern, the hot function and the network edge behind it.

Teams come from the kubehero.io/team pod label (configurable), with a namespace fallback and an optional namespace → team map; pods without a team roll up under unattributed rather than disappearing.

RightsizingCopy Anchor Link

What's the smallest safe request? KubeHero sizes each container from its measured usage over an observation window (default 7 days): CPU to a percentile (default p95) plus headroom (default 15%); memory to the larger of p99 and the observed maximum, plus headroom, never below that maximum, and never down after an OOM kill. Confidence comes from how much of the window has samples.

A RightsizingPolicy decides what happens with those numbers:

• recommend — write them to the policy's status; change nothing;
• shadow — also record exactly what would change, and why anything would be blocked; change nothing;
• apply — patch requests, only when the policy is armed and every guard passes (confidence, bounded step, daily limit, no rollout in progress, no VPA, enough replicas).

See Rightsizing.

Budgets and ceilingsCopy Anchor Link

A BudgetPolicy declares a spending limit for a scope (e.g. $100000/mo for every env=prod cluster). A CeilingPolicy references it and defines what to do when the burn rate — spend rate extrapolated against the budget — crosses a multiple for a sustained window: alert, cap HPAs, evict low-priority pods, cordon a node pool, one step at a time with a wait between steps.

Guarded automationCopy Anchor Link

Every mutation in KubeHero follows one path:

1. something proposes a change — you, or an agent;
2. a human arms the policy (humanArm: true is the default);
3. the operator executes it in bounded steps, dry-run first;
4. it's audited in an append-only, HMAC-signed log;
5. it's reversible with kubehero undo inside the cooldown.

Agents can only do step 1. See Agents & MCP.

Demo dataCopy Anchor Link

A fresh install should never look empty, but it should never lie either. When a signal's store isn't configured, its APIs return fixtures labelled source: "demo" and the dashboard shows a demo badge. Set controlPlane.demoMode: "false" in production to make missing stores fail loudly instead.