Kubecost Cloud provides the ability to allocate out of cluster (OOC) costs back to Kubernetes concepts like namespaces and deployments. The following guide provides the steps required for allocating OOC costs in GCP.
Before you interact with Kubecost Cloud, you will need to export your cloud billing data in GCP to BigQuery. For help, consult Google's documentation on the subject.
After this, it is also recommend to use a detailed billing export in order to gain access to Kubecost's cloud integration functionality such as reconciliation for the most accurate spend data.
You will need to prepare the following fields:
GCP Project Id: The ID of your GCP project.
GCP Dataset: BigQuery dataset prefix
GCP Table: BigQuery table name.
If you are having trouble determining these values, consider this example. A dataset billing_data.gcp_billing_export_v1_018AIF_74KD1D_534A2 under a project project-1 will have the following values:
Project ID: project-1
Dataset Name: billing_data
Table: gcp_billing_export_v1_018AIF_74KD1D_534A2
In the Kubecost Cloud UI, begin by selecting Settings in the left navigation. Scroll down to Cloud Integrations, then select View Additional Details. The Cloud Integrations dashboard opens. Select + Add Integration. Then, select GCP Integration from the slide panel.
After completing the Prerequisites section, you will fill out the three fields in this step with the respective values (Project Id, Dataset, and Table). All fields are mandatory. Then, select Continue.
You will need to give your Kubecost GCP service account certain permissions in your project roles/bigquery.jobUser. This can be performed either through the gcloud CLI or the GCP Console. Follow the instructions as they appear directly in the UI. Then, select Continue.
Finally, you must give the Kubecost service account direct access to your BigQuery dataset via the BigQuery Data Viewer role. Like Step 2, this can be performed either through the gcloud CLI or the GCP Console. Follow the instructions as they appear directly in the UI. Then, select Continue.
After completing Step 3, you will see an overview of details for your integration. You can correct any details by selecting Edit. The Status should initially display as Unknown. This is normal. If everything looks correct, select Close to return to the Cloud Integrations dashboard. Your integration will now appear as a line item.
Kubecost Cloud provides the ability to allocate out of cluster (OOC) costs back to Kubernetes concepts like namespaces and deployments. The following guide provides the steps required for allocating OOC costs in AWS.
Before beginning your integration, you need to create a Cost and Usage Report (CUR) through AWS. Consult AWS' documentation Creating Cost and Usage Reports for step-by-step instructions if needed during this process. When creating your CUR, make sure to configure these settings:
Time granularity is set to Daily
Resource IDs and Athena are enabled
Remember the name of the S3 bucket that is created for this CUR. AWS may require up to 24 hours to publish data. Wait until you have received data before proceeding with this integration.
In the Kubecost Cloud UI, begin by selecting Settings in the left navigation. Scroll down to Cloud Integrations, then select View Additional Details. The Cloud Integrations dashboard opens. Select + Add Integration. Then, select AWS Integration from the slide panel.
If your CUR has been properly set up and is now providing data after following the on-screen instructions in the Kubecost UI, select Continue.
It's important to set up an Athena integration so Kubecost can perform reconciliation for providing accurate billing data. The on-screen instructions of the Kubecost Cloud UI are repeated here:
As part of the CUR creation process, Amazon also creates a CloudFormation template that is used to create the Athena integration. It is created in the CUR S3 bucket under s3-path-prefix/cur-name and typically has the filename crawler-cfn.yml. This .yml is your necessary CloudFormation template. You will need it in order to complete the CUR Athena integration. You can read more about this here.
Your S3 path prefix can be found by going to your AWS Cost and Usage Reports dashboard and selecting your bucket's report. In the Report details tab, you will find the S3 path prefix.
Once Athena is set up with the CUR, you will need to create a new S3 bucket for Athena query results:
Navigate to the S3 Management Console.
Select Create bucket. The Create Bucket page opens.
Use the same region used for the CUR bucket and pick a name that follows the format aws-athena-query-results-*.
Select Create bucket at the bottom of the page.
Navigate to the Amazon Athena Dashboard.
Select Settings, then select Manage. The 'Manage settings' window opens.
Set Location of query result to the S3 bucket you just created, then select Save.
When you have completed all the above steps, select Continue in the Kubecost Cloud UI.
Before continuing with the integration in the Kubecost Cloud UI, you need to set up IAM permissions in AWS.
Begin by downloading this .yaml template.
Then, navigate to the AWS Console Cloud Formation page.
Select Create Stack, then select With existing resources (import resources) from the dropdown. On the 'Identify resources' page, select Next.
Under Template source, choose Upload a template file.
Select Choose file, which will open your file explorer. Select the .yaml template, and then select Open. Then, select Next.
On the 'Identify resources' page, provide any additional resources to import. Then, select Next.
For Stack name, enter a name for your template.
Set the following parameters:
MasterPayerAccountID: The account ID of the management account (formerly called master payer account) where the CUR has been created
SpotDataFeedBucketName: Optional. The bucket where the Spot data feed is sent to
Review all provided information, then select Import Resources.
At the bottom of the page, select I acknowledge that AWS CloudFormation might create IAM resources.
Select Create Stack.
You will be prompted to provide values for several different fields to finalize your integration. See this table for working definitions of each field:
AWS Account ID
The AWS account ID where the Athena CUR is, likely your management account.
Master Payer ARN
Also known as the management account ARN. Configured in Step 3. The account ID of the management account where the CUR has been created.
Region
The AWS region Athena is running in
Bucket
An S3 bucket to store Athena query results that you’ve created that Kubecost has permission to access. The name of the bucket should match s3://aws-athena-query-results-*
Database
The name of the database created by the Athena setup
Table
The name of the table created by the Athena setup
Workgroup
Optional. Primary workgroup associated with the AWS account where your Athena CUR is.
Access Key Id
In the AWS IAM Console, select Asset Management > Users. Find your user and select Security credentials > Create access key.
Secret Access Key
Use the Access Key associated with the Access Key ID above.
When you have provided all mandatory fields, select Create Integration to finalize. Be patient while your integration is set up. The Status should initially display as Unknown. This is normal. You should eventually see the integration's Status change from Pending to Successful.
Integration with cloud service providers (CSPs) via their respective billing APIs allows Kubecost to display out-of-cluster (OOC) costs (e.g. AWS S3, Google Cloud Storage, Azure Storage Account). Additionally, it allows Kubecost to reconcile Kubecost's in-cluster estimates with actual billing data to improve accuracy.
To learn more about how Kubecost provides accurate cost data or how to manage existing cloud integrations, read below. Otherwise, see any of the following articles to get started on integrating a specific CSP:
Reconciliation matches in-cluster assets with items found in the billing data pulled from the CSP. This allows Kubecost to display the most accurate depiction of your in-cluster spending. Additionally, the reconciliation process creates Network assets for in-cluster nodes based on the information in the billing data. The main drawback of this process is that the CSPs have between a 6 to 24-hour delay in releasing billing data, and reconciliation requires a complete day of cost data to reconcile with the in-cluster assets. This requires a 48-hour window between resource usage and reconciliation. If reconciliation is performed within this window, asset cost is deflated to the partially complete cost shown in the billing data.
Cost-based metrics are based on on-demand pricing unless there is definitive data from a CSP that the node is not on-demand. This way estimates are as accurate as possible. If a new reserved instance is provisioned or a node joins a savings plan:
Kubecost continues to emit on-demand pricing until the node is added to the cloud bill.
Once the node is added to the cloud bill, Kubecost starts emitting something closer to the actual price.
For the time period where Kubecost assumed the node was on-demand but it was actually reserved, reconciliation adjusts the price to reflect the actual cost.
The reconciled assets will inherit the labels from the corresponding items in the billing data. If there exist identical label keys between the original assets and those of the billing data items, the label value of the original asset will take precedence.
You can view your existing cloud integrations and their success status in the Kubecost UI by visiting Settings, then scrolling to Cloud Integrations. To create a new integration or learn more about existing integrations, select View additional details to go to the Cloud Integrations page.
Here, you can view your existing integrations. For non-successful integrations, Kubecost will display a diagnostic error message in the Status column to contextualize steps toward successful integration.
Select an individual integration to view a side panel that contains details about that integration. You will be able to select Edit to adjust any details about your integration that were configured during the original setup. You can also delete an integration by selecting the red trash can icon next to the name of the integration.
Kubecost Cloud provides the ability to allocate out of cluster (OOC) costs back to Kubernetes concepts like namespaces and deployments. The following guide provides the steps required for allocating OOC costs in Azure.
In the Kubecost Cloud UI, begin by selecting Settings in the left navigation. Scroll down to Cloud Integrations, then select View Additional Details. The Cloud Integrations dashboard opens. Select + Add Integration. Then, select Azure Integration from the slide panel.
Read Microsoft's tutorial for creating and managing exported data. Follow the on-screen instructions in the Kubecost Cloud UI when exporting your cost report to ensure it's properly configured. Then, select Continue.
In the UI, provide Kubecost with the following values which can be located in the Azure Portal by selecting Storage Accounts:
Azure Subscription ID: Subscription ID belonging to the Storage Account which stores your exported Azure cost report data.
Azure Storage Account: Name of the Storage account where the exported Azure cost report data is being stored.
Azure Access Key: Found by selecting Access keys in the Storage account left navigation under "Security + networking".
Azure Storage Container: The name that you chose for the exported cost report when you set it up. This is the name of the container where the CSV cost reports are saved in your Storage account.
Azure Container Path (optional): An optional value which should be used if there is more than one billing report that is exported to the configured container. The path provided should have only one billing export because Kubecost will retrieve the most recent billing report for a given month found within the path.
Azure Cloud (optional): An optional value which denotes the cloud where the storage account exist, possible values are public and gov. The default is public.
When all required values have been provided, select Create Integration. Be patient while your integration is set up. The Status should initially display as Unknown. This is normal. You should eventually see the integration's Status change from Pending to Successful.