Because pods in ACK clusters do not map one-to-one to cloud resources and have shorter lifecycles, estimating pod-level cost is key to allocating department and application spend. The ACK cost management suite provides estimation policies based on scheduling watermarks (resource utilization ratios). This topic introduces those policies.
The ACK cost management suite provides two cost estimation policies based on resource watermarks (resource utilization ratios). Each calculates the cluster cost share for individual pods and namespaces.
Choose a cost estimation policy
|
Policy |
Allocates cost by |
Recommended when |
|
Single resource cost estimation |
CPU or memory alone |
One resource dominates—for example, CPU watermark is much higher than memory watermark, or most applications are memory-intensive. |
|
Weighted resource cost estimation |
CPU and memory, weighted by recommended or custom utilization ratiosand memory, weighted by utilization ratios |
CPU and memory utilization are similar, or applications consume both resource types. |
Single resource cost estimation
The default policy in the cost management suite. Calculates pod cost from a single resource dimension: CPU or memory.
Applicable scenarios
A resource watermark is the ratio of requested to allocatable resources. When one watermark is much higher than the other, that resource drives scheduling and dominates cluster cost.
Example: Memory-intensive applications such as Java workloads request large amounts of memory. If memory watermark reaches 90%, memory supply determines pod scheduling, and memory cost accounts for 90% of total cluster cost. The single resource policy captures this accurately.
Pod cost calculation
Pod CPU or memory cost formula:
Namespace cost calculation
A namespace groups related pods. Its cost equals the sum of pod cost ratios in the namespace, multiplied by the total cluster bill amount.
Namespace cost formula:
Namespace cost ratio formula:
Weighted resource cost estimation
Calculates pod cost using both CPU and memory, weighted by cluster-level utilization ratios, for balanced allocation when workloads consume both resource types.
Applicable scenarios
Use this policy when:
-
The cluster's CPU and memory watermarks are close.
-
Applications consume both CPU and memory.
When CPU and memory costs are similar, their watermarks provide a meaningful basis for weighted allocation.
Pod cost calculation
This policy calculates pod cost from CPU and memory weights derived from cluster-level watermarks.
Pod cost formula:
Watermark and weight formulas
CPU watermark, memory watermark, CPU weight, and memory weight formulas:
-
CPU watermark (CPU utilization ratio):
-
Memory watermark (memory utilization ratio):
-
CPU weight:
-
Memory weight:
Comparison of policy results
Example 1: One resource type dominates
Setup: Two memory-intensive applications run in a cluster.
| Application | vCore requested | Memory requested |
|---|---|---|
| App A | 1 vCore | 2 GB |
| App B | 1 vCore | 4 GB |
-
Memory watermark: 90%
-
CPU watermark: 20%
-
Daily cluster cost: CNY 200
Single resource cost estimation results:
| Resource dimension | Pod cost | Calculation | Unallocated cost |
|---|---|---|---|
| Memory | CNY 180 | CNY 200 x 90% | CNY 20 |
| CPU | CNY 40 | CNY 200 x 20% | CNY 160 |
Allocating by memory captures 90% of cluster cost. Allocating by CPU leaves 80% unallocated, though only 10% of memory remains for scheduling.
Weighted resource cost estimation results:
-
Memory weight: approximately 80%
-
CPU weight: approximately 20%
-
Pod cost: CNY 152 (CNY 180 x 80% + CNY 40 x 20%)
-
Unallocated cost: CNY 48
Result: The single resource policy (using memory) allocates CNY 180 out of CNY 200, closely matching actual consumption. The weighted policy allocates only CNY 152, leaving CNY 48 unallocated. For clusters where one resource dominates, the single resource policy is more accurate.
Example 2: Both resource types are consumed
Setup: One memory-intensive and one CPU-intensive application run in a cluster.
| Application | vCore requested | Memory requested |
|---|---|---|
| App A | 1 vCore | 4 GB |
| App B | 4 vCores | 1 GB |
-
CPU watermark: 40%
-
Memory watermark: 50%
-
Daily cluster cost: CNY 200
Single resource cost estimation results:
| Resource dimension | Pod cost | Calculation |
|---|---|---|
| Memory | CNY 100 | CNY 200 x 50% |
| CPU | CNY 80 | CNY 200 x 40% |
Weighted resource cost estimation results:
-
Memory weight: approximately 56%
-
CPU weight: approximately 44%
-
Pod cost: CNY 91.2 (CNY 100 x 56% + CNY 80 x 44%)
-
Unallocated cost: CNY 8.8
Result: CPU and memory watermarks are close (40% and 50%), so costs are similar. The weighted policy accounts for both dimensions, producing CNY 8.8 unallocated cost versus CNY 100 or CNY 120 unallocated under single resource allocation. For mixed workloads, the weighted policy produces more balanced results.
Reduce unallocated cost with the weighted policy
Cause: Unallocated cost occurs when one resource watermark is much higher than the other—the dominant resource hits a bottleneck while the other stays idle. For example, if CPU watermark far exceeds memory watermark, idle memory exists. The single resource policy can allocate this cost, but the weighted policy cannot.
Solution: Select Elastic Compute Service (ECS) instance types matching your workload resource profile to keep CPU and memory watermarks close. Alternatively, switch to the single resource policy.
Cost data API
-
Retrieve cost insights data via API for custom development. See Call an API to query cost data.