Kubernetes FinOps & Cost Optimization

Kubernetes FinOps is the practice of making cluster spend visible, reducible and durable. It follows the FinOps Foundation's Inform, Optimize, Operate loop: allocate spend to the teams and applications that generate it, act on the waste that allocation exposes, then wire the discipline into the platform so the savings do not decay. On Kubernetes it is specific work — requests and limits, autoscaling policy, spot capacity, and namespace-level cost attribution — not a generic cloud cost review.

The cluster autoscaler scales node groups you defined in advance, so your savings are capped by how well you guessed the instance mix. Karpenter provisions nodes to fit the pods that are actually pending, choosing instance type, size and purchase option per workload, and it consolidates — it notices when the same pods would fit on cheaper or fewer nodes and rebuilds the fleet to match. That consolidation loop is where most of the recurring saving comes from, because it keeps working after the engagement ends. The trade-off is churn: nodes are replaced more often, so PodDisruptionBudgets and graceful shutdown have to be right before you turn it on.

No, and we would rather say so up front. Karpenter has production providers for AWS and Azure; there is no OVHcloud or Scaleway provider. On those platforms the cost work is the same discipline through different mechanics: the managed cluster autoscaler tuned against a realistic node-pool design, rightsizing driven by measured consumption rather than inherited defaults, and spot or preemptible capacity where the workload tolerates reclaim. The allocation and governance layers — OpenCost, policy as code — are provider-agnostic and behave identically. In our experience rightsizing alone usually returns more than autoscaler choice does, so the OVHcloud and Scaleway path is not a consolation prize.

Cost becomes a signal on the same dashboards as everything else. OpenCost, a CNCF project, allocates real cloud spend down to namespace, controller and pod, and we export it to Prometheus so cost sits beside latency and error rate rather than in a finance tool nobody on the team opens. From there you get per-namespace spend with an owner, alerts on cost anomalies and idle-resource percentage, and a monthly number each team recognises as theirs. Visibility with ownership is what stops the bill drifting back.

It is what makes the saving durable rather than seasonal. Autoscaling policy, resource requests, NodePool definitions and cost guardrails all live in the same repository as the rest of the platform, reconciled by Argo CD. A change to the cost posture is a reviewed pull request with an audit trail, not a console edit somebody forgets. Policy as code with Kyverno holds the line underneath: reject workloads with no requests, block the instance families you have decided not to pay for, require the team label that allocation depends on.