Table of Contents

Written By

Asaf Liveanu
Co-Founder & CPO
Asaf is the CPO and co-founder of Finout. He has more than 12 years of experience in software engineering, QA and product management at companies like Taboola and Intel. In his last position at Logz.io, he met Roi, and together they decided to embark on the Finout journey.

Finout now delivers Kubernetes cost allocation for managed Red Hat OpenShift clusters- on ROSA (Red Hat OpenShift Service on AWS) and ARO (Azure Red Hat OpenShift).

What OpenShift Is

Red Hat OpenShift is an enterprise Kubernetes platform. Standard Kubernetes runs underneath it, packaged with the pieces an enterprise would otherwise assemble and maintain itself: a hardened security model, a container image registry, built-in CI/CD and GitOps pipelines, its own monitoring and observability stack, a developer console, and one Red Hat support contract behind all of it.

The short version: Kubernetes is the engine. OpenShift is the supported, audited, batteries-included car built around it.

ROSA and ARO are the infrastructure OpenShift runs on- the managed AWS and Azure offerings, operated jointly with Red Hat, so you don't run the control plane yourself. They're how most enterprises land OpenShift in the cloud.

What It's Mostly Used For

Regulated workloads are the main use case. Financial services, insurance, healthcare, telco, government, airlines- environments where an auditable platform with a named vendor behind it matters more than using the cloud's own Kubernetes service.

Three other patterns cover most of the rest:

  • Application modernization. Moving long-lived Java, JBoss and VM-based applications into containers. OpenShift is the standard destination for programs whose goal is getting off a legacy estate.
  • Hybrid consistency. The same platform runs in the data center and on AWS, Azure and GCP. One operational model for organizations that can't or won't standardize on a single cloud- usually the deciding factor over EKS or AKS.
  • Platform engineering. A central team gives internal developers a paved road with guardrails, instead of every team wiring up its own Kubernetes.

Increasingly, it also hosts AI and ML workloads, which is where the cost curve gets steep fastest.

Why This Matters For FinOps

On the cloud bill, a managed OpenShift cluster does not appear as Kubernetes. It appears as compute resource- EC2 instances on ROSA, Azure VMs on ARO- with worker, infrastructure and control-plane nodes all summarized into a single instance cost and no breakdown underneath it. Alongside that sits a separate license or service fee: the ROSA service fee on AWS, the OpenShift license fee on ARO worker nodes.

Nothing in that breakdown tells you which namespace, workload, team, or business unit consumed the capacity, and because the cloud providers' native Kubernetes cost features are built around their own managed Kubernetes services, OpenShift clusters fall outside them. So the platform carrying the most compliance-sensitive workloads in the estate- often the single largest container line item- ends up allocated by estimate, by headcount, or by whoever argues hardest in the meeting. That is now fixed.

How The Integration Works

Finout reads the cluster's Prometheus metrics from OpenShift, the monitoring stack it already runs- so there's no second stack to stand up. The integration is per cluster.

  1. You deploy a Finout CronJob in each cluster. It connects to that cluster's OpenShift Prometheus endpoint using a bearer token.
  2. Every 30 minutes, the CronJob queries the container request and usage metrics: CPU, memory, and network
  3. It writes metric files to an S3 bucket you own and control.
  4. Finout joins those metrics to the cloud bill and allocates the cluster's compute and network cost per namespace, label, and workload, in the same MegaBill as the rest of your spend.

Allocation is built from aggregated container metrics and surfaced at the namespace, workload, and label level. Multiple clusters sharing the same configuration can write to the same bucket and prefix.

What You Can Do With It

  • Show back and charge back OpenShift cost to the namespace, workload or team that generated it
  • Apply Virtual Tags to OpenShift cost the same way you do to every other source, with no cloud-provider tagging work
  • Bring OpenShift into the same views, budgets and reports as the rest of your Kubernetes and cloud spend
  • See where requested capacity is running far ahead of what workloads actually use

Requirements

  • kube-state-metrics 2.0.2 or later, with the required label allowlist flags enabled
  • An S3 bucket with write, read and delete permissions in the CronJob's IAM policy
  • Network connectivity from cluster pods to the Prometheus endpoint
  • Endpoint authentication — a bearer token for the OpenShift Prometheus endpoint

Kubernetes cost data appears in Finout within two days, in line with cloud billing latency.

Get started: OpenShift Kubernetes Integration, or talk to your CSM.
Adopt the new standard for
cloud & AI spend
Start free trial now