Container Request Right-Sizing Recommendation API (V1) - Deprecated
The container request right-sizing recommendation API provides recommendations for container resource requests based on configurable parameters and estimates the savings from implementing those recommendations on a per-container, per-controller level. Of course, if the cluster-level resources stay static then you will likely not enjoy real savings from applying these recommendations until you reduce your cluster resources. Instead, your idle allocation will increase.
The endpoint is available at
The request right-sizing recommendation includes an estimate of the savings that can be realized by applying the request right-sizing recommendations. To calculate this estimation, we use each container's lifetime and the overall data window (max observed cluster lifetime within
window). We assume each container will run on the same node (and therefore have the same resource costs) it ran on historically; calculate the monthly rate for that container with the new, reduced resource requests; and then we scale that monthly rate by
container lifetime in window/data window. This will underestimate savings for recently-created controllers (e.g. a Deployment created 3 days ago in a 7-day data window will be assumed to run for 3/7 of the next month when calculating monthly savings), but avoids some edge cases that vastly overestimate savings.
We have a 1 hour window with 2 pods that look like they each have their own controller. Each pod has 1 container (with the same name).
All CPU costs are $7/core-hour
Pod 1 ran for 15 minutes [t=15min, t=30min], allocated 3 cores, and used an avg and max of 1 core.
Pod 2 ran for 20 minutes [t=45min, t=60min], allocated 3 cores, and used an avg and max of 2 cores.
| --- | Pod 1 exists
| ---| Pod 2 exists
0 min 60min
Window = [0min, 60min]
We'll right-size with a target utilization of 100%:
- Pod 1 will be right-sized to an allocation of 1 core.
- Pod 2 will be right-sized to an allocation of 2 cores.
What should the estimated monthly savings of this right-sizing be?
Controller 1 = Pod 1 ran for (15/45) of the known duration of the cluster being alive (we don't know if it was alive from [t=0, t=15]). That's (45 min / (60 min/hr) / (730 hr/month)) of a month.
Within the query window, the pod could haved saved: 2 cores * (15min / (60 min/hr)) = 0.5 core-hours 0.5 core-hours * $7/core-hour = $3.50
"If that 45 minute window is representative for 30 days (730 hrs) then we scale the savings by 1 / (45 / 60 / 730)": $3.50 * 1 / (45 / 60 / 730) = $3406.67
For Pod 2 = Controller 2 we can take the same numbers from Pod 1 = Controller 1 and halve the savings because it has half the CPU core savings.
Savings: $3406.67/mo / 2 = $1703.34/mo
Total savings = $3406.67/mo + $1703.34/mo = $5110.01/mo
We resize the shared container to 2 cores, reducing the savings of pod 1 to be the same as the savings for pod 2, because both pods had the same overall allocation.
Controller 1 = Pod 1 and Pod 2 ran for 45/45 minutes of the known duration of the cluster being alive (we don't know if it was alive from [t=0, t=15]). That's (45 min / (60 min/hr) / (730 hr/month)) of a month.
Within the query window, Pod 1 could haved saved: 1 cores * (15min / (60 min/hr)) = 0.25 core-hours 0.25 core-hours * $7/core-hour = $1.75
Pod 2 saves the same amount = $1.75
That's a total savings for the controller of: $1.75 * 2 = $3.50
"If that 45 minute window is representative for 30 days (730 hrs) then we scale the savings by 1 / (45 / 60 / 730)": Total savings = $3.50 * 1 / (45 / 60 / 730) = $3406.67/mo
curl -G \
-d 'targetCPUUtilization=0.8' \
-d 'targetRAMUtilization=0.8' \
-d 'window=3d' \