> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Kubernetes Cost

> Attribute Kubernetes spend to the teams that cause it, then turn the waste into right-sizing and placement changes you approve.

Kubernetes Cost owns the gap between what your clusters cost and what anyone can account for. It attributes
spend to the namespaces, labels, and teams that generate it, then converts the waste it finds into
specific right-sizing and placement changes. This page covers the outcome the module owns, the three
workflows inside it, what it needs connected, and what it produces.

## What this module owns

Kubernetes makes over-provisioning the rational choice for every individual team. Requests are set
generously because the cost of being wrong downward is a page and the cost of being wrong upward is
invisible. Multiply that by every workload and you get a cluster bill nobody can attribute and
nobody feels responsible for.

The work of fixing it is not hard, it is just relentless: pull utilization against requests per
workload, decide which gaps are real headroom and which are waste, propose new numbers, and get
someone to apply them. This module runs that loop continuously — and because it also runs the
attribution, the proposal arrives at the team that owns the workload rather than at a platform
engineer holding a spreadsheet.

Good looks like spend that lands on a named owner, usage-based waste estimates and projected
savings attributed to the workload's owner, and every applied change traceable to the finding that
justified it.

## The workflows inside it

This module contains **3 workflows**.

### Cost allocation

| Step                 | What happens                                   |
| -------------------- | ---------------------------------------------- |
| **1 · Usage ingest** | Pulls cluster usage and cloud spend.           |
| **2 · Attribution**  | Allocates spend by namespace, label, and team. |
| **3 · Showback**     | Produces a per-team showback report.           |

### Right-sizing

| Step                    | What happens                                                                                                                                                     |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1 · Usage ingest**    | Pulls per-workload utilization against requests.                                                                                                                 |
| **2 · Waste detection** | Flags over-provisioned and idle workloads, with a waste estimate. The idle detector handles the barely-used workloads; the right-sizing analyzer takes the rest. |
| **3 · Recommendation**  | Proposes new requests and limits with the savings they would produce.                                                                                            |
| **4 · Apply**           | Opens a pull request or applies the change, within the autonomy you allowed.                                                                                     |

### Pod placement

| Step                        | What happens                                                                                        |
| --------------------------- | --------------------------------------------------------------------------------------------------- |
| **1 · Scheduling analysis** | Analyzes pod-to-node packing and node utilization.                                                  |
| **2 · Waste detection**     | Flags under-packed nodes and fragmentation.                                                         |
| **3 · Recommendation**      | Proposes placement, node-pool, or affinity changes.                                                 |
| **4 · Apply**               | Applies the placement change within autonomy scope, draining safely before anything is rescheduled. |

<Note>
  Nothing in this module mutates production without a human decision: the apply steps are
  approve-then-run, and a right-sizing recommendation is graded by a cost-efficiency judge before it
  reaches you.
</Note>

## What it needs connected

| Requirement                    | Why                                                                                                   | Where to set it up                                                       |
| ------------------------------ | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Kubernetes access              | The module reads cluster metrics, workload requests, and scheduler state                              | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
| Cloud billing                  | Attribution needs the spend side, not just the usage side                                             | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
| A scoped write credential      | Applying new requests or a placement change is a cluster write, bound to the agent allowed to make it | [Credentials & secrets](/manage-your-agents/build/credentials-secrets)   |
| A source repository (optional) | So a right-sizing change can arrive as a pull request against your manifests instead of a live edit   | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |

## Enabling it

<Steps>
  <Step title="Open Modules → Overview">
    Kubernetes Cost appears in the Cost Optimization family with the three workflows it contains.
  </Step>

  <Step title="Turn it on">
    Enabling the module adds Kubernetes Cost to your sidebar, with its cost findings list.
  </Step>

  <Step title="Connect a cluster and set the autonomy you want">
    Point the ingest steps at your clusters and billing, then decide whether the apply step opens a
    pull request or applies within scope.
  </Step>
</Steps>

## What you see when it runs

The module's sidebar entry lists cost findings. Each one carries the workload it belongs to, the
waste estimate behind it, the recommendation with its projected savings, and — once you accept —
the change itself, with a link to the pull request where one was opened.

Showback reports appear as their own records, so a per-team number has the run that produced it
attached rather than being a figure in a slide.

## Next steps

<CardGroup cols={2}>
  <Card title="Cloud Cost" href="/modules-and-workflows/cost-optimization/cloud-optimization">
    The same loop one layer down, on your cloud vendor bill.
  </Card>

  <Card title="Approvals" href="/security-and-governance/controls/approvals">
    How an apply step waits for a human decision.
  </Card>

  <Card title="Evaluations" href="/manage-your-agents/optimize/evaluations">
    The judge that grades a cost recommendation.
  </Card>

  <Card title="Agent spend & attribution" href="/manage-your-agents/optimize/agent-spend-attribution">
    What the fleet doing this work costs you.
  </Card>
</CardGroup>


## Related topics

- [Cloud Cost](/modules-and-workflows/cost-optimization/cloud-optimization.md)
- [Azure Investigator](/manage-your-agents/build/catalog/azure-investigator.md)
- [AWS Cost Analyzer](/manage-your-agents/build/catalog/aws-cost-analyzer.md)
- [Kubernetes RCA](/manage-your-agents/build/catalog/kubernetes-rca.md)
- [Agent catalog](/manage-your-agents/build/catalog/overview.md)