How ACK’s Resource Profiling Optimizes Kubernetes CPU & Memory Requests

Introduction

Kubernetes abstracts CPU, memory and other resources, allowing users to declare resource specifications for containers. Manually setting these specifications often leads to over‑provisioning (wasting resources) or under‑provisioning (risking stability). ACK (Alibaba Cloud Container Service for Kubernetes) provides a resource‑profiling feature that automatically recommends request and limit values for Pods.

Challenges of Manual Resource Specification

Administrators add buffers to guarantee stability, causing request values to far exceed actual usage and resulting in low cluster utilization.

When cluster utilization is high, administrators may shrink requests to increase density, which can introduce stability risks under traffic spikes.

The manual process does not scale efficiently as the number of workloads grows.

Resource Profiling Concept

Resource profiling captures an application’s consumption characteristics—including CPU, memory, network bandwidth, and disk I/O—over time. By aggregating historical usage data, specifications can be set based on concrete evidence rather than guesswork. Temporal patterns such as daily peaks, weekly cycles, and promotional traffic spikes are incorporated to enable “peak‑shaving” and “valley‑filling” in resource allocation.

Technical Foundations

Half‑life sliding‑window model : each data sample at time τ is weighted by t^-1/2, where t½ is the half‑life; after one half‑life interval the weight halves, giving newer data more influence.

Histogram compression : minute‑level or second‑level metrics are stored as histograms. The x‑axis represents resource quantity, the y‑axis the count of samples in each bucket. Bucket width is about 5 % of the range, so a workload’s history can be represented with roughly 200 buckets, reducing storage and speeding up cold‑start analysis.

Quantile‑based recommendation algorithm : instead of a simple time‑based percentile, the algorithm computes the quantile of compute‑power demand, distinguishing occasional spikes from sustained load. Example: nine samples of 100 MB and one sample of 900 MB yield a 90 % quantile of 900 MB under the compute‑power quantile, providing a more accurate request.

Additional factors such as sample confidence, OOM events, and half‑life weighting are incorporated into the final recommendation.

Case Study

A test Deployment was run on an ACK cluster with resource profiling enabled. Prometheus dashboards displayed three series: actual CPU usage (blue), profiling recommendation (orange), and original request (green). Adjusting the request to match the profiling recommendation saved cluster resources without sacrificing stability.

Future Directions

Upcoming enhancements will expose profiling capabilities through a console UI, further lowering the barrier for users to adopt intelligent resource recommendations.

References

Open‑source Koordinator project (underlying scheduling optimizations):

https://github.com/koordinator-sh/koordinator