Skip to main content
Available in Radar v1.8.4+ Radar shows Kubernetes allocation cost from either OpenCost-compatible metrics in your existing Prometheus or the APIs of a Kubecost 3 Aggregator. Both integrations are passive and read-only.

​
What you see

  • Cluster cost - current hourly rate, monthly projection, and CPU, memory, storage, and network breakdowns when available.
  • Namespaces - sortable cost rows with workload details on demand.
  • Workloads and applications - focused CPU and memory allocation cost for Deployments, StatefulSets, and DaemonSets.
  • Nodes - instance, region, and hourly or monthly pricing where provider data is available.
  • Trends - historical allocation cost over 6h, 24h, or 7d with hover details.
  • Allocation use - CPU and memory shown separately when complete usage evidence is available.
Radar presents monthly projections from the current hourly rate. Historical spend uses the selected range. OpenCost-compatible Prometheus data supports history at cluster, namespace, application, and workload level. Kubecost supplies the retained cluster and namespace trend from its Aggregator; workload and application history are not available through that path.

​
Request guidance

The workload Cost tab can also show Rightsizing. Rightsizing uses Prometheus demand evidence to evaluate one workload’s configured requests. It is separate from OpenCost allocation accounting and does not claim guaranteed savings.

​
Choose a cost source

Auto is the default. Radar keeps working OpenCost-compatible data from its discovered Prometheus. If representative cost metrics are absent, it looks for a Kubecost 3 Aggregator in the connected cluster. The Cost view appears only after a source returns usable current allocation data. You can pin the source to Prometheus or Kubecost under Settings → Cost. Auto and Kubecost are tested before Radar saves the selection. Prometheus can be saved before its cost metrics are installed, which supports staged installations.

​
OpenCost-compatible Prometheus

Radar uses its automatically discovered Prometheus or the endpoint configured with --prometheus-url. OpenCost or Kubecost must expose allocation metrics to that Prometheus.

​
Kubecost in the connected cluster

Radar discovers an active Kubecost 3 Aggregator StatefulSet and its matching Service. It tries the Service’s named tcp-api port 9004 first. If that endpoint rejects unauthenticated access and no API key is configured, Radar can retry the same Service’s exact tcp-api-rbac port 9008, which Kubecost exposes for internal clients when SAML or OIDC is enabled. A Service exposing only port 9008 is not auto-discovered; configure that endpoint explicitly. Local Radar opens a scoped port-forward to the selected port. In-cluster Radar uses Service DNS. A configured API key is never bypassed through port 9008: if the key is rejected, Radar reports the authentication failure.

​
Central or federated Kubecost

A cluster running only the Kubecost FinOps Agent has no local Aggregator for Radar to discover. Configure the central Aggregator URL and the exact cluster ID in Settings → Cost or through Helm. Radar accepts a root API URL or one ending in /model. Add a Kubecost service-account API key when the endpoint requires one.

​
In-cluster Helm controls

Setting cost.source, cost.kubecost.url, cost.kubecost.clusterId, or cost.kubecost.existingSecret through Helm makes the source, URL, cluster ID, and API-key controls environment-managed and read-only in Settings. cost.kubecost.existingSecretKey only selects the key within a configured Secret; its api-key default does not lock those controls. cost.currency is managed independently and makes only the display-currency control read-only when configured through Helm.

​
Common gaps

Some cost categories require additional provider or cost-tool configuration:
  • GPU pricing - requires GPU pricing data.
  • Cloud egress - requires cloud-provider integration.
  • Persistent volumes - requires storage-class pricing.
  • Spot vs. on-demand - requires provider and node metadata.

​
Limitations

  • Radar does not change requests, instance types, or running workloads.
  • Workload and application cost currently focus on steady-state Deployment, StatefulSet, and DaemonSet workloads.
  • Batch workload, storage, and network attribution may remain at namespace or cluster level.
  • OSS cost data is per cluster. Radar Cloud provides fleet views.

​
See also