Committed usage discount and autoscaling GKE

[Paolo Mainardi]

Dear all,

I have the following scenario, a gke cluster with 2 pool composed by the following machine types:

* default: n1-standard-2: running at least 2+ vms during the month (here is where the sustained usage discount is applied)

* build: n1-standard-4: this is an autoscaling pool from 0 to N which is used by gitlab to do CI/CD, the number of the machines running in a month is not that predictable, anyway during the day the number is around 3/4 VMS then they go to 0 during the night.

Considering the above described scenario, the question is how and if the committed usage discount can be applied in a context where vms can be created and destroyed in any moment but with a sustained use during the months. 

[Carlos (Cloud Platform Support)]

Hi Paolo, 

Sustained discounts are only applied when the VM is running for at least 25% of the month. Therefore, if autoscaler is deleting the VMs before that time, I do not believe a discount will be applied. It does not matter if new VMs are span afterwards (they are other VMs). If you set up a minimum node pool size, those instances will not be deleted by autoscaler and can receive the discount. If your load were predictable you could also consider applying for committed use discounts.

[Paolo Mainardi]

Hi Carlos, thanks for your reply.

The question it was more related to the committed use discounts, considering the scenario where machine are created and destroyed at anytime, can the committed discount be applied ? If i understood well the committed use discount it is applied against the number of hours of vcpu/ram despited than the running machine.

[Carlos (Cloud Platform Support)]

Thanks for getting back Paolo.

I do agree with you. According to the article, commitments are for aggregate vCPU and Memory so they are not tied to a specific instance or instance shape.

For committed discounts it should not matter autoscaler creates//delete VMs but it does for the sustained discounts.

[Paul Nash]

Generally, yes Committed Use Discounts are designed to be flexible for exactly this kind of scenario.

Unlike some other providers' bulk discounts, GCP Commitments are purchased based on the amount of vCPU and RAM you expect to be using over a time period, regardless of the shape or number of instances you run. You can change machine shapes at any point in time with no penalties or conversions, or apply the discounts across a range of different machines you are running. So for example, if you buy 5 vCPU worth of commitment, the system will give a discount for 5 of the vCPU you are using at every point in time, and this is evaluated continuously as your fleet usage changes. Note, it is per unit time meaning, you cannot "store up" the discount. If you ran 0 vCPUs for 1 hour and 10 vCPUs for the next hour, you would pay the monthly equivalent for 5 discounted vCPUs the first hour (even though you're running 0), and 5 discounted vCPUs the second hour, and the hourly/minutely/secondly requirement of the extra 5 vCPUs in that second hour. The extra 5 vCPUs in that hour would be eligible for consideration as sustained use discounts, however.

Finally, about sustained use discounts. What was said above might not be entirely correct regarding whether you would qualify for any SUD; we do some calculations to help you out in those use cases. Assume for example that you had no committments purchased and had an autoscaling use case. SUD calculates what our docs call "inferred instances." That means that if you run multiple instances that are the same size and shape, in the same zone, then we treat them as if they were one machine for the purpose of calculating the discount. So if your autoscaler ran extra instances at certain points in time, you would likely see some discount if the sum of those instances were running 25% or more of the month. We designed this "inferring" exactly for that type of scenario.

Now, when you have committed use discounts, then sustained use "inference" calculations are done a little differently. In that case we combine together the usage of VMs that are in the same "family" (e.g. all n1-standards, all n1-highmems, etc). This is more compatible with the way committed use discounts work, which could otherwise lead to lower discounts.

Paulo, in your scenario I believe it may make sense to find your lowest number of vCPUs running at any given time and buy a commitment for that many vCPUs and RAM. For the build machines, if you are running multiple machines for 30-50% of the hours of the day, I would expect you will see some SUD for that through inferred instances.

For more details on all this, the docs pages are at:

https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts

https://cloud.google.com/compute/docs/sustained-use-discounts

Hope this helps!

--
© 2017 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
 
Email preferences: You received this email because you signed up for the Google Compute Engine Discussion Google Group (gce-discussion@googlegroups.com) to participate in discussions with other members of the Google Compute Engine community and the Google Compute Engine Team.
---
You received this message because you are subscribed to the Google Groups "gce-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gce-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to gce-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gce-discussion/ec89e225-45fc-46c2-a9b5-31ffa31f2b4f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Paul R. Nash |

Group Product Manager, Compute Engine |

paul...@google.com |

206-876-1620