The Reports dashboard allows you to save defined queries across your different monitoring dashboards, including Allocations, Assets, and Cloud Costs, for quick access. All saved reports will display their type, window duration, and what they aggregate by.

Creating a report

Start by selecting Create a report, then select which dashboard you want to query for. You can also go directly to any dashboard and set up your query first. On either dashboard, once you have the parameters you want to save, select Save Report. You can choose a custom name for your report, but one will auto-generate based on your parameters, then select Save. The query will now show on the Reports dashboard.

Deleting a report

Reports can be deleted directly from the Reports dashboard by selecting the three dots icon under Actions, then selecting Delete. You can also delete a report by selecting it, then selecting Unsave Report on the corresponding dashboard. Confirm with Unsave.

The Assets page shows Kubernetes cluster costs broken down by the individual backing assets in your cluster (e.g. cost by node, disk, and other assets). It’s used to identify spend drivers over time and to audit Allocation data. This view can also optionally show out-of-cluster assets by service, tag/label, etc.

UI overview

Date range

You can control the window of allocation spend by selecting Last 7 days (the default option), and choosing the time window you want to view spend for. When using custom dates instead of a preset, select Apply to make changes.

Aggregate By

Here you can aggregate cost by namespace, deployment, service, and other native Kubernetes concepts. While selecting Single Aggregation, you will only be able to categorize by one concept at a time. While selecting Multi Aggregation, you will be able to filter for multiple concepts at the same time.

Edit Report

Selecting Edit Report will provide filtering and visualization options.

Resolution

Choose one of the following ways to display your query data on the dashboard:

• Daily: Default, displays data as a bar graph with daily steps

• Entire window: Displays all cost data as a semicircle graph with proportionate costs of your aggregate

Cost metric

View either cumulative or run rate costs measured over the selected time window based on the resources allocated.

• Cumulative Cost: represents the actual/historical spend captured by the Kubecost agent over the selected time window

• Rate metrics: Monthly, daily, or hourly "run rate" cost, also used for projected cost figures, based on samples in the selected time window

Filters

Filter resources by namespace, cluster, and/or Kubernetes label to more closely investigate a rise in spend or key cost drivers at different aggregations such as deployments or pods. When a filter is applied, only resources with this matching value will be shown.Comma-separated lists are supported to filter by multiple values, e.g. label filter equals kube-system,kubecost. Wild card filters are also supported, indicated by a * following the filter, e.g. label=kube* to return any namespace beginning with kube.

Additional options

The three horizontal dots icon provides additional means of handling your query data. You can open a saved report or download your query data as a CSV file.

Kubecost Cloud's UI shares many similarities in feature functionality with self-hosted Kubecost. However, while Kubecost Cloud is expanding in utility, there may be distinct differences that require users to consult specific product documentation depending on which version of Kubecost they are using. This docs group contains information on the multiple Kubecost Cloud pages and dashboards.

The Collections page allows users to create groups of external cloud costs and Kubernetes objects in order to receive a unified view of all cloud spending. This is to leverage existing tags applied to cloud resources, without needing to rename them to match Kubernetes names. Collections will also avoid duplicate costs.

Kubernetes costs, also referred to as in-cluster costs, refer to spending on resources including nodes, disks, and network costs. They are monitored via the Assets dashboard. Cloud costs, also referred to as out-of-cluster or external costs, refer to spending on third party services such as services offered by cloud service providers. They are monitored via the Cloud Cost Explorer.

Creating a new collection

To begin, select Add a new Collection in the top right. If you have not created any collections yet, you should see a Add a Collection icon in the middle of your screen. You can select this instead. The ‘New Collection’ page opens. The headline for your page should be an auto-generated title. This will be the name of your collection, which you can change by selecting the pencil icon. You can provide a name and a category for your collection. Categories are custom labels you can add to multiple collections to allow for filtering of that category, if multiple collections are intended for the same team or function. Name and category can always be edited later.

Once you are satisfied with the name of your collection, you can add Kubernetes and cloud costs.

All Kubernetes and cloud spend sources will appear on this page under one of two columns: Costs in Collection, or Costs Not in Collection. When first creating your collection, there should be no costs already added. Therefore, you should select Costs Not in Collection to view a list of all available cost sources, or select Explore Costs.

Costs are then divided into two categories: Kubernetes and Cloud (see above for an explanation of these costs). You can toggle between the two groups using the Domain dropdown on the left of the page. For each group, you will see a total cost value displayed on the right of the page, above your cost table.

Costs are organized in a table, listed in descending order starting with the highest values. To add an individual item, hover your cursor over the item until you see a green Add button visible on the right of the page. Select Add to include that cost into your collection. You can add all your listed Kubernetes or cloud costs into a collection by selecting Add All, displayed next to your total cost. This is only available once you've added at least one filter. Once an item has been added to the collection, changes will be automatically saved.

You can filter and recategorize your cost table using Aggregate By and Add Filters. Aggregate By allows you to organize your costs by a listed category, and supports single and multi-aggregation. Add Filters allows for flexible filtering of your table items, including filtering by custom labels.

After having added items to your collection, selecting Costs in Collection will provide a complete list of all items, as well as key cost metrics including total and percentage costs of both Kubernetes and cloud items.

In the event there is cost overlap from conflicting Kubernetes and cloud costs, they will be reflected in a special Overlap category. Kubecost automatically subtracts the overlapping costs so that the totals seen for the collection are accurate and do not contain duplicate costs. Currently, overlap is not considered for Network costs and Load Balancer costs coming from workloads running on Azure and GCP clusters.

Managing collections

The Collections page will list all existing collections with a chart displaying cost over time and total cost. You can begin editing a collection by selecting it. Selecting the three vertical dots in the top right of the collection tile will allow you to delete it. You can also adjust your Collections display by adjusting the window of time, aggregating by item or kind, or filtering.

The Abandoned Workloads page can detect workloads which have not sent or received a meaningful rate of traffic over a configurable duration.

You can access the Abandoned Workloads page by selecting Savings in the left navigation, then selecting Remedy abandoned workloads.

The Abandoned Workloads page will display front and center an estimated savings amount per month based on a number of detected workloads considered abandoned, defined by two values:

• Traffic threshold (bytes/sec): This slider will determine a meaningful rate of traffic (bytes in and out per second) to detect activity of workloads. Only workloads below the threshold will be taken into account, therefore, as you increase the threshold, you should observe the total detected workloads increase.

• Window (days): From the main dropdown, you will be able to select the duration of time to check for activity. Presets include 2 days, 7 days, and 30 days. As you increase the duration, you should observe the total detected workloads increase.

Filtering your abandoned workloads

Beneath your total savings value and slider scale, you will see a dashboard containing all abandoned workloads. The total number of workloads detected should appear in the top right of the table.

You can filter your workloads through four dropdowns; across clusters, namespaces, owners, and owner kinds.

Selecting an individual line item will expand the item, providing you with additional traffic data for that item.

The Savings page provides miscellaneous functionality to help you use resources more effectively and assess wasteful spending. In the center of the page, you will see your estimated monthly savings available.

Savings insights

The Savings page provides an array of panels containing different insights capable of lowering your Kubernetes and cloud spend. The current list of Savings features includes:

• Right-size your cluster nodes

• Right-size your container requests

• Remedy abandoned workloads

The Cloud Cost Explorer is a dashboard which provides visualization and filtering of your cloud spending. This dashboard includes the costs for all assets in your connected cloud accounts by pulling from those providers' Cost and Usage Reports (CURs) or other cloud billing reports.

For help on integrating one or several cloud service providers (CSPs), see the corresponding documentation:

UI Overview

Date range

You can adjust your displayed metrics using the date range feature, represented by Last 7 days, the default range. This will control the time range of metrics that appear. Select the date range of the report by setting specific start and end dates, or by using one of the preset options.

Aggregate filters

You can adjust your displayed metrics by aggregating your cost by category. Supported fields are Account, Provider, Invoice Entity, Service, Item, as well as custom labels. The Cloud Cost Explorer dashboard supports single and multi-aggregation. See the table below for descriptions of each field.

Edit

Selecting the Edit button will allow for additional filtering and pricing display options for your cloud data.

Add filters

You can filter displayed dashboard metrics by selecting Edit, then adding a filter. Filters can be created for the following categories (see descriptions of each category in the Aggregate filters table above):

• Service

• Account

• Invoice Entity

• Provider

• Labels

Cost Metric

Additional options

Selecting Save will save your current Cloud Costs query for access on the Reports page.

Select the three horizontal dots icon to view additional options. Select Open Report to open any existing Cloud Costs reports. Selecting Download CSV will download the current query as a CSV file.

Cost metrics by CSP

The current Cloud Cost schema is optimistic in that it provides space for cost metrics that may not yet be available from some providers. As the FOCUS Spec gains more adoption among CSPs, all fields will be populated with values that match the definitions. For now, some values on certain providers are being populated with their nearest approximate. This section outlines how each value is populated on each CSP.

The Allocations page allows you to aggregate cost by namespace, deployment, service, and other native Kubernetes concepts. While selecting Single Aggregation, you will only be able to categorize by one concept at a time. While selecting Multi Aggregation, you will be able to filter for multiple concepts at the same time.

Costs aggregations are also visible by other meaningful organizational concepts, e.g. Team, Department, and Product. These aggregations are based on Kubernetes labels, referenced at both the pod and namespace-level, with labels at the pod-level being favored over the namespace label when both are present. Workloads without the relevant label will be shown as __unallocated__.

UI Overview

Date range

You can control the window of allocation spend by selecting Last 7 days (the default option), and choosing the time window you want to view spend for. When using custom dates instead of a preset, select Apply to make changes.

Aggregate By

Here you can aggregate cost by namespace, deployment, service, and other native Kubernetes concepts. While selecting Single Aggregation, you will only be able to categorize by one concept at a time. While selecting Multi Aggregation, you will be able to filter for multiple concepts at the same time.

Costs aggregations are also visible by other meaningful organizational concepts, e.g. Team, Department, and Product. These aggregations are based on Kubernetes labels, referenced at both the pod and namespace-level, with labels at the pod-level being favored over the namespace label when both are present. Workloads without the relevant label will be shown as __unallocated__.

Edit Report

Selecting Edit Report will provide more options of filtering and visualizing your window query.

Idle costs

For an overview of what idle costs are and how they are calculated, see the bottom of the page.

Customize how you wish idle costs to be displayed in your report chart:

• Hide: Hides idle costs.

• Separate By Cluster: Associates idle costs with the clusters they are a part of.

• Separate By Node: Associates idle costs with the nodes they are scheduled to.

Chart

View Allocations data in the following formats:

1. Cost over time: Cost per aggregation broken down over days or hours depending on date range

2. Cost: Total cost per aggregation over date range

3. Proportional cost: Cost per aggregate displayed as a percentage of total cost over date range

4. Cost Treemap: Hierarchically structured view of costs in current aggregation

While Cost over time is selected, hover over any interval to receive a breakdown of your spending.

Cost metric

View either cumulative or run rate costs measured over the selected time window based on the resources allocated.

• Cumulative Cost: represents the actual/historical spend captured by the Kubecost agent over the selected time window

• Rate metrics: Monthly, daily, or hourly "run rate" cost, also used for projected cost figures, based on samples in the selected time window

Costs allocations are based on the following:

1. Resources allocated, i.e. max of resource requests and usage

2. The cost of each resource

3. The amount of time resources were provisioned

For more information, refer to the OpenCost spec.

Filters

Filter resources by namespace, cluster, and/or Kubernetes label to more closely investigate a rise in spend or key cost drivers at different aggregations such as deployments or pods. When a filter is applied, only resources with this matching value will be shown. These filters are also applied to external out-of-cluster asset tags:

Comma-separated lists are supported to filter by multiple categories, e.g. namespace filter equals kube-system,kubecost. Wild card filters are also supported, indicated by a * following the filter, e.g. namespace=kube* to return any namespace beginning with kube.

Additional options

The three horizontal dots icon provides additional means of handling your query data. You can open a saved report or download your query data as a CSV file.

Idle

Cluster idle cost is defined as the difference between the cost of allocated resources and the cost of the hardware they run on. Allocation is defined as the max of usage and requests. It can also be expressed as follows:

idle_cost = sum(cluster_cost) - (cpu_allocation_cost + ram_allocation_cost + gpu_allocation_cost) where allocation = max(request, usage)

Idle costs can also be thought of as the cost of the space that the Kubernetes scheduler could schedule pods, without disrupting any existing workloads, but it is not currently.

Alerts allow teams to receive updates on real-time Kubernetes spend. This doc gives an overview of how to configure alerts sent through email, Slack, and Microsoft Teams. Alerts are either created to monitor specific data sets and trends, or they must be toggled on or off.

Currently, only spend changes in allocation costs are supported in Kubecost Cloud. This alert type detects sudden changes in allocation spending (spending relating to any Kubernetes objects) when compared to a previous interval.

Creating an alert

To begin, select Create Alert. The 'Create New Alert' slide panel opens. Provide the following fields:

• Alert Type: Currently only can be set to Allocation Spend Change.

• Window: Spend over selected interval will be compared against the previous interval. Supports Daily, Weekly, and Monthly.

• Cost Threshold (%): Percent change to trigger alert. Must be configured as a negative value to detect sudden decreases in spend.

• Aggregation: The Kubernetes object type to monitor spend for.

• Filter: Optional, filter to a specific selected Kubernetes object.

• Recipients: Choose which platform(s) you want your alert sent through. Kubecost Alerts can be sent via Slack/Microsoft Teams webhook URLs, or by email. All three platforms do not need values provided for them, but may trigger global recipients if left blank (see below).

Before you finalize your alert, you can select Test Alert, which will send a test alert across the provided webhooks/emails. This is useful for ensuring your alert has been configured correctly. If the alert was sent successfully, you can finalize your changes by selecting Submit. Your alert will now appear on the Alerts page, and can be tested, edited, or deleted at any time by selecting the corresponding icons in your alert's line.

Global recipients

Global recipients specify a default fallback recipient for each type of message. If an alert does not define any email recipients, its messages will be sent to any emails specified in the Global Recipients email list. Likewise, if an alert does not define a webhook, its messages will be sent to the webhook, if one is present. Alerts that do define recipients will ignore the global setting for recipients of that type.

You can define global recipients by selecting Edit in the Global Recipients box, then selecting the desired platform type and providing a corresponding value. Confirm by selecting Save. You can only provide one webhook per platform as a global recipient.

Cluster Status Alerts

Cluster Status notifications, if enabled, provide notice if and when the cluster agent(s) installed have stopped reporting data to Kubecost Cloud.

To configure, select Add in the Cluster Status Alerts box. The 'Cluster Status' slide panel opens. Provide any Slack/Microsoft Teams webhooks or email addresses to which you want the alert sent. Confirm by selecting Enable.

Kubecost Cloud can provide recommendations for right-sizing your clusters to ensure they are configured in the most cost-effective way. Recommendations are available for any and all clusters.

Viewing cluster recommendations

You can access cluster right-sizing by selecting Savings in the left navigation, then select the Right-size your cluster nodes panel.

Kubecost will offer two recommendations: simple (uses one node type) and complex (uses two or more node types). Kubecost may hide the complex recommendation when it is more expensive than the simple recommendation, and present a single recommendation instead. These recommendations and their metrics will be displayed in a chart next to your existing configuration in order to compare values like total cost, node count, and usage.

You can toggle on Show advanced metrics to view more details about your cluster resource consumption.

Configuring your recommendations

Kubecost Cloud provides its right-sizing recommendations based on the characteristics of your cluster. You have the option to edit certain properties to generate relevant recommendations. Select Filter to configure your settings in the Cluster Sizing Settings window.

There are multiple dropdown menus to consider:

• In the Cluster dropdown, you can select the individual cluster you wish to apply right-sizing recommendations to.

• In the Profile dropdown, select the most relevant category of your cluster. You can select Production, Development, or High Availability.

  • Production: Stable cluster activity, will provide some extra space for potential spikes in activity.

  • Development: Cluster can tolerate small amount of instability, will run cluster somewhat close to capacity.

  • High availability: Cluster should avoid instability at all costs, will size cluster with lots of extra space to account for unexpected spikes in activity.

• In the Architecture dropdown, select either x86 or ARM. You may only see x86 as an option. This is normal. At the moment, ARM architecture recommendations are only supported on AWS clusters.

With this information provided, Kubecost can provide the most accurate recommendations for running your clusters efficiently.

Kubecost Cloud can provide recommendations for right-sizing your container requests to ensure they are as cost-effective as possible. Recommendations are provided for all namespaces within your cluster.

Viewing request recommendations

You can access request right-sizing by selecting Savings in the left navigation, then select the Right-size your container requests panel.

On the Container Request Right-sizing Recommendations page, you will see a table containing all namespaces/controller pairs and the cluster and container associated with each. You will also see the requested and recommended RAM/CPU, the current efficiency, and finally estimated monthly savings by adopting recommendations.

Configuring your recommendations

The displayed right-sizing recommendations are calculated by taking into account your environment profile. You can optionally configure this for more optimal results by selecting Customize above the table.

• Window: The range of time Kubecost will read for resource activity to determine its recommendations.

• Profile: Refers to the type of environment. The selected value for Profile may restrict you from customizing certain other values.

  • Production: Stable container activity, will provide some extra space for potential spikes in activity.

  • Development: Container can tolerate small amount of instability, will run somewhat close to capacity.

  • High availability: Container should avoid instability at all costs, will size container with lots of extra space to account for unexpected spikes in activity.

• CPU/RAM recommendation algorithm: The algorithm used to compute the recommendations. Currently, the only supported option is Percentile.

• CPU/RAM target utilization: These can be set to limit recommended utilization of resources below a percentage threshold.

• CPU/RAM percentile: Percentage of data points that will be sampled within your window range. Outlier data will be filtered out when determining recommendations.

• Add Filters: Filter the table of namespaces/controllers to be equal or not equal to values of one or several different categories such as cluster, label, or pod. For example, if you want to only see namespace/cluster pairs within the namespace kube-system, select Namespace from the first dropdown, select Equals from the second dropdown, then provide the value "kube-system" in the text box. Select the plus icon to confirm your filter. Multiple filters can be applied.

Select Save to confirm your customization. The table should update accordingly.