Meeting schedule​

Every 2nd Thursday at 10:00 AM EST, we hold an OpenCost community meeting. To support collaboration across time zones, starting March 5, 2026 we will alternate between two sessions each month:

• One EMEA/APAC-focused meeting at 10:00 AM EST (15:00 UTC) (best for Europe, Middle East, Africa, and Asia-Pacific): This meeting will be held March 5, and every 4 weeks after that
• One Americas-focused meeting at 4:00 PM EST (21:00 UTC) (best for Americas): This meeting will be held March 19, and every 4 weeks after that

So each month there will be one meeting optimized for NA and one for EMEA/APAC, making it easier to attend from your region.

How to join​

• View Both Meetings on the Public Calendar (Self-Service)
  View the full schedule with both meetings, and add meetings to your own calendar:
  OpenCost meetings – week view

• Americas Meeting
  Direct join link for the EMEA/APAC session:
  Join the Americas OpenCost Community Meeting

• EMEA/APAC Meeting
  Direct join link for the EMEA/APAC session:
  Join the EMEA/APAC OpenCost Community Meeting

Why are we splitting the meetings?​

OpenCost is used and contributed to from many regions. Holding one NA and one EMEA/APAC meeting per month gives each region a slot that’s more workable locally, so more people can join, share feedback, and collaborate without staying up late or getting up very early.

We hope to see you in an upcoming meeting. For more ways to connect, see the Community page.

If you’re new to OpenCost, it is an open-source cost and resources management tool that is an Incubating project in the Cloud Native Computing Foundation (CNCF). It was created by IBM Kubecost and continues to be maintained and supported by IBM Kubecost, Randoli, and a wider community of partners, including the major cloud providers. Aside from AWS, Microsoft, and Google, who have been contributing companies since OpenCost’s inception, we’ll also call out Oracle and DigitalOcean below. If you have further questions, you can find us on Slack or at the regular OpenCost meetings.

OpenCost Releases​

The OpenCost project has had 11 releases in 2025. These include new features and capabilities that improve the experience for both users and contributors. Here are a few highlights:

• Promless: OpenCost can be configured to run without Prometheus, using environment variables which can be set using helm. Users will be able to run OpenCost using the Collector Datasource (beta) which can be run without Prometheus.
• OpenCost MCP server: AI agents can now query cost data in real-time using natural language. They can analyze spending patterns across namespaces, pods, and nodes, generate cost reports and recommendations automatically, and provide other insights from OpenCost data.
• Export System: The project now has a generic Export Framework to make it possible to export cost data in a type-safe way.
• Diagnostics System: OpenCost has a complete diagnostic framework with an interface, runners, and export capabilities.
• Heartbeat System: You can do system health tracking with timestamped heartbeat events for export and more.
• Cloud providers: There are continued improvements for users to track cloud and multi-cloud metrics. We appreciate contributions from Oracle (including providing hosting for the demo at demo.infra.opencost.io) and DigitalOcean (for recent cloud services provider work).

Thanks to our maintainers and contributors who make these releases possible and successful, including our mentees and community contributors as well.

Mentorship and Community management​

Our project has been committed to mentorship through the Linux Foundation for a while, and we continue to have fantastic mentees who bring innovation and support to the community.

• Manas Sivakumar was a summer 2025 mentee and worked on writing Integration tests for OpenCost’s Enterprise readiness. Manas’ work is now part of the OpenCost Integration Testing Pipeline for all future contributions. Manas has been voted in as a Maintainer of the OpenCost Integration Tests sub project!

• Adesh Pal also menteed with us and made a big splash with the OpenCost MCP server. The MCP server is powerful because it now comes by default and needs no configuration. It outputs easily readable markdown on your metrics as well as step-by-step suggestions to make improvements.

• Sparsh Raj has been in our community for a while and has become our most recent mentee. Sparsh has come out already with a blog post on KubeModel, the foundation of OpenCost's Data Model 2.0. Sparsh’s work will meet the needs for a robust and scalable data model that can handle Kubernetes complexity and constantly shifting resources.

• On the community side, Tamao Nakahara was brought in to the IBM Kubecost team for a few months of open source and Developer Experience expertise. Tamao helped organize the regular OpenCost community meetings, leading actions around events, the website, and docs. On the website, Tamao improved the UX for new and returning users, and brought in Ginger Walker to help clean up the docs.

Events and talks​

As a CNCF incubating project, OpenCost participated in the key KubeCon events. Most recently, the team was at KubeCon Atlanta 2025, where maintainer Matt Bolt from IBM Kubecost kicked off the week with a Project lightning talk. During a co-located event that day, Rajith Attapattu, CTO of contributing company Randoli, also gave a talk on OpenCost. Dee Zeis, Rajith, and Tamao also answered questions at the OpenCost kiosk in the Project Pavilion.

Earlier in the year, the team was also at KubeCon London 2025 and KubeCon Japan 2025 giving talks and running the OpenCost kiosks.

2026!​

What’s in store for OpenCost in the coming year? Aside from meeting all of you at future KubeCons, we’re also excited about a few roadmap highlights. As mentioned, our LFX mentee Sparsh is working on KubeModel, which will be important for improvements to OpenCost’s data model. As AI continues to increase in adoption, the team is also working on building out costing features to track AI usage. Finally, supply chain security improvements are a priority.

We’re looking forward to seeing more of you in the community in the next year!

OpenCost is evolving. As Kubernetes environments grow in complexity with pods being recreated, names being reused, and resources constantly shifting, the need for a more robust, scalable data model has become clear. Today, we're excited to introduce KubeModel, the foundation of OpenCost's Data Model 2.0, designed to bring precision, efficiency, and reliability to Kubernetes cost tracking.

The Challenge: Tracking Resources in a Dynamic Environment​

Kubernetes is inherently dynamic. Pods come and go, deployments scale up and down, and resource names can be reused across recreation cycles. Traditional metric tracking that relies solely on resource names struggles in this environment for a number of reasons including:

• Name reuse: When a pod is recreated with the same name, historical cost data can become ambiguous. This is particularly problematic in stateful set pods.
• Resource correlation: Linking metrics across different time windows becomes unreliable.
• Debugging complexity: Without stable identifiers, tracing cost anomalies back to specific resource instances is challenging.

KubeModel addresses these challenges head-on with a comprehensive approach to resource identification and tracking.

What is KubeModel?​

KubeModel is a new data model for Kubernetes resource tracking in OpenCost. It introduces a flat architecture with core resource types that mirror Kubernetes primitives:

• Cluster - The top-level container
• Namespace - Logical resource groupings
• Node - Compute instances with CPU, RAM, and GPU details
• Pod - The fundamental deployment unit
• Container - Individual workload containers
• Owner/Controller - Deployments, StatefulSets, ReplicaSets, DaemonSets, Jobs
• Service - Network service abstractions
• Volume & PVC - Persistent storage resources
• ResourceQuota - Namespace resource limits and requests
• KubeModelSet - A collection of KubeModel resources for a specific time window
• GPU - GPU resource tracking (Coming soon)

Flat Architecture for Performance​

Unlike nested hierarchies, KubeModel maintains a flat map-based structure enabling O(1) lookups while preserving resource relationships through UIDs and references. This design choice prioritizes:

• Fast access: Constant-time lookups regardless of cluster size.
• Clean relationships: Resources reference each other via stable identifiers.
• Efficient serialization: The flat structure translates well to binary formats.
• Use case agnostic: Flexible design supports diverse consumption patterns and applications.

Here's the core KubeModelSet structure that holds all resources for a time window:

core/pkg/model/kubemodel/kubemodel.go

type KubeModelSet struct {
	Metadata   *Metadata              `json:"meta"`
	Window     Window                 `json:"window"`
	Cluster    *Cluster               `json:"cluster"`
	Namespaces map[string]*Namespace  `json:"namespaces"`
	Containers map[string]*Container  `json:"containers,omitempty"`
	Owners     map[string]*Owner      `json:"owners,omitempty"`
	Nodes      map[string]*Node       `json:"nodes,omitempty"`
	Pods       map[string]*Pod        `json:"pods,omitempty"`
	Services   map[string]*Service    `json:"services,omitempty"`
}

Each resource type is stored in a flat map keyed by UID, enabling O(1) lookups while maintaining relationships through UID references between resources.

UID Support: The Heart of Data Model 2.0​

The cornerstone of KubeModel is comprehensive UID (Unique Identifier) support across all Kubernetes resources. Every resource in Kubernetes has a UID - a stable, unique identifier that persists for the lifetime of that specific resource instance.

Figure 1: Prometheus metrics showing UID labels for precise resource identification across queries.

Enhanced Metric Tracking​

With UID support integrated into OpenCost's metrics, we now have:

• Stable resource identification across queries, even when names are reused.
• Improved cost attribution to specific resource instances rather than just names.
• Better multi-cluster support by preventing resource name conflicts.
• Enhanced debugging through stable identifiers throughout the resource lifecycle.

Here's an example of how we track node CPU capacity with UID support:

pkg/metrics/nodemetrics.go

type KubeNodeStatusCapacityCPUCoresMetric struct {
	fqName string
	help   string
	cores  float64
	node   string
	uid    string  // <-- UID field for unique resource identification
}

func newKubeNodeStatusCapacityCPUCoresMetric(fqname string, node string, uid string, cores float64) KubeNodeStatusCapacityCPUCoresMetric {
	return KubeNodeStatusCapacityCPUCoresMetric{
		fqName: fqname,
		help:   "kube_node_status_capacity_cpu_cores Node Capacity CPU Cores",
		cores:  cores,
		node:   node,
		uid:    uid,
	}
}

func (nam KubeNodeStatusCapacityCPUCoresMetric) Write(m *dto.Metric) error {
	m.Gauge = &dto.Gauge{
		Value: &nam.cores,
	}
	m.Label = []*dto.LabelPair{
		{
			Name:  toStringPtr("node"),
			Value: &nam.node,
		},
		{
			Name:  toStringPtr("uid"),
			Value: &nam.uid,
		},
	}
	return nil
}

The uid field is now a first-class citizen in every metric struct. The Write method serializes it as a Prometheus label, ensuring every emitted metric carries its resource's unique identifier for precise tracking.

Implementation Scope​

The UID implementation spans the entire OpenCost stack:

• 61+ metric result types enhanced with UID fields
• 30+ Prometheus queries updated to include UID in aggregation
• 9 resource types with comprehensive UID validation
• 31 metrics covered by integration tests

Resources enhanced include Pods, Deployments, StatefulSets, Services, Namespaces, Nodes, PersistentVolumes, PersistentVolumeClaims, Jobs, and ReplicaSets.

Binary Serialization with Bingen​

KubeModel introduces bingen-annotated Go structs enabling efficient binary serialization. Bingen is OpenCost specific tooling for generating binary serialization code from annotated Go structs. This provides:

• Compact storage: Binary formats are significantly smaller than JSON/YAML
• Fast serialization/deserialization: Critical for high-frequency metric collection
• FinOps-agent integration: Compatible with date-based storage hierarchies (YYYY/MM/DD)

Metric Hydration: Bridging Data Sources​

The metric hydration system populates KubeModelSet instances with data from various sources:

• Prometheus metrics from the costmodel datasource
• Cluster cache transformations for real-time resource state
• Computed values like PublicIPSeconds per node for cloud cost attribution

This creates a unified view of resource metrics that can be serialized, stored, and analyzed efficiently.

Implemented So Far​

KubeModel represents a significant step forward for OpenCost. The foundation has been laid through several contributions:

1. Core resource types and KubeModelSet - The fundamental data structures
2. UID support across all metrics - Stable resource identification
3. Binary serialization pipeline - Efficient storage and transmission

The Road Ahead​

This work is part of a broader effort to modernize OpenCost's architecture, making it more capable of handling the demands of enterprise Kubernetes environments. Upcoming features include:

1. ResourceQuota integration - Tracking namespace-level resource constraints
2. Comprehensive integration tests - Ensuring reliability at scale
3. S3 storage support - Storing compressed KubeModel entries in S3 for scalable, durable, and cost-effective long-term data retention

Get Involved​

KubeModel is being developed in the open, and we welcome contributions. Check out the ongoing work:

• Core KubeModel Introduction
• Flat Architecture with Binary Serialization
• UID Support for K8s Resource Metrics
• ResourceQuotas Support
• Initial KubeModel Proposal

Acknowledgments​

A special thanks to my mentors for their guidance and support throughout this project: Alex Meijer, Sean Holcomb, and Niko Kovacevic.

KubeModel is the next evolution of OpenCost's data infrastructure. As we continue building out Data Model 2.0, we're excited to deliver more accurate, efficient, and reliable Kubernetes cost tracking for the community.

The activities kick off right away with 2 events on Monday, November 10:

• Matt Bolt will deliver the OpenCost Project Lightning Talk Learn Kubernetes Best Practices With OpenCost. Always check the live schedule link for any changes, but currently the talk is scheduled for 2:53pm - 2:58pm EST in Building C | Level 3 | Georgia Ballroom 2. Matt, who is a project founder and maintainers, will give an overview of OpenCost and show the recent OpenCost MCP Server! Matt will be available right after the talk to take questions outside of the ballroom.

• That same evening, join us for a rooftop reception near the KubeCon convention center, Monday 7:00 - 9:00 pm. Come hang out with OpenCost maintainers and members while enjoying the view. Make sure to save your spot so that you can get in.

On Tuesday, come say hello at the OpenCost kiosk in the Project Pavilion. We will be there, Tuesday only, from 10:45 am - 3:00pm. We'd love to hear your use cases and help troubleshoot any issues you may have.

The future of Kubernetes cost management is here, and it's powered by AI. We're excited to announce that OpenCost now includes a built-in Model Context Protocol (MCP) server that enables AI agents to directly access and analyze your Kubernetes cost data. This groundbreaking integration brings intelligent automation to cost optimization, making it easier than ever to understand, predict, and optimize your cloud spending.

Note: This is available as of OpenCost v1.118.

What is Model Context Protocol (MCP)?​

The Model Context Protocol is an open standard introduced by Anthropic in late 2024 that standardizes how AI systems integrate with external tools and data sources. Think of MCP as a universal translator that allows AI agents to seamlessly interact with your infrastructure, databases, and applications.

For OpenCost, this means AI agents can now:

• Query cost data in real-time using natural language
• Analyze spending patterns across namespaces, pods, and nodes
• Generate cost reports and recommendations automatically
• Monitor budget alerts and cost anomalies
• Optimize resource allocation based on historical data

OpenCost MCP Server: Zero-Configuration AI Integration​

The best part? OpenCost's MCP server is enabled by default in every deployment. No additional setup, no complex configuration—just intelligent cost management out of the box.

• ⚙️ Full-Featured: Supports all the filters and features of our battle-tested APIs.

Available MCP Tools​

The OpenCost MCP server provides three powerful tools for AI agents:

1. get_allocation_costs​

Retrieve detailed cost allocation data with advanced filtering and aggregation.

Example Use Cases:

• "Show me the cost breakdown by namespace for the last 7 days"
• "Which pods are consuming the most resources in production?"
• "Compare costs between different nodes in my cluster"

Parameters:

• window (required): Time window (e.g., "7d", "1h", "30m")
• aggregate (optional): Group by namespace, pod, node, etc.
• step (optional): Resolution step size
• accumulate (optional): Whether to accumulate over time
• share_idle (optional): Whether to share idle costs
• include_idle (optional): Whether to include idle resources

2. get_asset_costs​

Access comprehensive asset information including nodes, disks, load balancers, and more.

Example Use Cases:

• "What are my current infrastructure costs?"
• "Show me the cost of all storage volumes"
• "Which load balancers are most expensive?"

Parameters:

• window (required): Time window for cost analysis

Supported Asset Types:

• 🖥️ Node: Compute instances with CPU, RAM, GPU details
• 💾 Disk: Storage volumes with usage and cost breakdown
• ⚖️ LoadBalancer: Load balancer instances with IP and private status
• 🌐 Network: Network-related costs and usage
• ☁️ Cloud: Cloud service costs with credit information
• ☸️ ClusterManagement: Kubernetes cluster management costs

3. get_cloud_costs​

Query cloud cost data with provider, service, and region filtering.

Example Use Cases:

• "How much am I spending on AWS EC2 instances?"
• "Compare costs between different regions"
• "Show me the breakdown of GCP services"

Parameters:

• window (required): Time window
• aggregate (optional): Group by provider, service, region
• provider (optional): Filter by AWS, GCP, Azure, etc.
• service (optional): Filter by specific services
• region (optional): Filter by geographic regions

Example Interaction​

Here's a glimpse of what's possible when you connect an AI agent to OpenCost's MCP server.

Allocation Costs​

A simple prompt asking for "allocation costs for the last 7 days aggregated by namespace" yields a detailed breakdown:

Saving Insights​

The MCP server can also provide actionable saving insights.

Ready to revolutionize your cost management with AI? Deploy OpenCost and start exploring the possibilities with our built-in MCP server.

Getting Started with OpenCost​

In the brief moment before the mentorship started, I was looking up Prometheus queries and Go structs in OpenCost. This was my first time working on a big project in Go, so I was really nervous that I wouldn't be able to keep up. The idea behind my summer was to test every metric exported in the /allocation and /assets API, which were numbers synthesized by OpenCost on top of Prom metrics.

Early Challenges and Breakthroughs​

I was able to breeze through the first couple of tests, but I hit a roadblock when it came to time-aggregated results. OpenCost adopts a bottom-to-top approach, where the rules are applied on the lowest level, the containers, and the results are propagated up from Pods to Namespaces to Nodes. I missed this crucial observation until my mentors pointed it out.

The Persistent Volume Cost Challenge​

My second biggest obstacle came in the form of Persistent Volume Costs. Here, the combined use of Kubernetes UID, Container runtimes, and Pod Claims to Persistent Volume Bytes complicated my debugging process. I eventually managed to break down most of the challenges myself and made the tests pass. This was the only test that ate my mind, but also was the most satisfying to write. I offer a specific example of a test helper function below that helped me make sense of how OpenCost allocates its PVCs:

func buildPodPVCMap(window string, endTime int64, podMap map[PodKey]*PodData, persistentVolumeMap map[string]*PersistentVolume, persistentVolumeClaimMap map[PersistentVolumeClaimKey]*PersistentVolumeClaim, IngestUID bool, podUIDKeyMap map[PodKey][]PodKey, t *testing.T) map[PodKey][]*PersistentVolumeClaim {

	podPVCAllocation, err := queryPodPVCAllocation(window, endTime)  
	if err != nil {  
		t.Fatalf("Error Occurred while querying PromQL pod_pvc_allocation: %v", err)  
	}

	podPVCMap := make(map[PodKey][]*PersistentVolumeClaim)

	for _, podPVCAllocationItem := range podPVCAllocation.Data.Result {

		namespace := podPVCAllocationItem.Metric.Namespace  
		pod := podPVCAllocationItem.Metric.Pod  
		persistentVolumeName := podPVCAllocationItem.Metric.PersistentVolume  
		persistentVolumeClaimName := podPVCAllocationItem.Metric.PersistentVolumeClaim

		if namespace == "" || pod == "" || persistentVolumeName == "" || persistentVolumeClaimName == "" {  
			t.Logf("PV Test: pvc allocation query result missing field")  
			continue  
		}

		podKey := PodKey{  
			Namespace: namespace,  
			Pod:       pod,  
		}

		persistentVolumeClaimKey := PersistentVolumeClaimKey{  
			Namespace:                 namespace,  
			PersistentVolumeClaimName: persistentVolumeClaimName,  
		}

		if _, ok := persistentVolumeMap[persistentVolumeName]; !ok {  
			t.Logf("PV Test: pv missing for pvc allocation query result: %s", persistentVolumeName)  
		}

		pvc, ok := persistentVolumeClaimMap[persistentVolumeClaimKey]  
		if !ok {  
			t.Logf("PV Test: pvc missing for from PVC alloctions prom query: %s", persistentVolumeClaimKey)  
			continue  
		}

		pvc.Mounted = true

		if IngestUID {  
			for _, key := range podUIDKeyMap[podKey] {  
				podPVCMap[key] = append(podPVCMap[key], pvc)  
			}  
		} else {  
			podPVCMap[podKey] = append(podPVCMap[podKey], pvc)  
		}  
	}

	return podPVCMap  
}

Here is a function that builds a podPVC map. The PodPVC map represents all the Persistent VolumeClaims made by a pod. This is useful in particular, when we wish to calculate costs for a Pod incurred by each PV (through a PVC). The PV Claim includes Persistent Volume and Time Allocated information, with this we can calculate costs using the weighted average formula. Notice we apply the PVCs to all Pod UIDs, even if the pod runtimes are separated for a longer time.

Impact and Future Plans​

The most fulfilling part of this summer is that my tests are now run on the OpenCost pipeline. I'm thrilled to think that everyone who wants to make a new change will now have to pass my tests before merging code. My tests run in the context of the OpenCost Integration Testing Pipeline, here:

I want to keep contributing to OpenCost and work my way up to a maintainer. I'm grateful for being given this opportunity and for my mentors, @ameijer and @mbolt35.

At last week’s KubeCon North America, OpenCost shared exciting updates about our project, including our new status as a CNCF Incubating Project! This milestone underscores our commitment to open-source excellence and the trust the community has placed in OpenCost as a leading solution for Kubernetes cost management. In this post, we’ll recap the Kubecon highlights, including details on our latest plugins, upcoming integrations, and our $1,000 reward for accepted community plugin contributions. Check out Alex Meijer’s KubeCon session on OpenCost plugins here on YouTube.

New Plugins: Datadog, MongoDB Atlas, and OpenAI​

If you didn’t hear the news already at Kubecon, we’ve released several new plugins to expand OpenCost’s integrations with essential tools and platforms. Here’s a look at the capabilities each plugin brings:

1. Datadog Plugin: This plugin enables users to view and track Datadog’s costs directly within OpenCost. By consolidating Datadog expenses alongside Kubernetes workloads, users gain a comprehensive view of monitoring-related expenses, making it easier to manage observability costs in the context of total infrastructure spending.
2. MongoDB Atlas Plugin: For teams using MongoDB Atlas as a managed database service, this plugin provides cost insights directly within OpenCost. By tracking MongoDB resource consumption alongside Kubernetes spending, teams get a more unified view of total application costs.
3. OpenAI Plugin: OpenAI’s usage can be unpredictable and often scales rapidly with demand. With this plugin, OpenCost users can analyze and monitor OpenAI API usage costs alongside Kubernetes workloads, helping organizations understand and manage the full scope of AI-driven application expenses.

Plugin Backlog: What’s Coming Next​

Our backlog is shaped by community feedback. Below are a few examples of plugins we are looking to build, but you can check out the full backlog on our GitHub issues page.

• Snowflake: This plugin will enable tracking of Snowflake data warehousing costs, giving insights into data expenses alongside Kubernetes workloads.
• Databricks: With Databricks' popularity for big data processing, this plugin will bring Databricks cost insights into OpenCost, allowing users to manage analytics costs in one place.
• Cloudflare: This plugin will monitor the cost of Cloudflare, providing visibility into network and security-related expenses alongside Kubernetes infrastructure.

$1,000 Reward for Plugin Contributions​

In addition to these updates, OpenCost is inviting community contributions by offering a $1,000 reward + a box of OpenCost swag for each accepted plugin. This reward is part of our commitment to building a robust, community-driven ecosystem of cost management tools for Kubernetes. If you have experience with a particular tool or service that could benefit other OpenCost users, we’d love to collaborate with you!

How to get started with OpenCost Plugins​

Visit our Plugin Docs for the full details on how to install OpenCost plugins in your environment. In general, installing a plugin is as simple as:

1. Obtaining the plugin Binary
2. Adding your plugin API keys to the relevant plugin config
3. Watch all your cost data come together in one place!

Join the OpenCost Community​

Thank you to everyone who joined us at KubeCon! OpenCost’s new status as a CNCF Incubating Project represents a significant step forward, and we’re excited to grow with the community. For those who missed the session, watch Alex Meijers’ KubeCon talk here on YouTube and join us on GitHub to share your feedback and ideas. Together, let’s build a powerful and open ecosystem for cost management!

The OpenCost project proudly announces that we’ve reached CNCF Incubating status! This milestone in our journey underscores the significant dedication the project has received from the community that contributes to OpenCost. We’d like to thank the developers, Kubernetes practitioners, and FinOps teams from organizations across the globe that continue to make this project meaningful.

Cloud-native adoption continues accelerating, and the need for clear, manageable insights into Kubernetes costs keeps pace. OpenCost addresses this need as an open-source tool designed to make Kubernetes cost management more accessible and standardized. Initially launched through a collaborative effort led by Kubecost and supported by experts from organizations like Amazon, Adobe, Google, Microsoft, and SUSE, OpenCost was welcomed into the CNCF Sandbox to improve cost management for Kubernetes. Our promotion to CNCF Incubation reflects strong community support and the important challenges it seeks to address.

The Importance of OpenCost​

OpenCost fills a critical gap by providing real-time visibility into Kubernetes costs across multi-cloud environments. With its vendor-neutral framework, OpenCost enables teams to allocate costs by Kubernetes service, deployment, container, and more. By standardizing cost allocation, OpenCost helps reduce cost overruns and gives teams a trusted model for budget planning, regardless of whether they use AWS, Google Cloud, Microsoft Azure, or on-premises infrastructure.

From Sandbox to Incubating​

Progressing from Sandbox to Incubation within the CNCF represents a vote of confidence from the cloud-native and open-source communities. Projects that reach this status are celebrated for their innovation and reliability, and they signal the potential for widespread adoption. For OpenCost, this transition validates our project’s solutions to Kubernetes cost challenges and recognizes the tool as becoming foundational for Kubernetes cost management at scale.

Key Milestones for OpenCost​

OpenCost’s growth has been remarkable. Here are some notable highlights:

• Broader Platform Integration: OpenCost has integrated with major cloud providers’ billing APIs and supports Prometheus for seamless cost data exporting.
• Community-Driven Development: A diverse group of contributors from Adobe, Google, SUSE, and many others have significantly contributed to refining OpenCost, with frequent releases that keep it flexible, effective, and secure.
• Open Source Plugin Framework: OpenCost Plugins were added to allow for cost monitoring of tools and services like Datadog, OpenAI, and MongoDB Atlas.
• FinOps Certification: By aligning with the FinOps Foundation, OpenCost supports Kubernetes FinOps practitioners seeking to optimize their Kubernetes costs.

OpenCost Momentum​

As an Incubating project, OpenCost’s future is bright and filled with opportunities to expand its capabilities. We look forward to developing new integrations, refining real-time cost monitoring, and offering deeper support for multi-cloud and hybrid-cloud environments. Our progress depends on the community of users, and we invite anyone interested in Kubernetes cost management to join us in building a sustainable, transparent future for Kubernetes operations.

Help Shape the Future of OpenCost​

OpenCost is powered by the passion and expertise of our community. We encourage you to explore OpenCost on GitHub and chat with us on CNCF Slack. Together, we’re creating an essential tool for Kubernetes teams worldwide, helping them manage cloud costs more effectively and transparently. Are you going to Kubecon NA 2024? Stop to say ‘hi’ at the OpenCost kiosk in the CNCF Project Pavillion.

OpenCost is one of CNCF's leading open-source projects that offers real-time native cost monitoring for Kubernetes environments, providing visibility to developers and companies on the costs linked to their cloud-native applications. With OpenCost, one can trace the costs of single workloads, namespaces, and even particular labels in your Kubernetes cluster. The continuous granular cost visibility that OpenCost provides help in effectual usage of resources and better budgeting.

Given how useful OpenCost is, in the Headlamp team we created a Headlamp plugin for OpenCost to help Headlamp users track their cluster resource costs. This integration aims to solve the visibility problem between cost and cluster management, enabling developers to make more informed decisions.

Here is a quick video explaining the whole process:

Installing OpenCost in the cluster​

If you don’t have Prometheus and OpenCost installed in your cluster and you are using Headlamp as a desktop app, you can use the App Catalog to install them. This can be done by accessing the Apps from the sidebar, after you enter your cluster in Headlamp, look for the Prometheus app that is distributed by the prometheus-community, click install and follow the instructions.

Alternatively, you can install it by running the following commands.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prom prometheus-community/kube-prometheus-stack

Installing OpenCost:

opencost:
  prometheus:
    internal:
      enabled: true
      namespaceName: <Prometheus-Namespace>
      port: 9090
      serviceName: <Prometheus-Service>

Installing OpenCost plugin from the plugin Catalog​

1. In Headlamp’s home screen click on Plugin Catalog > Catalog.
2. Click the OpenCost plugin from the list of plugins that are displayed.
3. Click the Install button on the top right.

Visualizing OpenCost information​

After OpenCost is correctly installed and configured, its information will appear integrated in various parts of the Headlamp UI, for example, tables listing resources in the workload related views (pods, deployments, etc.) will now show a column with the cost of running that resource.

Similarly, at the bottom of the details view of each individal resource, there will be a chart showing the resource’s cost over time.

Configuring how data is displayed​

OpenCost's settings (under Settings > Plugins > OpenCost) provide options to adjust how the data is shown in the UI, ie. what currency symbol to be used, or timespan for which the cost has to be displayed. This way, users can easily adapt how OpenCost is displayed for them.

Conclusion​

In the Headlamp team, we believe this plugin is useful for many users who want to keep their costs monitored close to their Kubernetes resources. We are looking forward to receiving feedback and contributions on how we can make the UI even more useful with OpenCost and other CNCF tools, so reach out to us and get involved in Headlamp!

We are excited to announce that the CNCF OpenCost project has significantly expanded its scope and capabilities beyond existing Kubernetes and cloud costs monitoring. Via the new OpenCost Plugins framework, teams are now increasingly able to use OpenCost to monitor ALL of their IT spending (infrastructure monitoring, data platforms, cloud services or other tools) in one place. We have kicked things off with a Datadog plugin, but this is just the first of many plugins coming to OpenCost.

The new 1.110 release of OpenCost is a huge milestone in the project’s mission to deliver granular, real-time IT costs to the world. Already the leading project for monitoring the costs for Kubernetes and Cloud Services, OpenCost’s new Plugin architecture will provide comprehensive, unified cost monitoring capabilities to developers, FinOps practitioners, platform engineers, or anyone in your organization who values monitoring the cost of your IT resources.

The plugin framework for adding additional cost sources to OpenCost is flexible enough to allow for cost monitoring from a wide range of tools and services – it supports new costs that conform to the FOCUS spec developed by the FinOps Foundation to ensure costs are shown in a consistent way. If you are interested in a plugin to monitor your resources, you can review the process for adding a new plugin and make a contribution, or open an issue requesting a new plugin. Additionally, the first 10 plugins contributed and accepted to OpenCost will receive a box full of OpenCost swag and $1,000! If you have any issues or questions you can join our slack community or email us at opencost-kubecost@wwpdl.vnet.ibm.com.

To kick things off, we have created the first OpenCost plugin for Datadog cost monitoring! OpenCost 1.110 users are now able to monitor what it costs them to run Datadog’s various services in real time right alongside their monitoring of costs from Kubernetes and Cloud Services. Simply install the Datadog plugin, and you are able to slice and dice your Datadog costs however you want – by Account, Resource Type, Resource Name, etc. This granular, real-time visibility makes it easy to understand your costs by business unit (team, application, etc.), quickly identify increases in spend, and ensure you are spending money efficiently.

Below you can see how the new OpenCost API’s can be used to view costs from the configured plugins. For example, once you’ve integrated your Datadog account, you can access Datadog cost information via the following APIs:

• customCost/total
  • Used to grab a summary of custom costs over a window
  • Available aggregations:
    • zone
    • accountName
    • chargeCategory
    • description
    • resourceName
    • resourceType
    • providerId
    • usageUnit
    • domain
    • costSource
  • The available filters are the same as the available aggregations. For example:
    • filter=domain:”datadog”
    • filter=zone:”us”
    • filter=resourceType:”infra_hosts”
• customCost/timeseries
  • Essentially equivalent to calling /total over a range of time steps. For example, querying for the past 7 days will give you a /total response for each of those days, individually
  • All available aggregations and filters are the same as with /total

Below are some examples of these APIs in action.

Totals request, aggregating by domain over the past 7 days:

https://nightly.opencost.io/customCost/total?window=7d&aggregate=domain

Response:

{
  "code": 200,
  "data": {
    "window": {
      "start": "2024-03-14T00:00:00Z",
      "end": "2024-03-21T00:00:00Z"
    },
    "totalBilledCost": 147.37999,
    "totalListCost": 186.98547,
    "customCosts": [
      {
        "id": "",
        "zone": "us",
        "account_name": "Kubecost",
        "charge_category": "",
        "description": "",
        "resource_name": "",
        "resource_type": "",
        "provider_id": "",
        "billedCost": 147.37999,
        "listCost": 186.98547,
        "list_unit_price": 0.082197905,
        "usage_quantity": 120,
        "usage_unit": "",
        "domain": "datadog",
        "cost_source": "observability",
        "aggregate": "datadog"
      }
    ]
  }
}

Totals request, aggregating by providerId over the past 7 days:

https://nightly.opencost.io/customCost/total?window=7d&aggregate=providerId

Response:

{
  "code": 200,
  "data": {
    "window": {
      "start": "2024-03-14T00:00:00Z",
      "end": "2024-03-21T00:00:00Z"
    },
    "totalBilledCost": 147.37999,
    "totalListCost": 186.98546,
    "customCosts": [
      {
        "id": "",
        "zone": "us",
        "account_name": "Kubecost",
        "charge_category": "usage",
        "description": "350+ integrations, alerting, custom metrics & unlimited user accounts",
        "resource_name": "agent_host_count",
        "resource_type": "infra_hosts",
        "provider_id": "42c0ac62-8d80-11ed-96f3-da7ad0900005/agent_host_count",
        "billedCost": 0,
        "listCost": 8.876712,
        "list_unit_price": 0.073972605,
        "usage_quantity": 360,
        "usage_unit": "Infra Host - hours",
        "domain": "datadog",
        "cost_source": "observability",
        "aggregate": "42c0ac62-8d80-11ed-96f3-da7ad0900005/agent_host_count"
      },
      {
        "id": "",
        "zone": "us",
        "account_name": "Kubecost",
        "charge_category": "usage",
        "description": "Centralize your monitoring of systems and services (Per Container)",
        "resource_name": "container_count_excl_agent",
        "resource_type": "infra_hosts",
        "provider_id": "42c0ac62-8d80-11ed-96f3-da7ad0900005/container_count_excl_agent",
        "billedCost": 0,
        "listCost": 19.80274,
        "list_unit_price": 0.0041095894,
        "usage_quantity": 14456,
        "usage_unit": "Container - hours",
        "domain": "datadog",
        "cost_source": "observability",
        "aggregate": "42c0ac62-8d80-11ed-96f3-da7ad0900005/container_count_excl_agent"
      }
...
    ]
  }
}

Datadog is just the first of many plugins! If you are interested in a plugin to monitor your resources, you can review the process for adding a new plugin and make a contribution, or open an issue requesting a new plugin. The first 10 contributors who add a plugin which is accepted into OpenCost will receive swag and $1,000! If you have any issues or questions you can join our slack community or email us at opencost-kubecost@wwpdl.vnet.ibm.com.

Let’s build something together!

It’s a fact now that Kubernetes has won the container wars. It has fought off Docker, Mesos, OpenStack and a number of other clustering and orchestration technologies to become the de-facto Cloud Operating System. Heck, Kubernetes has even made it to F-16s. You say Maverick is an ace? He’s got nothing on those F-16s pilots who are able to fly a cloud within clouds at Mach 2. I’m jealous of those pilots.

Almost every type of workload now runs on Kubernetes. At Oracle, we are constantly striving to make the numerous software we build a first-class citizen of Kubernetes and the cloud-native ecosystem.

For those software that are foundational pieces which other applications rely on, we create Kubernetes operators for them e.g.

• Databases: Oracle Database, MySQL.
• In-memory data grid: Coherence.
• Application servers: WebLogic.

For applications, we either build containerized versions of them or we evolve them and run them in a semi-microservices style e.g. Siebel. The benefits for customers are quite obvious:

• Run in the cloud (hopefully you choose Oracle Cloud).
• Lean on Oracle Cloud and Kubernetes to scale your workloads when you need to.
• Embrace modern software engineering architectures, methodologies, culture and practices.
• Modernize your IT infrastructure and application landscape at your own pace.
• Run more recent “cloud-native” workloads such as micro-services, AI/ML, serverless, observability etc alongside your traditional Oracle workloads.

And finally, we also contribute to CNCF projects to enable our customers to use these projects smoothly, especially on Oracle Cloud and OKE. However, our contribution to CNCF is more than just financial. My colleague Mickey Boxell has led the Kubernetes documentation release team, we have added support to Thanos and OCI Object Storage, external-dns and we have recently made Istio available as a native OKE addon.

All this is a long-winded way to announce that we have contributed to OpenCost and added support for Oracle Cloud, courtesy of my colleague Anders Swanson.

What is OpenCost?​

From the horse’s mouth:

OpenCost is a vendor-neutral open source project for measuring and allocating cloud infrastructure and container costs in real time. Built by Kubernetes experts and supported by Kubernetes practitioners, OpenCost shines a light into the black box of Kubernetes spend.

Using OpenCost, you should be able to track the cost of running any Kubernetes clusters running on Oracle Cloud:

• OKE: Oracle’s managed Kubernetes service
• user-managed: Kubernetes that you run yourself e.g. OCNE, K3s on Oracle Cloud

For the purpose of this article, we’ll use OKE. As I mentioned in a previous post, you now have an astounding range of options to run your various workloads on OKE. From traditional Intel-based node pools to bare metal computes to HPC shapes running on ultra-low latency RDMA cluster network (very handy if you are in the AI/ML business), you can run them all on OKE and let us worry about the heavy lifting for you.

However, whenever Kubernetes and AI/ML are mentioned to customers, many users tend to picture thousands of servers and an astronomical sum to run these and are as a result, quite apprehensive to jump on the train. Well, you are still not running a planetary search engine so it’s very unlikely that you have such a massive bill to foot.

With OpenCost support for OCI, you can now have a better visibility of these costs and thus be a lot more judicious when planning your cluster.

Let’s get started.

Installing OpenCost on OKE​

Use the Terraform module for OKE to create a cluster. We’ll create a small cluster of 1 node pool and 3 worker nodes to get started. OpenCost requires Prometheus so let’s follow the guide install it:

helm install prometheus — repo https://prometheus-community.github.io/helm-charts prometheus \
--namespace prometheus-system — create-namespace \
--set prometheus-pushgateway.enabled=false \
--set alertmanager.enabled=false \
 -f https://raw.githubusercontent.com/opencost/opencost/develop/kubernetes/prometheus/extraScrapeConfigs.yaml

Let’s now install OpenCost:

kubectl apply — namespace opencost -f https://raw.githubusercontent.com/opencost/opencost/develop/kubernetes/opencost.yaml

We can now test OpenCost:

kubectl port-forward --namespace opencost service/opencost 9003:9090

And we can see a nice chart giving us a breakdown of running OKE:

We can also see a more detailed breakdown by containers:

But how do we know it’s really picking up the Oracle Cloud pricing? Retrieve the OpenCost pod name:

kubectl -n opencost get pods

NAME                        READY   STATUS    RESTARTS   AGE
opencost-794c54d566-5sh45   2/2     Running   0          42s

And check the logs:

kubectl logs -f opencost-794c54d566-5sh45

2024-02-24T13:43:16.091546797Z ??? Log level set to info
2024-02-24T13:43:16.091621789Z INF Starting cost-model version dev (HEAD)
2024-02-24T13:43:16.091708313Z INF Prometheus/Thanos Client Max Concurrency set to 5
2024-02-24T13:43:16.096096365Z INF Success: retrieved the 'up' query against prometheus at: http://prometheus-server.prometheus-system.svc
...
2024-02-24T13:43:16.205189991Z INF Found ProviderID starting with "oracle", using Oracle Provider

You can see it’s now found the ProviderID to be Oracle.

I would like to conclude by thanking my colleague Anders Swanson for his contribution to make this possible. If you have ideas and suggestions about how we can make OpenCost work better for you especially on OCI, please do not hesitate to reach out to us.

Kubecost joined efforts with ThoughtWorks and their open source Cloud Carbon Footprint tool to bring resource-level carbon footprint monitoring data into OpenCost.

"We are delighted to see Cloud Carbon Footprint integrated with Kubecost, a phenomenal cost management tool, and the underlying open source OpenCost project" said Ajay Chankramath, Head of Platform Engineering, responsible for the FinOps/GreenOps at Thoughtworks. "As organizations increasingly prioritize sustainability alongside financial efficiency, this integration empowers users to make informed decisions that benefit both their bottom line and the environment."

Cloud Carbon Footprint provides carbon costs across AWS, Azure, and GCP. OpenCost carbon costs support is currently in the mainline develop branch of OpenCost and will be available in the upcoming OpenCost 1.110 release. The OpenCost API has been extended to enable access and the OpenCost UI will be extended to support carbon costs.

**Example /allocation/carbon API response data: **

{
  "code": 200,
  "data": [
    {
      "cluster-one/gke-dev-1-kc-cloud-pool-80a91fb4-fbjy/alan-prom/alan-prom-prometheus-server-6d7bfd6f8d-gp2qc/prometheus-server": {
        "co2e": 0.00021789412060017551
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-021v/alan-prom/alan-prom-cost-analyzer-86c75db68f-j4clf/cost-analyzer-frontend": {
        "co2e": 5.8024376361348894e-06
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-021v/alan-prom/alan-prom-cost-analyzer-86c75db68f-j4clf/cost-model": {
        "co2e": 0.00011605019011287359
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-021v/nick/kubecost-nick-aggregator-0/aggregator": {
        "co2e": 0.0005701628137437462
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-021v/nick/kubecost-nick-cost-analyzer-7bbd5f4b6c-z4pqc/cost-analyzer-frontend": {
        "co2e": 5.801292027651357e-06
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-021v/nick/kubecost-nick-cost-analyzer-7bbd5f4b6c-z4pqc/cost-model": {
        "co2e": 0.00011602584055302713
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-kb6f/nick/kubecost-nick-aggregator-0/aggregator": {
        "co2e": 7.461035614569218e-05
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-nz03/alex-sonarqube/sonarqube-sonarqube-0/sonarqube": {
        "co2e": 0.0002412874789797606
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-nz03/ingress-nginx/ingress-nginx-controller-6859dbc4dc-cfjd8/controller": {
        "co2e": 5.802438122382271e-05
      },
      "cluster-one/gke-dev-1-n2-standard-8-c01e010c-nz03/kaelan/kaelan-kc-cost-analyzer-89658f954-ggsmp/aggregator": {
        "co2e": 7.249046165488723e-05
      }
    }
  ]
}

Through the incorporation of carbon emissions tracking, OpenCost provides a valuable tool for organizations to assess and mitigate their environmental impact in line with sustainability goals. By quantifying the carbon footprint of cloud-based services and digital infrastructures, organizations can optimize resource allocation, minimize waste, and prioritize eco-friendly solutions. Moreover, this initiative fosters collaboration and knowledge-sharing within the tech community, encouraging the development of best practices for reducing carbon emissions across the industry. We look forward to expanding our coverage and sharing our findings with other tools and platforms for both a more sustainable digital ecosystem and the planet as a whole.

To kick things off on Tuesday there will be a Project Lightning Talk Monitoring Kubernetes and Cloud Spend with OpenCost at 10:00 am in Pavilion 7, Level 7.1 Room D. This will be a introduction to OpenCost as a foundation for monitoring Kubernetes and cloud costs. There will be opportunities to follow up after the session, so introduce yourself and we can talk about the project afterwards.

OpenCost will be in the Project Pavilion on Wednesday 3:00-8:00pm and Friday 12:30-2:30pm in Kiosk PP11-B. Stop by with your questions, grab some stickers and other swag, or just drop in to discuss the latest news in the OpenCost community. All OpenCost community members are welcome to spend some time at the kiosk.

There has been a lot of new development and features launched since KubeCon NA 2023, we're eager to talk about some major new features that we'll be discussing at KubeCon EU. We'll be involved with a number of discussions at the event, interviews, and attending sessions. If you want to catch up at KubeCon EU, you can drop an email at opencost-kubecost@wwpdl.vnet.ibm.com or reach out in Slack. It's going to be a great week, see you there!

Port officially integrates with OpenCost. This brings together OpenCost data and Port’s internal developer portal, providing developers with the autonomy to understand and manage the cost associated with their work as well as providing managers with alerts, scorecards and initiatives that make it much easier to control costs.

Who are Port and OpenCost?​

OpenCost is a vendor-neutral open source project from the Cloud Native Computing Foundation for measuring and allocating cloud infrastructure and container costs in real time. Built by Kubernetes experts and supported by Kubernetes practitioners, OpenCost shines a light into the black box of Kubernetes and cloud spend.

Port is an open internal developer portal, owned by platform engineering teams and built for developers. Port consolidates everything developers need to know and execute to deliver software autonomously and to comply with organizational standards. Internal developer portals such as Port are gaining popularity since the need to create an end-to-end unified developer experience became obvious, due to the increasing complexity of cloud native application development.

Unlocking new possibilities together

As part of the platform engineering movement there is a focus on bringing everything in one place, so developers can become autonomous and managers can easily track engineering standards compliance. This is also relevant to cost data, with the goal of making developers more cost aware since they are the ones who build the applications and are therefore responsible to optimize them, also in terms of cost, both for the production environment and in earlier stages of the SDLC.

However, cloud cost reports are not developer friendly, and can be overwhelming since it is difficult to relate the cost of a cloud service to an application.

When you integrate OpenCost data into a developer portal you’re presenting cost data in the central place that developers use to access anything SDLC. Showing cost data to developers, in context of the cloud environment and services they are developing provides developers with easy to understand data that they can act upon, and immediately see if something is amiss.

The OpenCost integration not only displays cost per service but also per namespace and can break down the cost to CPU, memory, load balancer, network cost etc. Managers can use it to understand costs by business units or teams, saving them the need to dig into complex reports. As OpenCost continues to add more cloud billing coverage we'll continue to look for ways to expand the integration for our users.

To learn more about the integration, go here https://docs.getport.io/build-your-software-catalog/sync-data-to-catalog/cloud-cost/opencost/

• Oracle Cloud Infrastructure support has been added, enabling Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) users to track their Cost Allocations across their deployments.
• Additional patches for Docker have been merged, making it easier to track Cloud Costs without requiring Kubernetes to be installed. This will allow Cloud Costs and other non-Kubernetes functionality to be accessed wherever you may need it.
• The OpenCost and OpenCost-UI containers have been moved to the GitHub Container Registry. The OpenCost Helm Chart, the Prometheus OpenCost Exporter, and the OpenCost manifest are all being updated to reflect the new download location.
• The OpenCost UI now shows the version of OpenCost being used in the footer. This is included in the startup logging of each container as well, but it should help make debugging a little easier.

There were many more community-provided enhancements, fixes, and additional tests that were added to continue improving OpenCost. Please join us in the OpenCost community and help build our next great release!

Add the Helm Chart Repository

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Install the Chart

helm install [RELEASE_NAME] prometheus-community/prometheus-opencost-exporter

And this will install the latest version of the Prometheus OpenCost Exporter (currently 1.107.1). The Prometheus OpenCost Exporter will be kept in sync with future releases of OpenCost going forward. If you want to change any of the default settings, you can provide your own values.yaml as necessary.

For detailed information on leveraging the OpenCost Exporter within Prometheus, check out the OpenCost Prometheus Exporter documentation and the list of available metrics. It’s easier than ever to get OpenCost deployed for your specific environment requirements, we look forward to solving even more use cases in the future! Join us in the OpenCost community and help build our open source community!

If you're not familiar with OpenCost, it's the open source CNCF project for monitoring Kubernetes and cloud spending. It's a Golang implementation of the OpenCost Specification for monitoring Kubernetes cloud costs. It has an optional web UI and you can also run it as a Prometheus metrics exporter. The code is all at https://github.com/opencost/opencost and you can learn more about the project at https://opencost.io

Running OpenCost without Kubernetes​

Given that not everyone who wants to look at their cloud billing is using Kubernetes, to run without Kubernetes you can either run from Docker or directly from the CLI. There are 3 environment variables you'll need to set:

• KUBERNETES_ENABLED=false (default is true)
• CLOUD_COST_ENABLED=true (default is false since it's beta)
• CLOUD_COST_CONFIG_PATH=/path/to/file - you'll need to provide your credentials in a file (default is cloud-integration.json). Here’s an example file.

Running with Docker​

If you want to run with Docker, you can pull down the image from docker.io/mattray/opencost:k8sless (or build it yourself).

docker pull mattray/opencost:k8sless

and run it with

docker run -e KUBERNETES_ENABLED=false -e CLOUD_COST_ENABLED=true -e CLOUD_COST_CONFIG_PATH=/tmp/cloud-integration.json -p 9003:9003 -d -v /tmp:/tmp mattray/opencost:k8sless

Building and Running from the CLI​

You can check out the code and run make to build.

To test it, run:

KUBERNETES_ENABLED=false CLOUD_COST_ENABLED=true CLOUD_COST_CONFIG_PATH='cloud-costs.json' ./costmodel

Accessing the Cloud Costs API​

The OpenCost Cloud Cost API is exposed on port 9003, you test with

curl -G http://localhost:9003/cloudCost -d window=7d -d aggregate=provider | jq

The Cloud Cost API provides the available query parameters and the API Examples show how you could query the Services by your Provider or how to get billing items over a range of time. There are more Cloud Cost API endpoints available in the code, the documentation hasn’t kept up with all the new options so far.

Using the OpenCost UI from Docker​

The OpenCost UI for Cloud Costs is still under development, but you can grab the beta build with

docker pull mattray/opencost-ui:docker-ui

and run it from Docker without Kubernetes:

docker run -p 9090:9090 -d mattray/opencost-ui:docker-ui

Go to http://localhost:9090/cloud to check it out. The Cost Allocation tab will be empty because there’s no Kubernetes data, but the Cloud Costs should have whatever clouds you’ve configured access.

The OpenCost UI already works for local development, you can find instructions here.

Walkthrough​

If you’d rather just see a quick demo, I’ve recorded a screencast walking through the above steps and connecting with the UI.

Code Changes​

This should get merged soon, but if you want to work with the branch it’s available here: https://github.com/mattray/opencost/tree/cloudclost-k8sless (build instructions). The OpenCost PR is here: opencost/opencost#2317

I tested on MacOS with Docker (and EKS, K3s, and Kind for regression-checking), but it probably would work on any Unix-compatible platform (Windows?).

Next Steps​

I think there are a lot of use cases we're not aware of yet and hopefully this will get more folks interested in the project. We'll continue expanding documentation on the Cloud Costs API and providing more examples as it continues to mature. If you're involved in FinOps we'll be adding support for the upcoming FOCUS specification for standardized billing, so that will make this even more compelling. Let me know what you think, looking forward to any feedback on how to get cloud billing data available in useful formats to even more people.

If you have any questions, email us at opencost-kubecost@wwpdl.vnet.ibm.com, join us in CNCF #opencost Slack, or check out the OpenCost Community page.

AKS Cost Analysis is an add-on for Standard and Premium-tier AKS clusters offered to customers at no additional cost. It provides cost allocation reports directly in the Azure portal. AKS customers can now easily visualize their Kubernetes cost allocations as the foundation for further optimization and anomaly detection.

New Kubernetes Namespaces view.

AKS is also the first Azure service that drills down into the specifics of the service’s granular cost details. These Kubernetes-specific views will surface cost allocation across AKS cluster resources (i.e. VMs, public IPs, disks, etc.). "Our goal in Microsoft Azure is to build Kubernetes-centric experiences on top of vendor-neutral open-source solutions, ensuring that our customers can take advantage of the innovation and portability of the CNCF ecosystem natively in Azure,” said Sean McKenna, Director of Product Management for Azure Cloud Native. “We've really enjoyed partnering with the OpenCost community on this project and are thrilled to get it in the hands of our customers." AKS customers will be able to configure how shared costs are allocated across namespaces.

New Kubernetes Cluster view.

OpenCost is the open source CNCF sandbox project and specification for the real-time monitoring of cloud costs and associated Kubernetes deployments. It models and tracks current and historical Kubernetes cloud spend and resource allocation as well as general cloud costs, which may be used as the basis for cost observability and optimizations. Check out the code on GitHub or join the community.

Microsoft announced their involvement with OpenCost earlier this year and have been active in the community ever since. Today’s announcement is just another great step in our journey together. Microsoft has committed to helping establish OpenCost as the open source standard for Kubernetes and cloud costs monitoring. If you want to run your own OpenCost deployment, we have Azure-specific instructions, including accessing your own Price Sheet API and configuring Azure Cloud Cost access.

As more AKS users get visibility and understanding of their Kubernetes cloud billing, we’re sure they’ll join us in our goal of building more consistency across all providers. As we continue to ship new features, AKS users will continue to benefit from OpenCost’s success.

There will be an OpenCost Working Session on Monday from 9:30 - 10:30am in the Hilton Garden Inn McCormick Place on level 3 in the Premier room. Everyone is encouraged to attend, whether you're an end-user, contributor, or just wanting to learn more about the project. We are planning on discussing the status of Incubation, the roadmap for the project, and future development on carbon footprint and the external asset costs.

OpenCost will be at the Project Pavilion in kiosk F34. We're there the entire duration, so be sure to stop by and say "hi", ask questions, and get stickers and other swag. We're looking for more volunteers to staff the kiosk, why don't you drop by and help answer questions?

Kubecost's Alex Meijer and Michael Dresser are giving the talk "Node Size Matters - Running K8s as Cheaply as Possible". They will be presenting a study of the system overhead, one of the biggest "hidden" costs of using Kubernetes, across cloud providers' node families and demonstrate new OpenCost functionality for measuring system overhead. This informative session is Wednesday, November 8 from 5:25pm - 6:00pm at W179.

Mark Poko and JuanJo Ciarlante from Grafana Labs will be presenting "Where's Your Money Going? The Beginners Guide to Measuring Kubernetes Costs". They'll dive into Grafana Labs' usage of OpenCost and how they embed it in their Grafana Cloud platform. We're looking forward to the session Thursday, November 9 from 2:55pm - 3:30pm at W180.

In addition to the OpenCost working session, kiosk, and the presentations we'll be discussing the new cloud costs feature we just launched. Be sure to join us at this week's Community Meeting for a sneak peek, or visit the KubeCon kiosk to learn more about cloud costs or anything else OpenCost-related. See you there!

In an era where cloud computing has become an integral part of most businesses, keeping track of infrastructure costs can be a daunting task. This is becoming even more challenging with the growing use of shared infrastructure, multi-cloud and an ever increasing number of other infrastructure solutions. As the complexity of cloud environments expands, there is a pressing need for unified and open solutions that provide a clear and normalized view of all infrastructure expenditures. That's where we see OpenCost playing an increasingly key role.

OpenCost UI now allows you to monitor cloud cost by service, tag, and more. It also provides the ability to drill down all the way to individual item level

Multi-Cloud Cost Monitoring​

OpenCost's new multi-cloud cost monitoring solution offers a seamless experience for managing costs across various cloud platforms. With an easy to use interface and simple APIs, OpenCost lets you monitor your cloud expenses on Google Cloud, Amazon Web Services (AWS), and Microsoft Azure in a unified view. And that's just the beginning – we aim to support an increasing number of platforms (e.g. Datadog, MongoDB, etc) in the near future!

Before we delve into why this expansion is important for the OpenCost project, let's take a look at OpenCost multi-cloud cost monitoring in action. Check out our simple demo video to get a glimpse of how this new solution can give you a unified and customizable cloud cost monitoring experience.

This initial launch provides users with the ability to aggregate costs by multi-dimensions, view different cost metrics, filter by various dimensions (e.g. tags, services) and more.

Getting Started with OpenCost​

To get started, simply deploy OpenCost and add any number of cloud accounts to see a unified view of all costs. You can view OpenCost documentation to learn about APIs usage and more.

Why Is This Important?​

In today's diverse cloud landscape, organizations often find themselves managing multiple cloud accounts and/or providers simultaneously. This can lead to a fragmented view of expenses, making it challenging to optimize resources and control costs effectively. OpenCost's multi-cloud cost monitoring solution addresses this issue by providing a single, consolidated interface to normalize and monitor all your cloud costs. This unified perspective simplifies decision-making, cost allocation, and ultimately resource optimization. We believe that having a single view of costs is a critical capability for teams operating a business at medium or large scale built on cloud infrastructure.

Additionally, as cloud environments continue to evolve, there's an increasing demand for monitoring various cost types beyond basic cloud infrastructure. The OpenCost community recognizes this need and intends to extend its customizable interface for other cost types in the near future. We are excited to see the OpenCost community continue to play a significant role in shaping and expanding these capabilities.

Adopting FOCUS Standards​

OpenCost not only offers a unified cost monitoring solution but also embraces emerging industry standards. We are proud to announce that we will be implementing the FinOps Open Cost and Usage Specification (FOCUS) being created with community input and the FinOps Foundation. The work being done on this effort will be directly reflected in the OpenCost implementation. From Udam Dewaraja, Chairperson for the FinOps Foundations’ FOCUS Working Group, “We’re excited to see open source projects like OpenCost integrate and align around this new specification, which will help extend the benefits of FOCUS to a wider group of users. The FOCUS project continues to gain industry-wide momentum and contributors for its ability to bring together practitioners, cloud service providers, vendors, and consultants around a common specification for presenting cloud cost and usage data.”

About OpenCost​

OpenCost is a Cloud Native Computing Foundation (CNCF) project for monitoring and allocating infrastructure and container costs in real time. Our expansion into multi-cloud cost monitoring was made possible through collaboration and contributions from industry leaders. We extend our gratitude to AWS, Grafana Labs, Microsoft , Kubecost, and many others who played a pivotal role in making this project a reality. Together, we look forward to shaping the future of cloud cost monitoring and governance.

Conclusion​

OpenCost's multi-cloud cost monitoring provides a fully open source approach for organizations seeking a comprehensive, user-friendly, and standards-compliant solution for managing cloud expenses. With a unified interface, support for various cloud providers, and a commitment to continuous improvement, OpenCost is poised to empower businesses in their cloud cost optimization journey. Get started today and take control of your cloud costs like never before!

Come find us at the OpenCost kiosk at KubeCon North America next week to learn more and to share your thoughts on the project or join the OpenCost community to get involved!