Skip to main content
This lesson focuses on money: what drives Kubernetes costs, how to make those costs visible, and practical ways to reduce them. Everything covered earlier in the course has cost implications; this lesson gives you a framework and tools to answer who, what, and where the money is going — and what to do about it. A mid‑sized SaaS company saw its monthly Kubernetes cloud bill rise from 30,000to30,000 to 120,000 in a year. Finance showed a single line item: $84,000 in EC2 charges. The platform team could not map that charge to teams, namespaces, or workloads — so the CTO could not know which engineering teams or workloads were responsible or whether the usage was justified.
A slide titled "The Problem" showing a highlighted cost box reading "Total EC2: $84,000." Below are three numbered question boxes asking which of the 15 engineering teams consumed the resources, which workloads were responsible, and whether the usage was justified or wasteful.
The practical solution is namespace-level cost allocation: attribute node, storage, and network costs to namespaces (or labels) so you can identify which teams and workloads drive spend. With that visibility you can systematically eliminate unused capacity and right‑size resources. The solution looks like this in practice: map cloud billing to Kubernetes constructs, then use that insight to right‑size and reclaim unused capacity.
A presentation slide titled "The Solution" showing two connected rounded boxes: one recommends implementing namespace-level cost allocation to see which teams and workloads drive spend, and the other advises using that insight to right-size resources and eliminate unused capacity, with a central icon linking them.
What drives Kubernetes costs? Use the following prioritized categories to focus your optimization efforts. Compute is typically the largest opportunity.
A slide titled "What Drives Kubernetes Costs?" showing three main cost categories—Compute (60–70%), Storage (15–25%) and Network (10–20%)—with bullet points explaining examples and drivers for each (worker node/CPU provisioning, persistent volumes/snapshots, and load balancers/data transfer).
The number‑one cost driver is provisioned capacity you do not actually use — the gap between node capacity and actual workload consumption. Many organizations see 40–60% of their provisioned compute idle. Closing that gap is the highest‑leverage optimization. Visibility is the blocker: cloud bills are organized by infrastructure resources (EC2, EBS, ELB, Data Transfer), not by teams, namespaces, or applications. That makes it impossible to answer questions like:
  • How much does the Payments team cost?
  • Which namespace is wasting the most resources?
  • Are we over‑provisioned or under‑provisioned?
You need a tool that understands both the cloud pricing model and Kubernetes resource constructs (pods, namespaces, labels) to bridge this gap.
A slide titled "The Visibility Problem" showing a "Typical Cloud Bill" breakdown (EC2 50,000; EBS 12,000; ELB 3,000; Data Transfer 8,000; Total $73,000). To the right are three numbered questions about cost visibility: how much the payments team costs, which namespace wastes resources, and whether resources are over- or under-provisioned.
That bridging tool is OpenCost — an open-source, vendor-neutral project that runs in your cluster, scrapes resource usage, applies cloud prices, and exposes dollar‑based metrics scoped to pods, namespaces, and labels.
A slide titled "The Visibility Problem" showing Cloud Billing (infrastructure level) on the left and Kubernetes Usage (platform level) on the right, with a dotted bridge and the OpenCost logo in the center implying it connects the two.
OpenCost runs as a pod in your cluster, scrapes usage from the Kubernetes Metrics API or Prometheus (if available), and overlays that usage with cloud pricing to produce dollar-cost metrics for pods, namespaces, and labels.
OpenCost gives three core capabilities that solve the visibility problem:
  1. Cost allocation by namespace or label — attribute node and storage costs to teams and applications so finance and engineering can see true spend per owner.
  2. Resource efficiency metrics — show actual CPU/memory usage vs. requested resources, which is the basis for right‑sizing.
  3. Real‑time and historical cost trends — detect spikes, regressions, and long‑term trends to prioritize remediation.
The OpenCost dashboard makes these outputs actionable: each row is a namespace (often mapping to a team), and you can filter or aggregate by label to see compute, storage, and network dollars attributed to that namespace.
A screenshot of an OpenCost "Kubernetes Cost Visibility" dashboard showing cost allocation by namespace (Last 7 days), with a chart and a table listing namespaces, resource costs and an "Efficiency" column highlighted. Most costs shown are $0 and efficiency percentages are small.
Focus on the efficiency metric: percentage of requested resources that are actually used. Example interpretation:
  • CPU efficiency 15% = pods requested ~7× more CPU than they used → big waste.
  • CPU efficiency 70% = reasonable balance of cost and headroom.
  • CPU efficiency 240% = workload is under‑requested and may encounter throttling or instability.
How OpenCost calculates costs OpenCost follows a three‑step process:
  1. Get cloud pricing — compute cost-per-CPU-hour and per-GB-hour for node types and storage classes.
  2. Measure pod resource usage — collect actual CPU and memory consumption from the metrics source.
  3. Aggregate costs — allocate node/storage costs to pods using a chosen strategy (requests, usage, or the higher of the two), then sum by namespace or labels (for example, team=Payments across multiple namespaces).
This produces actionable outputs such as “Payments costs $2,400/month,” which lets finance allocate costs to business units and platform teams prioritize right‑sizing.
A presentation slide titled "Cost Allocation by Namespace" showing a three-step process: 01 Get cloud pricing, 02 Measure pod resource usage, and 03 Aggregate costs. A callout lists steps to sum pod costs by namespace, optionally aggregate by labels (e.g., team), and produce total cost per team or application.
OpenCost also measures efficiency as Actual Usage ÷ Requested. Here are three practical scenarios:
A slide titled "Efficiency: Requested vs Used" showing three cases—Over-Provisioned (requested 4 CPU, actual 0.5, 12.5% efficient), Right-Sized (1 CPU requested, 0.7 used, 70% efficient), and Under-Provisioned (0.5 requested, 1.2 used, 240% efficient).
  • Over‑provisioned (low efficiency): requested 4 CPU, actual 0.5 CPU → 12.5% efficiency. Most waste lives here.
  • Right‑sized (target zone): requested 1 CPU, actual 0.7 CPU → 70% efficiency. Good balance of cost and headroom.
  • Under‑provisioned (high efficiency): requested 0.5 CPU, actual 1.2 CPU → 240% efficiency. Risk of throttling / instability.
Target range: 60–80% efficiency. Below 50% indicates substantial, recoverable waste. Above 90% leaves little headroom for spikes and increases the risk of resource contention.
An infographic titled "Efficiency: Requested vs Used" showing a color-coded horizontal bar with three zones: pink "Below 50%" (Wasted Money), green "60–80%" (Target Zone), and orange "90%" (High Risk). A caption notes OpenCost shows where each namespace falls on this cost-efficiency spectrum.
How to reduce costs — a practical roadmap Cost reduction is continuous and should be prioritized by dollar impact. Focus on compute first — it usually accounts for the largest share.
A presentation slide titled "Cost Reduction Strategies" with three colored columns labeled Quick Wins, Medium Term, and Long Term. Each column lists actionable items like right-sizing requests, deleting idle workloads, using spot/preemptible nodes and autoscaling, reserved instances, cost-aware architecture, team accountability, and budgets/alerts.
Combine visibility with governance:
  • Use resource quotas and limit ranges to prevent accidental overconsumption.
  • Use namespace/label cost allocation to show teams their true spend.
  • Let teams own budgets and alerts; incentivize optimization through reporting and periodic reviews.
When visibility (OpenCost) and governance (quotas, budgets, alerts) are combined, teams can self‑optimize and cost reduction becomes part of normal engineering practice rather than an ad‑hoc project. Key takeaways
A slide titled "Key Takeaways" showing five numbered points about Kubernetes cost optimization (focus on compute utilization and right‑sizing, using OpenCost for namespace-level visibility, target 60–80% efficiency, combine visibility with quotas, and treat cost optimization as ongoing). The items are listed alongside colorful numbered markers on a blue-green gradient sidebar.
  • Focus on compute utilization and right‑sizing — this yields the largest, most immediate savings.
  • Use OpenCost (or an equivalent) for namespace‑level visibility to map cloud billing to Kubernetes usage.
  • Target 60–80% efficiency; < 50% is wasteful, > 90% is risky.
  • Combine visibility with governance (quotas, budgets, alerts) so teams can self‑manage costs.
  • Treat cost optimization as continuous: prioritize quick wins, deliver medium‑term improvements, and invest in long‑term cultural change.
References and further reading This concludes the section on architecture, resources, multi‑tenancy, governance, storage, networking, and cost.

Watch Video