DEV Community: Kubecost

How to monitor Kubernetes costs with Kubecost and the Lens IDE

Stefano Maffulli — Wed, 23 Jun 2021 18:12:04 +0000

Lens is the most powerful IDE for those who need to deal with Kubernetes clusters on a daily basis. It allows you to manage your cluster and view important health metrics. A Kubecost and Lens integration allows you to also visualize Kubernetes costs directly in the Lens UI. With Lens and Kubecost you can view costs and spend efficiency by namespace, pod, deployment and more!

For most teams, it’s really difficult to understand the cost of Kubernetes workloads, even in a somewhat static multi-tenant environment. When concepts like autoscaling are introduced, it becomes far more complex. This creates many challenges, including unintentional overspending, poor visibility for business planning, and missing costly bugs/mistakes. Despite the fact that over 32% of respondents to the 2021 FinOps survey collect and analyze cloud cost data using spreadsheets, those will only take you so far.

To help engineering teams, we published an early version of a new open source integration with Lens. It provides a direct view into Kubernetes costs so you can understand what is driving overall costs and how efficiently they are being spent. In this first release you can see cost trends for any workload aggregation, e.g. pod, deployment, statefulset, namespace. Future releases will be driven by the feedback we receive, so join Kubecost Slack community (link below!) and let us know what features you'd like to see.

Install Kubecost in your Kubernetes cluster using Lens IDE

Get started by installing the Kubecost stack in your cluster. Open Lens and connect to your Kubernetes cluster. Go to the Apps directory and search for the cost-analyzer chart.

Create a namespace called “kubecost” and install Kubecost cost-analyzer in it.

Once Kubecost is installed, you can add the Kubecost extension:

Download the latest tar.gz file release from GitHub. Alternatively, just copy the download URL of the release artifact.
Open the Lens application and select Lens menu, and then click Extensions item, or press Shift + Command + E to open the Manage Lens Extensions page.
Specify the path (.tar, .tgz) or download URL to the extension package and click Install.

View Kubernetes cost metrics

To see the full Kubecost UI or to view cost metrics from the Lens terminal, setup a port forward to your Kubernetes cluster with kubectl:

kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090

This will add a new panel in Lens UI showing costs of resources per namespace.

These cost metrics account for all active workloads in the namespace. By default, pricing is pulled from public cloud providers, with AWS, Azure, and GCP being supported today. You can add a Kubecost cloud integration to reflect prices from Spot nodes, enterprise discounts, reserved instances, and more.
Custom pricing sheets are supported for for on-prem clusters.

You can also point your browser to http://localhost:9090 to view more cost metrics.

This installs the community version of Kubecost which is good for monitoring one cluster with a default metric retention of 15 days. Other features are available in the Business and Enterprise versions of the product. Join Kubecost Slack community or contact us if you want more!

How to set real-time cost alerts in Kubernetes

Stefano Maffulli — Wed, 12 May 2021 22:59:07 +0000

Kubernetes gave the great power to engineering to scale applications infrastructure without much fuss. Sadly, budgets don't scale as easily. DevOps and finance team can rely on the open source Kubecost project for real-time alerting of cost overruns.
In corporate environments it’s crucial to give all stakeholders the ability to track resource usage and cost to each service within a shared cluster. This clear ownership improves budget-based resource planning, identifies resource bottlenecks, and even helps manage security risks. Once your ecosystem is properly organized, the next step towards clarity is to set up cost alerts.

How Kubecost Adds Clarity

Two of the key features of Kubecost are its cost allocation views for granular insights and its notifications triggered by cost alerts.

1. Granular Insights

Kubecost can break costs down to any Kubernetes component level (according to usage), down to individual workloads. The cost allocation model supports all native Kubernetes concepts, including cluster, namespace, controller, deployment, service, label, pod, and container.

The view below shows a deployment along with its allocated costs and its resource efficiency score (by comparing idle to used resources), as well as its health score (calculated based on checks conveniently pre-configured based on industry best practices).

These historical cost measurements can serve as benchmarks for setting initial alerting or budget thresholds.

2. Notifications

Kubecost supports the following types of cost alert notifications:

Recurring Update: Great for creating scheduled cost reports allocated by namespace.
Budget: Great for surfacing a budget overrun relative to a defined threshold.
Spend Change: Great for detecting a jump in your spending habits (based on a historical moving average).
Efficiency: Great for detecting over-provisioned CPU, memory, or storage according to a defined efficiency ratio threshold between 0 and 1.

Let us expand some more on these alerting use cases.

Recurring Update Alert

This mode of alerting is better thought of as a scheduled report. Suppose an engineering manager responsible for a Kubernetes cluster has created multiple namespaces to delegate self-administration to various application teams. The engineering manager can schedule a “recurring update” alert to receive a regular report of usage and cost allocated by namespace to ensure that each group uses a fair portion of the shared cluster.

Budget Alert

The budget alert compares daily spending to a preset threshold (that can be typed in the Kubecost user interface) and alerts only if the threshold is exceeded. Once you combine this alert with the cost allocation feature of Kubecost, you achieve the fastest mechanism to notify the right person who is capable of rectifying a cost over-run on the very first day that the excess occurs, thus avoiding an end-of-month surprise.

Spend Change Alert

This type of alert is most helpful if you don't have a preset budget or would like to avoid setting thresholds altogether. Instead, you would simply like to know if your spending experiences a sudden unexpected increase. By comparing your current spending to a historical trend line, you will receive an alert as soon as your spending breaks from a typical daily pattern.

Efficiency Alert

An increase in spending is not always bad as it may be directly related to increased workload or increased business activity. The efficiency index identifies waste in your Kubernetes cluster, but it also detects bottlenecks. The efficiency alert notifies administrators of over and under-provisioning of resources that often go undetected for long periods.

To set the scope of an alert, simply add criteria to the aggregation (as defined in the aggregated cost model API) and filter settings. Aggregation supports dimensions such as cluster, namespace, controller, deployment, service, label, pod, and container. Filters let you choose which aggregations (such as a specific namespace) to include in the notification.

When you set up alerts based on usage per namespace (or per cluster), you can conveniently define daily budget thresholds in the UI unique to each project or team and direct notifications to relevant parties and collaborative tools. In this way, you not only cut out the noise, but you also deliver valuable information directly to the stakeholders who can act on it.

Via Email

Via Slack

Via Webhook

A third option is to simply use a generic webhook to integrate with just about any third-party tool such as PagerDuty or OpsGenie.

How to Get Started with Kubecost Alerts

1. Install Kubecost

Installing Kubecost in your Kubernetes cluster only takes a few minutes using Helm. Follow the installation guide and can configure all of the alerts in the Helm values section as shown below.

2. Set up Cost Alerts

You can configure your cost alerts from the Kubecost Helm values file. For each alert you complete the following:

Define your thresholds based on your budgetary goals
Filter namespaces unrelated to a given project or team
Add notifications for stakeholder awareness

The following is an example of a Helm values block.

  notifications:
    # Kubecost alerting configuration
    # Ref: http://docs.kubecost.com/alerts
    alertConfigs:
      enabled: false # the example values below are never read unless enabled is set to true
      frontendUrl: http://localhost:9090 # optional, used for linkbacks
      globalSlackWebhookUrl: "https://hooks.slack.com/services/<REDACTED>" # optional, used for Slack alerts
      kubecostHealth: true # Alerts generated for kubecost uptime. Uses the globalSlackWebhookUrl to deliver the alert
      globalAlertEmails:
        - user1@example.com
      alerts: # Alerts generated by kubecost, about cluster data
          # Daily namespace budget alert on namespace `kubecost`
        - type: budget # supported: budget, recurringUpdate
          threshold: 0.50 # optional, required for budget alerts
          window: daily # or 1d
          aggregation: namespace
          filter: elasticsearch
          ownerContact: # optional, overrides globalAlertEmails default
            - user1@example.com
            - user2@example.com
          slackWebhookUrl: "https://hooks.slack.com/services/T069Z9TFF/<REDACTED>" # optional, used for alert-specific Slack alerts
          # Daily cluster budget alert (clusterCosts alert) on cluster `cluster-one`
        - type: budget
          threshold: 1.0 # optional, required for budget alerts
          window: daily # or 1d
          aggregation: cluster
          filter: prod-cluster # does not accept csv
          # Recurring weekly update (weeklyUpdate alert)
        - type: recurringUpdate
          window: weekly # or 7d
          aggregation: namespace
          filter: '*'
          # Recurring weekly namespace update on kubecost namespace
        - type: recurringUpdate
          window: weekly # or 7d
          aggregation: namespace
          filter: kubecost
          # Spend Change Alert
        - type: spendChange  # change relative to moving avg
          relativeThreshold: 0.20  # Proportional change relative to baseline. Must be greater than -1 (can be negative)
          window: 1d                # accepts 'd', 'h'
          baselineWindow: 30d       # previous window, offset by window
          aggregation: namespace
          filter: kubecost, default # accepts csv

3. Scale Across Clusters

For production deployment, we recommend that you configure the system using the Helm values file (instead of using the UI). This enables you to reference your Helm values file for configuration across multiple clusters; to reuse your Helm values file, simply provide the path of the Helm chart and values file to your continuous delivery (CD) system (such as ArgoCD) and wait for the product to be deployed.

Once deployed, you'll see the following workloads in your cluster:

4. View

If you would just like to quickly explore the product:

Run the following command:

kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090

Navigate to http://localhost:9090.
Explore.

Let Kubecost run for a couple of hours before taking a full tour so that there is enough data in the system to populate all fields.

When moving to production, you can expose Kubecost via ingress, SAML, or other mechanism that meets your security requirements. This is similar to how you might give access to other resources, such as a Jenkins UI.

Setup Tips

Kubecost integrates with most Identity providers (such as Google Auth) and also supports SAML-based authentication. All of this can be configured in the Helm values file.
Kubecost uses Prometheus alertmanager for alert delivery. If you already have an instance of alertmanager running, you can configure its endpoint in the Helm values file and Kubecost can use that for alert notifications.

  notifications:
    # Kubecost alerting configuration
    # Ref: http://docs.kubecost.com/alerts
    alertConfigs:
  ...

    alertmanager: # Supply an alertmanager FQDN to receive notifications from the app.
      enabled: true # If true, allow kubecost to write to your alertmanager
      fqdn: http://kubecost-prometheus-alertmanager #example fqdn. Ignored if prometheus.enabled: true

See the Kubecost Alerts troubleshooting guide or join the Kubecost Slack group for community advice and support.

Conclusion

Kubecost provides a holistic view of infrastructure cost by collating both in-cluster and out-of-cluster resources with support for all leading public cloud providers. It takes this a step further by generating timely alerts and actionable scheduled reports for your stakeholders, allowing them to better control overspending on cloud resources.

From an operational standpoint, setup is quick and painless. Kubecost integrates with all leading identity providers and you can also use an existing alertmanager or Prometheus installation to integrate with, which is a huge plus, especially when most teams already have a Prometheus deployment running in their clusters.

AKS Cost Monitoring and Governance With Kubecost

Stefano Maffulli — Wed, 28 Apr 2021 22:57:02 +0000

When running Azure Kubernetes Service (AKS), it can be hard to understand and allocate costs in environments with multiple teams, projects, or even departments. With Kubecost, you gain full transparency into your Kubernetes usage and cost within minutes of installation. Officially launched in 2019 and built on open source, Kubecost now monitors over one billion dollars in Kubernetes spend, and enables startups and global enterprises alike to understand their spend and identify cost savings ranging from 30% to over 50%. Kubecost supports a wide range of self-managed and hosted Kubernetes environments, including Azure Kubernetes Service, which we’ll cover today in this article.

The Microsoft Azure Kubernetes Service (AKS) is a popular fully managed Kubernetes service that offers embedded continuous integration and continuous delivery as well as enterprise-grade security and governance— powerful tools for teams adopting Kubernetes. As with any complex infrastructure, AKS requires proper governance and financial transparency for successful organizational adoption. Kubecost, an open source tool that provides teams with visibility into Kubernetes spend and supports environments hosted in Azure, is a widely recommended solution for engineers and finance teams facing this problem. Note: This documentation page for AKS provides helpful context for using Kubecost to implement a cost governance strategy.

The Cost Allocation Challenge

Kubernetes clusters are often shared across teams, microservices, projects, applications, departments, and cost centers to save on infrastructure and administrative overhead. The most popular methods for organizing this shared platform is by simply using labels (similar to tags) or by creating namespaces. A Kubernetes namespace is a logical separation inside a Kubernetes cluster which could be assigned to a particular team, application, or even a business unit.

Most organizations map a namespace to a specific workload type or purpose. For example, a typical cluster might have one namespace for monitoring and one namespace for logging for use by the DevOps teams who maintain the cluster. A customer-facing application hosted in that same cluster might have one namespace for its front-end components and a separate namespace for its back-end services.

Creating these logical divisions inside a cluster is administratively convenient, but adds complexity when trying to accurately measure resource usage and allocate costs to each tenant based on detailed billing data.

Sharing a Kubernetes Cluster in Azure

There are three models for sharing Azure Kubernetes Service (AKS) clusters across cost centers:

Dedicated AKS cluster: Each team or project gets its own dedicated AKS cluster to easily track its billing. This approach does not benefit from resource sharing.
Dedicated AKS node: Each team or project gets its pods assigned to a specific node in a shared AKS cluster using labels and a configuration constraint known as nodeSelector. Each team can then isolate its spending in the Azure bill according to the cost of its assigned nodes. Resource sharing is not efficient in this model.
Dedicated AKS Namespace: Each team or project gets its own dedicated namespace along with more flexibility and administrative freedom. This model, as we have mentioned, can be challenging for cost allocation. However, this is where Kubecost comes in.

The Measurement Challenge

Suppose you have chosen to support multiple projects and teams on your AKS cluster using a few dozen namespaces. In this example, each team has its own namespace and autonomous administrative control over provisioning pods and containers. After a couple of months, the cluster costs are higher than expected, and you would like to identify the cause of the spending jump. It’s a simple question, but complicated to answer, because you must measure resource usage by workloads in each namespace over multiple weeks to come to a conclusion.

This means that you must allocate the following by namespace:

The actual usage of CPU, GPU, memory, network, and persistent storage.
The excessive requests for CPU and memory leaving resources unused.
The usage of shared resources such as databases or blob storage.
The proportionate use of cloud instance reservations and support services.

If you take just network usage as one example, you are required to:

Measure the egress traffic generated by containers belonging to each namespace across regions, availability zones, and out to the internet.
Determine the data transfer rates that may be negotiated with your cloud provider.

Only then can you measure the networking costs associated with each namespace.

This process is daunting, especially when you consider the fact that it requires:

Specialized telemetry for collecting relevant data in real-time
Storage of time-series data over time
Collection and analysis of cloud provider’s detailed billing logs
Analysis of usage and cost data to calculate the accurate costs
Presentation of the results in the form of reports or dashboards

Don’t Sidestep the Challenge

Leaving this challenge unresolved leads to organizational frustration in the long run as you struggle to identify the root cause of a spending jump or struggle to respond to a management request for what seems a simple report of cost allocation by application, team, or project. A sudden increase in spending due to misconfiguration would be a routine operational matter if noticed within hours or days, but when left lurking in the shadows for weeks or months, it can fester into an end-of-quarter budgeting drama.

Although Kubernetes delivers on the promise of economies of scale and auto-scaling, it requires proper governance and financial transparency for sustained, successful organizational adoption.

One Comprehensive View

Having a high-level summary view of your resource usage and spend while also being able to drill down into the details is a universal ideal applicable to just about any domain. In the case of Kubernetes hosted in Azure, there are two types of comprehensive summarized views:

Azure resources directly or indirectly related to Azure Kubernetes Service
Azure services unrelated to AKS, e.g. other Azure Virtual Machines

Having both views in a single tool avoids the need to switch between consoles and reconcile billing information.

Azure Costs Related to Kubernetes

The costs directly associated with Kubernetes in Azure are the costs of the nodes that form the Kubernetes cluster, including the network and persistent storage volumes that support the nodes. Costs can be broken down into charges associated with:

CPU
Memory
GPU
Network
Storage Volumes

There are also external costs associated with a Kubernetes cluster or namespace. These charges may be dedicated to each namespace or Kubernetes resource, or they may be shared across multiple namespaces. For example, a proxy server may be accessed by all containers regardless of the namespace, and therefore its cost would be shared across all namespaces.

The table below summarizes the types of costs that you must account for to have an accurate view of your spending by namespace:

Kubernetes Cost Type	Kubernetes Cost Description	Examples
In-Cluster	The cost of the nodes that make up the cluster	CPU, memory, storage, network, and GPU
External	The cost of Azure services dedicated to an individual namespace	Azure SQL, Azure Blob, Azure Synapse Analytics
Shared	The cost of services shared by all namespaces	kube-system namespace, common labor costs

The Kubecost Approach

Kubecost is popular because of its rich set of functionality, ease of implementation, and its attentive support team. As pioneers in Kubernetes FinOps, Kubecost and its early adopters helped define many of the modern concepts behind financial reporting on shared Kubernetes resources in a hosted cloud environment.

Azure Integration

Later in this article, we’ll go over how to install Kubecost in a Kubernetes cluster using Helm and integrate it with Azure. But first, it’s important to know that Kubecost is installed within the Kubernetes cluster and does not transmit any data outside of your cluster, meaning you won’t have to worry about sensitive data leaving your environment.

Kubecost collects data from the Azure Billing Rate Card API (using a role definition that you create) to provide accurate cost information based on your detailed billing records. Kubecost’s Azure integration collects your exact pricing data to account for any special pricing, such as Azure reservations, in its analyses. Additionally with integration to your Azure Storage Account, Kubecost is able to reconcile exact costs of your in-cluster usage and display them alongside out-of-cluster costs for an accurate and holistic view of your cloud spend.

Main Dashboard

Once the installation process is completed, you can then access the main dashboard, where each cluster also has its own dedicated view, which includes:

Total monthly spending
Efficiency (the ratio of utilized to idle resources over time)
Cost allocation by Kubernetes controller, service, namespace
Cluster health (based on preset rules of reliability and risk best practices)

Navigation Options

As you might have noticed, the navigation menu visible on the left side of the previous screenshot presents a number of other reports and dashboards available to Kubecost users. These tools include:

Cost Allocation: Group costs by Kubernetes meta-data and Azure tags
Assets: View all of your Azure spending beyond AKS
Savings: Get recommendations for cost savings based on preset best practices
Health: See your cluster’s health score based on preset best practices
Reports: Group, filter, sort detailed cost information and store for later
Notifications: Configure cost alerts based on cluster or namespace budgets

We won’t cover all of the functionalities offered by these tools in this article; we will highlight the primary ones related to Azure billing and Kubernetes cost allocation.

Cost Allocation

As referenced earlier in this article, costs associated with a Kubernetes cluster fall into the following categories:

In-cluster: AKS costs of Memory, CPU, network, storage, and GPU
External: Azure costs dedicated to each Kubernetes component
Shared: Azure services or fixed costs shared across Kubernetes components

The diagram below uses a grouping by namespace to illustrate these concepts including the option to allocate the cost of a shared cluster namespace across other namespaces:

The user interface displays the cost categories highlighted in this screenshot:

This functionality requires you to export your Azure cost report into an Azure storage by following these instructions (select the daily month-to-date option for the export and wait a few hours to populate) and allowing Kubecost to securely access it via the Azure storage API by creating a JSON file named azure-storage-config.json with your secret information formatted as below.

{
    "azureStorageAccount": "<STORAGE_ACCOUNT_NAME>",
    "azureStorageAccessKey": "<STORE_ACCESS_KEY>",
    "azureStorageContainer": <REPORT_CONTAINER_NAME>
}

You can then use this command to create the secret:

kubectl create secret generic <SECRET_NAME> --from-file=azure-storage-config.json -n kubecost

Once the secret is created, set .Values.kubecostProductConfigs.azureStorageSecretName to <SECRET_NAME> and upgrade Kubecost via helm. You can also follow the more detailed instructions.

Later in this article, we provide instructions for using helm to install Kubecost and share links to relevant instructions pages.

Cost Breakdown

One of the nice features of Kubecost is that you can select just about any line item on the screen and drill down to see more information. For example, in the case of external costs highlighted in the previous screenshot, selecting a specific value would present a breakdown of the charges:

Allocating External Azure Costs Using Tags

Now that you have learned about the concepts of in-cluster, external, and shared Azure costs in Kubecost, it may be helpful to know how you can control the allocations. Kubecost uses tags and labels to allocate Azure spending outside of the Kubernetes cluster to specific Kubernetes components, such as pods and namespaces.

For example, you could take the costs related to a SQL instance and associate them with a specific pod. Suppose you have a namespace called “app-backend” containing microservices with their own dedicated Azure SQL database. This database is provisioned under the Managed Instance model, and you would like all of its costs to be attributed to this one specific namespace in the form of external costs. In this scenario, you would apply a tag to the SQL database instance with the tag key “kubernetes_namespace” and the tag-value “app-backend.” That’s it -- the next time you visit Kubecost and use the Cost Allocation view (grouped by namespace), the costs of the SQL instance will be shown in the appropriate row, under the column titled “external costs''. The table below shows the various tags available in Kubecost to accomplish this type of mapping:

Kubernetes Component	Azure Key	Azure Value
Cluster	kubernetes_cluster	<cluster-name>
Namespace	kubernetes_namespace	<namespace-name>
Deployment	kubernetes_deployment	<deployment-name>
Label	kubernetes_label_NAME	<label-value>
DaemonSet	kubernetes_daemonset	<daemonset-name>
Pod	kubernetes_pod	<pod-name>
Container	kubernetes_container	<container-name>

You can learn more about tagging using the Azure portal on this page.

Next, we’ll show you how to use tags to control the allocation of shared resources in the Kubecost Settings user interface.

Cost Allocation Configuration

Kubecost makes it easy to configure the allocation of shared costs to Kubernetes components. Shared resources may be in the form of:

Fixed dollar value: For example, $1,000 may be shared across all namespaces
Shared namespace: For example, the cost of the default “kube-system” namespace may be spread out. The configuration field accepts a list of common-separated namespaces.
Share by label: For example, the cost of pods with a label of app=splunk may be distributed. Note that in the screenshot below, the tag key named “app” is repeated and separated by a comma to capture both the “datadog” value for the key named “app” and the value “splunk” for the same key named “app.”

The fixed dollar value is a simple and elegant solution for allocating costs of any type. For example, you may attribute the proportional maintenance labor cost of the cluster to each namespace so that your financial report reflects a fully-loaded cost.

The namespace sharing feature allows you to take the costs associated with multiple namespaces and distribute them among all of the other namespaces. A namespace dedicated to hosting security software intended to protect the entire cluster is a great candidate for this feature; kube-system is another great candidate, which is created by the Kubernetes system to host common utilities such as kube-dns and kube-proxy.

The third sharing feature uses labels to select just about any Kubernetes component and distribute costs proportionally among them. For example, you may have pods running your user acceptance testing (UAT) environment -- with labels, you could take all of your UAT costs and spread them across your production namespaces so that the cost of testing your software is included in your application costs.

The shared costs are allocated proportionally to the percentage of in-cluster resource costs the namespaces are consuming (CPU, memory, network, storage, and GPU) so a namespace that uses more of the cluster resources would get a higher allocation of shared expenses. However, you can also instruct Kubecost to distribute the costs equally (independent of usage) across all of the namespaces for a uniform distribution.

Azure Cloud Assets

So far, we focused on Kubernetes components; however, one of the exciting features introduced by Kubecost as part of its support for Azure is the ability to extend the comprehensive view to include all of your Azure spending (even if not related to AKS).

This view is accessible on the navigation menu, under the section titled Assets, and it supports a full set of controls to filter, group, and sort your Azure bill in every dimension.

You can drill down into specific billing record details simply by selecting them. For example, the following screenshot drills into the networking charges and shows itemized charges for load balancers or specific spot instances:

Getting Started With Installation

There are 3 steps to install Kubecost in Azure and enable access to billing data:

Install Kubecost using a Helm chart.
Create an Azure role definition for Kubecost in your Azure account.
Enter your account information on the Kubecost Settings page.

Kubecost is available for download as a Helm chart at this link: https://www.kubecost.com/install.html and should take less than 5 minutes to install in AKS.

Once you have installed Kubecost in an Azure account, you must then create an Azure role definition to provide access privileges to Kubecost in the form of JSON files. This is required for accessing accurate billing data via the Billing Rate Card API. Detailed instructions for creating an Azure role definition and sharing it with Kubecost are provided on this Kubecost documentation page: http://docs.kubecost.com/azure-config while Microsoft Azure’s own instruction page for integrating with Kubecost also documents the installation steps.

The last step is to enter your Azure Subscription, Tenant, Client ID, and Client Secret in the Kubecost’s Settings user interface.

Conclusion

You don’t have to accept an AKS cluster as a financial black box. With Kubecost, you can share your AKS cluster with other teams and still generate a cost allocation report within minutes of installation. Kubecost also monitors your cluster’s health and efficiency -- it’s even able to send cost notification alerts when your namespace experiences an unexpected jump in spending. Look for other Kubecost articles and documentation pages to learn more about its growing list of functionalities.

Hello kubectl cost: monitoring Kubernetes spend from the command line!

Stefano Maffulli — Tue, 20 Apr 2021 23:19:10 +0000

If you're terminal-loving engineers using Kubernetes like us, kubectl is your constant companion. That's why the Kubecost team built a new CLI for interacting with Kubernetes cost data. Today, we’re announcing kubectl cost, an open-source extension that fits directly into your workflow.

Here’s an example of it in action:

For teams running Kubernetes, gaining visibility into the cost of resources can be hard, especially in dynamic multi-tenant environments. Kubecost helps teams—developers, managers, executives, and everyone in-between—running Kubernetes understand their cluster spend precisely, all the way down to the pod level. One of our primary goals is to provide cost visibility into tools that teams are already using.

Kubectl cost is a kubectl plugin, a CLI tool designed for application and infrastructure engineers who interact directly with Kubernetes on a regular basis. They would benefit from understanding the costs of their various deployments and other in-cluster resources. With reporting a few keystrokes away on the familiar interface of kubectl, the cost plugin gives engineers quick and easy access to cost and spend efficiency information. At Kubecost, we believe that by making cost metrics more accessible we can help our users build more cost-efficient software systems. Let’s check it out.

How to use `kubectl cost`

The basic structure of kubectl cost is built around various aggregations that map to Kubernetes concepts, e.g. namespace, label, deployment, statefulset, etc. It leverages Kubecost APIs which provide users with programmatic access to useful data about workloads and assets in your clusters.

Let’s have a look at a few samples:

One of the simplest queries, showing a monthly cost projection for each namespace in your cluster based on the past day of activity. This accounts for all workloads and their resources in each label.

Total cost, over the past day, broken down by the value of the app label. This accounts for labels applied at both the namespace and workload-level.

Monthly rate projection broken down by deployment, including a more detailed look at CPU cost and CPU cost efficiency.

How much each namespace cost last month, including CPU cost and efficiency.

How much each namespace cost yesterday, with all resource-specific costs and efficiencies displayed. This highlights the granular detail at which Kubecost collects cost metrics.

How it works

By default, Kubecost integrates with cloud provider billing APIs with support for AWS/EKS, Azure/AKS, GCP/GKE, and on-prem clusters via custom pricing sheets.
Kubecost can integrate with your cloud provider billing data directly to accurately reflect enterprise discounts, spot prices, reserved instances, savings plans, and more.
Compute and memory costs are calculated using the max of resource usage and resource requests.
Network costs are optional and are enabled via the network-costs daemonset.
Monthly rate projections are based on average run rate for each individual workload over the measured window.

Learning more

There’s tons more to discover, check out the documentation and kubectl cost --help to keep going. We’re also going to be adding more functionality in the coming weeks. So join our Slack community or reach out to team@kubecost.com if you have questions or additional features you’d like to see!

DEV Community: Kubecost

How to monitor Kubernetes costs with Kubecost and the Lens IDE

Install Kubecost in your Kubernetes cluster using Lens IDE

View Kubernetes cost metrics

How to set real-time cost alerts in Kubernetes

How Kubecost Adds Clarity

1. Granular Insights

2. Notifications

Recurring Update Alert

Budget Alert

Spend Change Alert

Efficiency Alert

Via Email

Via Slack

Via Webhook

How to Get Started with Kubecost Alerts

1. Install Kubecost

2. Set up Cost Alerts

3. Scale Across Clusters

4. View

Setup Tips

Conclusion

AKS Cost Monitoring and Governance With Kubecost

The Cost Allocation Challenge

Sharing a Kubernetes Cluster in Azure

The Measurement Challenge

Don’t Sidestep the Challenge

One Comprehensive View

Azure Costs Related to Kubernetes

The Kubecost Approach

Azure Integration

Main Dashboard

Navigation Options

Cost Allocation

Cost Breakdown

Allocating External Azure Costs Using Tags

Cost Allocation Configuration

Azure Cloud Assets

Getting Started With Installation

Conclusion

Hello kubectl cost: monitoring Kubernetes spend from the command line!

How to use kubectl cost

How it works

Learning more

How to use `kubectl cost`