Authored By : @Chinmayi Panicker
Co-authored By : @Sunjit Tara , @Nithin Thomas
In the previous blog, the integration between Instana and Kubecost is explained, which shows how it significantly enhances cost observability across Kubernetes environments. It outlines the core features offered by this integration and how it delivers granular visibility into resource usage and associated costs within your clusters.
In this blog, we’ll take a deeper look at how to configure the Instana-Kubecost integration for both free and enterprise tiers, tailored to suit different infrastructure scales and requirements. We’ll cover how Instana intelligently detects clusters that Kubecost monitors, and how you can select between static or dynamic cluster list configurations, depending on the complexity of your environment and monitoring goals.
In addition, if your Kubecost setup needs authentication, then you can generate an API key and perform additional configuration for the successful integration. This action ensures that the Instana Kubecost sensor can successfully connect and retrieve cost metrics in secure environments.
Static configuration for free tier users
The static cluster list configuration allows you to manually specify the clusters that Instana can monitor. This approach is useful when you want full control over clusters that are included in cost reporting.
If you use the free version of Kubecost, then you are limited to a single cluster. The free version of Kubecost is suited for smaller setups, development clusters, or proof-of-concept use cases where only one cluster is monitored.
To configure Instana for monitoring this cluster, you must modify the Instana agent configuration as shown in the following example:
For the url parameter, you must provide the URL of your Kubecost deployment. For example, http://<your-kubecost-setup>.com
The default cluster name is cluster-one.
Note: If your cluster is not named as cluster-one, update the clusters parameter with the correct cluster name that you want Instana to monitor.
Dynamic cluster detection for enterprise setups
While static configuration works well in controlled or smaller environments, many enterprise infrastructures are highly dynamic, where clusters are added, removed, or scaled frequently. Manually updating a list of clusters in such environments is inefficient.
To solve this issue, Instana provides dynamic cluster detection. When you use this method, you have to omit the clusters parameter entirely from your configuration.
The Instana Kubecost sensor automatically query Kubecost and detect all active clusters that are monitored.
Instana dashboard displays the cost data for each detected cluster on the appropriate “Cost” tab.
This method is useful for large-scale organizations in following scenarios:
- Managing frequent changes in cluster topology
- Running CI/CD pipelines that spin up new clusters
- Implementing multi-cloud strategies with clusters distributed across different environments
Static configuration using a selective cluster set
In enterprise environments, it’s common to operate multiple Kubernetes clusters across production, staging, development, and other environments. You can configure Instana to monitor all clusters that are detected by Kubecost, but many organizations prefer to limit monitoring to a specific set of clusters. This might be due to operational boundaries, regulatory constraints, cost allocation needs, or team-specific visibility requirements.
You can customize the configuration by listing the desired clusters using the clusters parameter even if you're on an enterprise plan with dynamic capabilities. This approach allows you to override automatic detection and focus only on the clusters that matter most to your use case:
This selective monitoring approach ensures that your dashboards and cost metrics remain clean, focused, and relevant to the stakeholders who consume them.
By understanding and applying these different configuration methods: static, dynamic, or custom, you can fine-tune your Instana-Kubecost setup to match the scale, complexity, and organizational structure of your Kubernetes infrastructure. This configuration not only optimizes your cost visibility but also ensures that your observability tools align seamlessly with your operational goals.
Now as you know how to configure Instana to monitor your Kubernetes clusters by using static, dynamic, or custom methods, let’s look at an additional consideration, which is authentication. If your Kubecost environment has security enabled, Instana needs an API key to access cost data.
Note: In the sample configuration examples shown in the previous section, the api_key parameter is omitted for illustrating the various cluster scenarios. If your Kubecost environment is setup for allowing only authenticated clients, providing an api_key in your agent configuration is required.
In the following section, we’ll walk through how to generate this key and incorporate it into your configuration to ensure a secure and successful integration.
Setting up API access for secured Kubecost
If you enable authentication in your Kubecost setup, Instana requires an API key to securely access cost metrics. For a detailed walkthrough on setting up authentication and managing users in Kubecost, see User Management (SAML). When authentication is configured, the next step is to generate a service account and obtain the API key.
1. Generate the API key in Kubecost
a) In the sidebar of the Kubecost UI, select Teams.
b) On the Service Accounts window, click Add Service Account.
c) Enter a name and generate the account. After the account is created, you receive an API key.
d) Record the API key.
#Kubernetes