Request versus usage drift
CPU and memory requests that no longer match what containers consume. Over-requesting wastes node capacity that every other team pays for.
- CPU request versus measured usage
- Memory request versus measured usage
Kubernetes cost management tool
Kubernetes cost management that allocates every container dollar to a team
Varcio is a Kubernetes cost management and allocation tool that maps container cost to namespace, deployment and team using Kubecost, OpenCost, the native Kubernetes API or its bundled in-cluster agent. Fourteen Kubernetes detectors flag request drift, idle pods, spot candidates, bin-packing headroom and orphaned volumes, with rightsizing based on measured utilisation rather than requests alone.
14Kubernetes detectors, plus 23 cross-cloud detectors on the shared ledger
4 modesKubecost, OpenCost, the native Kubernetes API or the bundled agent
Read-onlyThe complete analytical product runs on read-only credentials
Opt-inWrite-back through the agent is off unless you enable it, and every change needs approval
Detection
What Varcio finds on Kubernetes
Kubernetes hides cost behind shared nodes. 14 detectors and namespace-level allocation make it visible, attributable and fixable.
A cloud bill shows the nodes, not the workloads. Every team shares the same instances, so the invoice cannot tell you which namespace is responsible for growth, and scheduling works on requests, which are often set once and never revisited. The result is clusters sized for requests that bear little relation to what containers actually use.
Varcio maps container cost to namespace, deployment and team, and rightsizes from measured utilisation rather than requests alone. Each finding carries an estimated monthly saving, confidence, effort, risk and a recommended action, ranked in the same queue as findings from your cloud accounts.
Idle pods
Running pods whose actual CPU and memory use is near zero while they still reserve their requested capacity on the node.
- Idle pods still reserving requests
Spot and bin-packing
Workloads suited to cheaper spot capacity, and nodes with enough headroom that pods could run on fewer of them. These checks use the native Kubernetes API connection.
- Spot candidates for batch and worker workloads
- Node bin-packing headroom
Cluster objects and storage
With the native Kubernetes API connection, Varcio also inspects cluster objects directly, including storage that still bills after its workload has gone.
- DaemonSet overhead
- Orphaned Persistent Volumes and PVC utilisation gaps
- LoadBalancer services without endpoints
- Missing requests or limits, and privileged containers
Allocation and showback
Container cost attributed to namespace, deployment and team, with team taken from team, owner or cost-center labels, so shared cluster spend can be reported and charged back.
- Cost by namespace
- Cost by deployment
- Cost by team
Cluster cost in cloud context
Kubernetes cost sits in the same ledger as AWS, Azure, Google Cloud and OCI, where 23 cross-cloud detectors look for duplicated environments.
- Clusters next to cloud account spend
- Duplicated environments spanning clouds
The signals behind Kubernetes findings
Which signals Varcio can use depends on how the cluster is connected. Kubecost, OpenCost and agent data drive allocation, rightsizing and idle-pod findings; the native Kubernetes API adds node and cluster-object checks.
- Allocation data
Cost by namespace, deployment and team from Kubecost, OpenCost, the agent or the native API, used to find growth that is not matched by demand.
- Measured utilisation
CPU and memory requests compared with measured usage to find drift and idle pods. The agent reads usage from metrics-server.
- Node profiles (native API)
Node capacity and pricing, used to find spot candidates and bin-packing headroom.
- Cluster objects (native API)
DaemonSets, Persistent Volumes and claims, services and endpoints, and container settings such as requests, limits and privileged mode.
Connection
How Varcio connects to Kubernetes
Use the cost engine you already run, connect to the Kubernetes API, or install the bundled agent. Only the agent works without Varcio reaching an endpoint in your environment.
Kubecost or OpenCost
If your clusters already run Kubecost, or OpenCost, the vendor-neutral CNCF incubating project, Varcio reads allocation data from it, so you keep your existing installation. The Kubecost or OpenCost endpoint must be reachable from Varcio.
Native Kubernetes API
Varcio connects to the cluster API with a bearer token you provide. This mode adds the node and cluster-object detectors, such as spot candidates, DaemonSet overhead, orphaned volumes and privileged containers, and needs an API endpoint Varcio can reach.
Bundled in-cluster agent
The agent runs inside the cluster, reads usage from metrics-server and pushes metrics outbound, so there are no ports to open and no API server to expose. Its cluster role is read-only on pods, nodes, namespaces and pod metrics. The agent is available on Business and Enterprise plans.
Read-only first
Allocation, findings, forecasting, anomaly detection and Apex questions run on read-only access indefinitely. Write-back through the agent is optional and stays off unless you enable it.
If the cloud accounts that host your nodes are also connected, cluster cost and the underlying cloud spend sit in the same ledger.
Remediation
From finding to fix, with guardrails
Most Kubernetes changes land through manifests and pipelines. Varcio fits that flow, and can also apply approved changes through its agent.
A rightsizing finding gives the owning team the measured usage, the current requests and a costed recommendation. Many teams apply that change where they already manage workloads — manifests, Helm values or a GitOps repository — so the fix is reviewed like any other change. Where infrastructure is defined in Terraform, PR cost review shows the cost delta on the pull request before merge.
If you prefer, the agent can apply the change. Write-back is off unless you explicitly enable it and grant the agent permission to patch Deployments. Each change is queued as an approval request, and the agent applies it only after approval; rolling back is a new action in the opposite direction.
Example actions on Kubernetes
- Set CPU and memory requests on a Deployment
- Scale an idle Deployment to zero
- Restore replicas after scaling to zero
Guardrails every remediation inherits
These controls apply to all remediation Varcio executes, on every cloud, alongside the write permissions you grant and Varcio verifies before anything changes.
Protected-tag exemption
Resources carrying a protected tag are excluded from every remediation run, so a production database or a regulated workload cannot be changed by a rule that happens to match it.
Execution windows
Approved changes run only inside the windows you define, which keeps stops, deletions and resizes away from peak traffic, release trains and change freezes.
Rollout-safety gates
Before a live run, Varcio checks for step-up approval on high blast-radius changes, a rollback success floor, and a maintenance window for larger blast radius. If a gate is not met, the run drops to a dry run instead.
Dry run, action caps and budgets
Any action can be previewed without making live API calls, and individual rules can be held to dry run. Per-rule action caps, a maximum number of actions per run and a monthly action budget bound how much changes at once.
Approval, and Autopilot limits
Write actions requested through Apex come back as a plan that runs only after an authorised person types APPROVE, backed by a single-use token, or approves from Slack or Microsoft Teams. Autopilot runs in observe, suggest or autopilot mode. In autopilot mode it can act without a person above a confidence threshold, including deleting unattached volumes and orphaned snapshots, but resources that look production, public, critical or deletion-protected go to approval instead.
Full audit logging
Every action records who requested it, who approved it, what changed and when, so finance, security and auditors can reconstruct any change after the fact.
Native tools
OpenCost, Kubecost and Varcio
OpenCost and Kubecost are established Kubernetes cost tools, and Varcio can use either as a data source. Here is what each provides, according to their documentation.
OpenCost
A vendor-neutral open source project, created by Kubecost and now a CNCF incubating project, for measuring and allocating container and cloud infrastructure costs by namespace, pod and label, with cloud billing integration and a published OpenCost Specification.
IBM Kubecost
Kubernetes cost allocation across clusters, teams, namespaces, workloads and shared resources, reconciliation with cloud provider bills, rightsizing recommendations across containers, nodes and storage, and budgets, anomaly detection and forecasting.
| Capability | OpenCost and Kubecost | Varcio |
|---|---|---|
| Allocation | OpenCost by namespace, pod and label; Kubecost across clusters, teams, namespaces, workloads and shared resources | Namespace, deployment and team, in the same ledger as cloud account spend |
| Cloud billing context | OpenCost cloud billing integration; Kubecost reconciliation with cloud bills | Cluster cost alongside AWS, Azure, Google Cloud and OCI, with 23 cross-cloud detectors |
| Rightsizing | Kubecost recommendations across containers, nodes and storage | 14 detectors, with rightsizing from measured utilisation rather than requests alone |
| Alerts and forecasting | Kubecost budgets, anomaly detection and forecasting | Anomaly detection, forecasting and policy guardrails, with alerts in Slack or Teams |
| Data source | Runs in your cluster | Reads Kubecost, OpenCost or the native Kubernetes API, or receives metrics pushed outbound by the bundled agent |
| Acting on findings | Changes applied through manifests, Helm or GitOps | Optional, approval-gated write-back through the agent: set requests, scale to zero, restore replicas |
| Beyond the cluster | Focused on Kubernetes cost | Cloud waste detection, PR cost review, approval-gated remediation and Apex across the whole estate |
Scroll sideways to see the full table.
What Varcio adds
For a team that needs cost allocation inside its clusters and nothing more, OpenCost may be all that is required, and Kubecost adds a broader commercial feature set on top. Varcio is built for organisations where Kubernetes is one part of a larger cost picture.
Varcio combines cluster cost with cloud account spend in one ledger, ranks Kubernetes findings with cloud findings by savings, confidence and effort, applies tag governance, allocation and policies across both, and routes findings and approvals through Slack or Teams. Because it can read from Kubecost or OpenCost, adopting Varcio does not mean replacing what already works.
Teams
Who uses Varcio for Kubernetes
Cost is shared work. Each team sees the same findings and ledger, framed for the decisions it owns.
Platform engineering
Sees which namespaces and deployments are over-requesting, with measured usage as evidence, and gives application teams specific, costed rightsizing changes.
FinOps and finance
Allocates shared cluster cost to teams for showback or chargeback, using the same model as cloud account spend.
SRE and operations
Tracks idle pods, DaemonSet overhead and orphaned volumes, and receives anomalies and approvals in Slack or Teams.
Engineering leadership
Understands what each team’s services cost to run on shared clusters, and plans rightsizing work from a ranked backlog.
FAQ
Kubernetes cost questions, answered
How do I reduce Kubernetes costs?
Bring CPU and memory requests into line with measured usage, since requests drive how many nodes you need. Remove idle pods that reserve capacity without using it, review DaemonSets whose cost scales with node count, look for spot candidates and bin-packing headroom, and delete orphaned Persistent Volumes that still bill for storage. Then allocate cost to namespaces and teams so owners see and act on their share. Varcio automates this with 14 Kubernetes detectors and namespace, deployment and team allocation.
How do I allocate Kubernetes costs to teams?
Attribute container cost to namespaces and deployments, map those to owning teams through labels, and report it as showback or chargeback. Varcio maps container cost to namespace, deployment and team, taking team from team, owner or cost-center labels, with Kubecost, OpenCost, the native Kubernetes API or its bundled agent as the source.
Do I need Kubecost or OpenCost to use Varcio?
No. Varcio can use an existing Kubecost or OpenCost installation, connect to the Kubernetes API with a bearer token, or receive metrics from its bundled in-cluster agent. The agent needs metrics-server and is available on Business and Enterprise plans.
Does the Varcio agent need inbound access to my cluster?
No. The bundled agent pushes metrics outbound, so no inbound access to the cluster is needed, and its cluster role only reads pods, nodes, namespaces and pod metrics. The Kubecost, OpenCost and native Kubernetes API modes are different: they need an endpoint that Varcio can reach.
Can Varcio change workloads in my cluster?
Only if you enable write-back. It is off by default, and turning it on means granting the agent permission to patch Deployments. The agent can then set requests, scale an idle Deployment to zero or restore replicas, and each change runs only after it has been approved.
Why rightsize from measured utilisation instead of requests?
Requests are what a team asked for, often set once at deployment. The scheduler reserves capacity based on them, so over-requesting forces extra nodes even when containers use far less. Rightsizing from measured utilisation shows what workloads actually need.
Is OpenCost enough on its own?
For in-cluster cost allocation, OpenCost may be sufficient. It is an open source CNCF incubating project that allocates cost by namespace, pod and label. Teams add Varcio when they need Kubernetes cost combined with cloud spend, ranked findings, cross-cloud detection, governance and approval workflows.
Can I see Kubernetes cost next to AWS, Azure and Google Cloud spend?
Yes. Kubernetes cost sits in the same normalised ledger as AWS, Azure, Google Cloud and OCI, and 23 cross-cloud detectors run across it.
Allocate your cluster costs by team
Connect Kubecost, OpenCost, the Kubernetes API or the outbound-only agent and see container cost by namespace, deployment and team.