Skip to content

Mock-up for doc revamp and standardization #10577

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions docs/cloud-cost-management/content/recommendations/aws-recs.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@


An effective way to reduce AWS EC2 instance costs is to **optimize VM utilization**. This involves resizing instances based on active tasks and decommissioning unused instances.

Harness CCM helps you reduce costs with Recommendations.

You can view the Recommendations for all of your AWS EC2 instances on the Recommendations page. Furthermore, to view **only** EC2 instances Recommendations, you can use the **Filter** option and select `EC2_INSTANCE` from the **Recommendation Type** dropdown list.

:::note
Before using Recommendations in your environment, ensure that you evaluate their impact thoroughly. The person reviewing the Recommendations should be able to understand the impacts identified in the Recommendations, as well as the impact on the infrastructure and business.

Using Recommendations without proper assessment could result in unexpected changes, such as issues with system performance or poor reliability.
:::

17 changes: 17 additions & 0 deletions docs/cloud-cost-management/content/recommendations/azure-vm.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@


An effective way to reduce Azure VM costs is to optimize VM utilization. This involves resizing idle or underutilized VMs based on active tasks and shutting down unused VMs.

Virtual machines are considered low-utilization:

* If their CPU utilization is 5 percent or less and their network utilization is less than 2 percent and have threshold memory pressure numbers.

* If the current workload can be accommodated by a smaller sized virtual machine.

You can view the recommendations for your Azure VMs on the **Recommendations** page.

:::note
Before using recommendations in your environment, ensure that you evaluate their impact thoroughly. The person reviewing the recommendations should be able to understand the impacts identified in the recommendations, as well as the impact on the infrastructure and business.

Using recommendations without proper assessment could result in unexpected changes, such as issues with system performance or poor reliability.
:::
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
:::note
Currently, this feature is behind the feature flag **CCM_CURRENCY_PREFERENCES**. Contact Harness Support to enable the feature.
:::

Harness CCM allows you to view your cloud spend data in the currency of your choice. It is easier to view reports and dashboards in your preferred currency rather than having it in different currencies and then converting them to your preferred currency. It provides more consistent, easy-to-consume, and meaningful cloud analytics across the entire business.

CCM allows you to choose from the following list of currencies and displays the cost data in the specified currency:

- ARS
- AUD
- BRL
- CAD
- CNY
- EUR
- GBP
- INR
- JPY
- MXN
- NOK
- NZD
- RUB
- SGD
- USD
98 changes: 98 additions & 0 deletions docs/cloud-cost-management/content/recommendations/ecs-recs.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
# Optimize AWS ECS costs with recommendations

One of the most impactful ways to reduce spend on AWS ECS infrastructure is to make sure your ECS clusters are optimally sized for the services and tasks they run. Harness Cloud Cost Management (CCM) provides recommendations for your ECS clusters to show you resource optimization opportunities to potentially reduce your monthly spend.

The recommendations are computed by analyzing the past utilization of CPU and memory of your service. ECS workloads are called services.

You can also tune recommendations by changing the percentage of CPU/memory requests buffer (in the **Buffer to be considered for CPU/Memory values** setting). ECS Services only have request and don't have limits.

This topic describes how CCM computes ECS service recommendations and how you can use them to potentially reduce monthly costs.

Before using recommendations in your ECS cluster environment, ensure that you evaluate their impact thoroughly. The person reviewing the recommendations should be able to understand the impacts identified in the recommendations, as well as the impact on the infrastructure and business.
Using recommendations without proper assessment could result in unexpected changes, such as issues with system performance or poor reliability.

## Before You begin

* [CCM Perspectives](../../3-use-ccm-cost-reporting/1-ccm-perspectives/1-create-cost-perspectives.md)

### Prerequisites

To obtain ECS recommendations, configure an AWS CCM Connector with the Inventory Management feature enabled.

No Delegate setup is required. All utilization metrics are obtained using a cross account IAM role.
See [Set Up Cloud Cost Management for AWS](../../get-started/onboarding-guide/set-up-cost-visibility-for-aws.md).

## How are recommendations computed?

The recommendations are computed by analyzing the past utilization of CPU and memory of your service. ECS workloads are called services.

ECS recommendations are computed both for AWS Fargate and EC2 spot instances.

The implementation uses a histogram method to compute the recommendations.

The computation adds a 15% buffer to the recommended resources by default. CCM also allows you to add any additional buffer using the **Tune recommendations** option.

When you enable [Cost Visibility](../../get-started/onboarding-guide/set-up-cost-visibility-for-aws.md) for your ECS cluster, Harness starts collecting CPU and memory resource utilization metrics for every service present in the cluster every minute.

The utilization data collected every minute is then aggregated in the Delegate for a 20-minute window. The 20-minute aggregated data is then sent to Harness:

* **CPU**: For CPU values, a partial histogram for the last 20 minutes is sent.
* **Memory**: The maximum value of the memory is sent as a single data point.

We use this data for further processing and to compute the complete histogram displayed in the UI (partial histograms are merged for the CPU and memory histogram is computed using the data points).

Each of these daily histograms has an equal weightage for a given task. As a result, if you select the last 30 days of data to aggregate, we will assign equal weightage to each of the 30 days.

You can also tune recommendations by changing the percentage of recommended CPU and memory requests buffer.

The task definitions for AWS Fargate can only be set to predefined values. For more information, go to [AWS Fargate Task Definitions](https://docs.aws.amazon.com/AmazonECS/latest/userguide/fargate-task-defs.html). Therefore, the recommendations are rounded off to the nearest configuration available on ECS Fargate.

### Why Histogram?

A histogram is used to account for the seasonality of high resource utilization on certain days of the week. Assume your application receives a lot of traffic (and thus a lot of resource utilization) on weekends, and we are using a decaying histogram. In that case:

* If you view service recommendation on Friday and selected the last seven days of utilization data, then Saturday will be given the least weightage, followed by Sunday, hence the recommended resources will be low.
* If you view the service recommendation on Monday, Sunday will be given the most weightage, hence your recommended resources may be high.

To avoid this, we use the histogram method and give equal weight to all previous days.

## Types of service recommendations

The recommendations are categorized as the following:

* Cost Optimized
* Performance Optimized

### Cost Optimized

The cost-optimized recommendations are computed as the following:

* The lower bound is based on the 50th percentiles of CPU samples and memory peaks.
* There is no upper bound for CPU samples and memory peaks are based on the 95th percentile. It is recommended not to set the upper bound for the CPU samples, because the CPU is considered a compressible resource.
* There is no limit set for the CPU. This is to avoid the throttling of the services when there is a spike in CPU usage. The usage of the CPU may go up in certain conditions, for example during the service start. In such a scenario, the CPU can burst and get the required additional resources.
* The potential monthly spend and savings are calculated based on the 90th percentiles of CPU samples and memory peaks.

Since the recommendations are computed using the 50th percentile of the CPU samples and memory peaks, this may potentially lead to system performance issues. Before using cost-optimized recommendations, ensure that you evaluate the recommendation's impact thoroughly.

### Performance Optimized

The performance-optimized recommendations are computed using the 95th percentile of CPU samples and memory peaks. Because of this, the probability of having any effect on the performance is minimum. However, the cost may go high for the resources that are optimized using this method.

The potential monthly spend and savings are calculated based on the 90th percentiles of CPU samples and memory peaks.

## Tune and share recommendations

You can tune your recommendations by adding a buffer to the resource preferences.

In **% Buffer to be considered for CPU/Memory values**, drag the slider to increase or decrease the percentage of the buffer. By default, it is set to 0.

The resource recommendations are based on the percentage of the buffer you set.

### Sharing recommendations

When you tune a recommendation, the URL for the recommendation captures your changes.

You can see the changes following `details?` in the URL. For example, `details?buffer=10&QoS="GUARANTEED"`.

Capturing your changes in the URL enables you to share your tuned recommendation and ensure others can see you tuning. Simply tune the recommendation and then share the URL.

Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
Harness Cloud Asset Governance provides tools to optimize your cloud spend and avoid unnecessary costs. By leveraging these recommendations, you can better control your cloud expenses while ensuring that your cloud infrastructure is optimized for maximum efficiency and cost-effectiveness.

You can view the recommendations for all of your Cloud accounts on the recommendations page.

The following resources can be optimized with Asset Governance:

### AWS Resource Coverage

- EC2 instances
- EBS
- ELB
- Cache-cluster
- S3 buckets
- Lambda functions
- RDS (Relational Database Service) instances
- CloudFormation stacks

To view all the AWS recommendations, please see [here](https://developer.harness.io/docs/cloud-cost-management/use-ccm-cost-governance/asset-governance/aws/AWS-recommendations).

### Azure Resource Coverage

- Virtual Machines (VMs)
- Storage accounts
- App services
- Cosmos DB accounts
- SQL server
- PostgreSQL servers
- Key Vaults

To view all the Azure recommendations, please see [here](https://developer.harness.io/docs/cloud-cost-management/use-ccm-cost-governance/asset-governance/gcp/gcp-recommendations).

### GCP Resource Coverage

- Compute Engine instances
- Cloud Storage buckets
- App Engine applications
- Cloud SQL instances
- Cloud IAM policies

To view all the GCP recommendations, please see [here](https://developer.harness.io/docs/cloud-cost-management/use-ccm-cost-governance/asset-governance/Azure/azure-recommendations).
171 changes: 171 additions & 0 deletions docs/cloud-cost-management/content/recommendations/node-pool-recs.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,171 @@

One of the most impactful ways to reduce spend on Kubernetes infrastructure is to make sure your clusters are optimally sized for the workloads and node pools they run. Harness CCM recommends optimal compute resources for your workloads and node pools to help you reduce costs and improve performance.

Recommendations are produced by analyzing your historical utilization metrics. CCM recommends you choose the optimal resource configuration based on your utilization data and requests metrics for pods.

This topic describes how CCM computes node pool recommendations and how you can use them to potentially reduce monthly costs.


:::note
Before using recommendations in your cluster environment, ensure that you evaluate their impact thoroughly. The person reviewing the recommendations should be able to understand the impacts identified in the recommendations, as well as the impact on the infrastructure and business.

Using recommendations without proper assessment could result in unexpected changes, such as issues with system performance or poor reliability.
:::


:::info
Recommendations will not be generated for nodepools with multiple instance families. This applies to both native-managed clusters and clusters that are managed by third-party tools like spot.io.
:::

## Before You begin

* [Set Up Cloud Cost Management for Kubernetes](../../get-started/onboarding-guide/set-up-cost-visibility-for-kubernetes.md)
* [CCM Perspectives](../../3-use-ccm-cost-reporting/1-ccm-perspectives/1-create-cost-perspectives.md)

## Prerequisites

Harness CCM uses labels to process node pool recommendations. Make sure to add one of the labels listed in the following table for the respective cloud providers:



| **Cloud provider**| **Labels** |
| --- | --- |
| Amazon Web Services (AWS) |<ul><li>`eks.amazonaws.com/nodegroup​`</li> <li>`alpha.eksctl.io/nodegroup-name​`</li><li> `node-pool-name​`</li><li> `kops.k8s.io/instancegroup`</li><li>`nodegroup​`</li></ul>|
| Google Cloud Platform (GCP) | <ul><li>`cloud.google.com/gke-nodepool`</li><li> `nodegroup​`</li><li>`kops.k8s.io/instancegroup`</li></ul>|
| Microsoft Azure | <ul><li> `Agentpool​`</li><li> `node-pool-name​` </li><li> `nodegroup​`</li><li>`kops.k8s.io/instancegroup`</li></ul>|

## How are node pool recommendations computed?

:::note

- Node pool recommendations do not support node pools with autoscalers enabled.
- These recommendations should be treated as a nudge, not a source of accurate cost data in such cases.
- Please note: cost data might be incorrect for autoscaled node pools. To hide node pool recommendations for autoscaled pools, kindly reach out to [Harness Support](mailto:support@harness.io)

:::

The node pool recommendations are computed by analyzing historical utilization data and requests metrics of Pods. CCM recommends the optimal resource configurations for the Spot and On-demand instances. It uses the following parameters to determine the maximum node counts:

* Total CPUs
* Total memory
* Max CPUs
* Max Memory

The recommendations are calculated by aggregating the resource utilization and request across all pods running across nodes in the node pool. You can select the number of days to compute recommendations based on the utilization data. The available options are last 1 day, 7 days, and 30 days.


```
CPU, Memory: Max at a given instant [Aggregated Max(resource Utilization, requests)]
```
Let's try to understand how the recommendations are computed using the following example. Assume there are two nodes in a node pool, each with two pods running.


```
Time Instant 1:
Node1:
Pod1:
Util → 2.1 vCPU, Request → 4 vCPU
Pod2:
Util → 1.4 vCPU, Request → 1 vCPU

Node2:
Pod1:
Util → 1.1 vCPU, Request → 4 vCPU
Pod2:
Util → 0.9 vCPU, Request → 1 vCPU

Time Instant 2:
Node1:
Pod1:
Util → 2.2 vCPU, Request → 4 vCPU
Pod2:
Util → 1.5vCPU, Request → 1 vCPU
Node2:
Pod1:
Util → 2.0 vCPU, Request → 4 vCPU
Pod2:
Util → 0.3 vCPU, Request → 1 vCPU
```
The recommendations are calculated as the following:


```
Time Instant 1: [ Max (2.1, 4) + Max (1.4, 1)+ Max (1.1, 4)+ Max (0.9,1)] = [4 + 1.4 + 4 + 1] => 10.4

Time Instant 2: [ Max (2.2, 4) + Max (1.5, 1)+ Max (2, 4)+ Max (0.3,1)] = [4 + 1.5 + 4 + 1] => 10.5

So the Max CPU recommendation would be: Max (10.4, 10.5) = **10.5 vCPU**
```
Similarly, for memory, nodes will be the max number of nodes in the observation interval.

Node pool recommendations also offer the flexibility of tuning the recommendations by setting the resource configuration preferences. See **Tune Recommendations**.


### Tune and share recommendations

You can tune your recommendations by modifying the value of CPU, memory, node counts, and instances.

You can also add a buffer to the resource preferences.

CCM generates context-aware cluster sizing recommendations based on the resource configurations that you provide.

To tune your recommendations, set your preferences for the following resources:

* CPU
* RAM
* Preferred Minimum Node count
* Preferred Instance families

#### Option: Preferred resource needs

The value for CPU and memory is auto-populated by aggregating the resource utilization and request across all pods running across nodes in the node pool.

* **CPU (vCPU)**: Set preferences for the CPU.
* **RAM (GiB)**: Set preferences for memory.
* **Buffer**: This section allows you to add an additional buffer to the resources for calculating the recommendations.

By default, the recommendation computation adds a 15% buffer to the recommended resources. This option allows you to add an additional buffer to your resources.



Once you apply the preferences, modified values are used for calculating the recommendations.

#### Option: Largest workload requirements

The maximum workload that is observed based on the historical utilization that is scheduled on the nodes is used to calculate the value for this field. You can customize your CPU (vCPU) and RAM options (GiB).


#### Option: Preferred minimum node count

This option allows you to set the number of minimum nodes that are used for the recommendation. Use the **+** button to increase the node count and click **-** to decrease the node count.


#### Option: Preferred instance families

You can use this option to limit the recommendations to a certain machine type/instance family. For example, you have RIs/commitments on a specific machine type and only want to use that instance family.

In **Preferred Instance families**, click **add preferred instance families**.

Select your preferences and click **Save Preferences**. The category of the instance families will depend on the cloud provider type. The following example shows the GKE.


Once, you've made all the changes, click **Apply Preferences** or click **Reset to default**.



:::important note
For nodepool recommendations, we base our calculations using public pricing data, which may differ from actual price.
:::

#### Sharing recommendations

When you tune a recommendation, the URL for the recommendation captures your changes.

You can see the changes following `details?` in the URL. For example, `details?buffer=10&QoS="GUARANTEED"`.

Capturing your changes in the URL enables you to share your tuned recommendation and ensure others can see you tuning. Simply tune the recommendation and then share the URL.

### Next steps

* [Optimize Kubernetes Costs with Workload Recommendations](/docs/cloud-cost-management/use-ccm-cost-optimization/ccm-recommendations/workload-recommendations)

Loading
Loading