Introduction to cost estimation policies

Introduction to estimation policies

Single-resource estimation policy

The single-resource estimation policy is the default cost estimation policy. You can use this policy to calculate cluster costs based on the resource scheduling water level.

Scenarios

The scheduling water level is the ratio of requested resources to total resources. In most scenarios, the cluster's scheduling water level is determined by the resource type with the highest requests. Therefore, the single-resource estimation policy is ideal for scenarios where the scheduling water level of one resource is much higher than that of other resources, and where application resource requests are concentrated on a single resource type.

For example, consider memory-optimized applications such as those written in Java. The application pods request large amounts of memory resources (Memory Request) from the cluster. This increases the memory scheduling water level. Memory becomes the "expensive" resource that determines whether the cluster can schedule more pods. CPU becomes the "cheap" resource. In this scenario, using the single-resource estimation policy for cost calculation is more reasonable. If memory accounts for 90% of the cluster's scheduling water level, the calculated cost can also reach 90% of the total cluster cost. This ensures that the cost allocation accurately reflects the resource constraints.

How it works

In the single-resource policy, the pod cost is calculated using either CPU or memory metrics.

Single pod cost calculation

The formula for calculating the cost of a single pod is as follows. The resource can be either memory or CPU.

Namespace-level cost calculation

A namespace is a group of pods with common fields. After you accurately estimate the cost percentage of each pod, you can calculate namespace-level costs. To do this, you can calculate the cost ratio of all pods in a namespace to all pods in the cluster and then multiply this ratio by the total cluster bill.

• The formula for calculating namespace cost is as follows:

  

• The formula for calculating the namespace cost ratio is as follows:

  

Weighted hybrid-resource estimation policy

Scenarios

If your cluster has a mix of CPU-optimized and memory-optimized applications, or if the CPU and memory water levels are balanced, you can use the hybrid-resource estimation policy. In this case, the "value" of CPU and memory is similar. The ratio of their scheduling water levels can be used to measure the value of each resource.

How it works

In the weighted hybrid-resource estimation policy, the pod cost is calculated using a weighted mix of CPU and memory metrics. The weights are determined by the ratio of the cluster's CPU and memory scheduling water levels.

Single pod cost estimation

Unlike the single-resource policy, the hybrid-resource policy calculates the pod cost using a mixed estimation of CPU and memory. The formula for calculating the pod cost is as follows:

The weight values are determined by the cluster's scheduling water levels. The formulas for calculating the CPU and memory scheduling water levels, their ratio, and the weights are as follows:

• CPU scheduling water level:

  

• Memory scheduling water level:

  

• CPU weight:

  

• Memory weight:

  

Examples

The following two examples show how to choose a cost estimation policy.

Example 1: Concentrated application resource requests in a cluster

In the following figure, two memory-intensive applications are deployed in the cluster. One application requests 1 vCore and 2 GB of memory, and the other application requests 1 vCore and 4 GB of memory. In this case, the memory scheduling water level of the cluster is 90% and the CPU scheduling water level is 20%. Assume that the total daily cost of the cluster is 200 CNY.

• Using the single-resource estimation policy:

  • If you use single-resource estimation based on memory, the calculated cost is 200 × 90% = 180 CNY, which accurately reflects the cluster's scheduling constraints.

  • If you use single-resource estimation based on CPU, the calculated cost is 200 × 20% = 40 CNY. This method fails to account for the memory bottleneck and results in a large amount of unallocated idle cost.

• Using the weighted hybrid-resource estimation policy:

  If you calculate costs by weighting the two resources based on their scheduling water levels, and assume the weights for memory and CPU are 80% and 20% respectively, the calculated cost is 180 × 0.8 + 40 × 0.2 = 152 CNY. This leaves 28 CNY unallocated compared with allocating costs based solely on memory.

In summary, the memory-based single-resource estimation policy allows 90% of the total cost to be allocated. Therefore, for scenarios with concentrated application resource requests, use the single-resource estimation policy.

Example 2: Balanced application resource requests in a cluster

In the following figure, a memory-intensive application and a CPU-intensive application are deployed in the cluster. One application requests 1 vCore and 4 GB of memory, and the other application requests 4 vCores and 1 GB of memory. In this case, the CPU scheduling water level of the cluster is 40% and the memory scheduling water level is 50%. Assume that the total cost of the cluster is 200 CNY per day.

• Using the single-resource estimation policy:

  • If you use single-resource estimation based on memory, the calculated cost is 200 × 50% = 100 CNY.

  • If you use single-resource estimation based on CPU, the calculated cost is 200 × 40% = 80 CNY.

• Using the weighted hybrid-resource estimation policy:

  If you calculate the cost by applying weights to both resources based on the scheduling water level, and you set the weights for memory and CPU to 56% and 44% respectively, the calculated cost is 100 × 0.56 + 80 × 0.44 = 91.2 CNY. This leaves only 8.8 CNY of cost unallocated compared with the memory-based single-resource policy.

In summary, although the memory-based single-resource estimation allocates more cost than the weighted hybrid-resource estimation in this example, the CPU and memory scheduling water levels are close. The requested amounts for both resources are similar. This means the value of the two resources is similar, and their costs are not significantly different. Therefore, when you consider all factors, it is better to choose the weighted hybrid-resource estimation policy.

FAQ

How can I resolve the issue of idle costs that may arise from the hybrid-resource estimation policy?

Cause: Using the hybrid-resource policy for a cluster might increase idle costs. This is because the scheduling water level of an application's key resource is often higher than that of its non-key resources. When the key resource reaches a bottleneck, non-key resources will always have idle capacity. In other words, when the scheduling water levels of two resources differ significantly, the resource with the lower scheduling water level generates idle costs. With a single-resource policy, the cost of this idle portion can be allocated. However, using a hybrid-resource policy might increase idle costs.

Solution: To resolve the idle cost issue with the hybrid-resource estimation policy, you can choose more suitable instance types based on your application's resource needs. This helps keep the CPU and memory scheduling water levels balanced. Alternatively, you can use the single-resource estimation policy.

References

• If you have strict requirements for cloud resource cost allocation and need to customize the business logic, you can use custom accounting policies. For more information, see Custom cost accounting policies.

• You can use HTTP API commands to view reported data for custom development. For more information, see Overview of obtaining cost data through an API.