[Elasticsearch] Default values for resource policies makes it hard to have unset limits

[rccrdpccl]

Describe the feature: Set empty object as default value for resource policy for elasticsearch containers

Describe a specific use case for the feature: Often it is quite useful to have applications running without limits in its resource policy (for example, setting CPU limits causes throttling CPU time). At the moment is not easy to unset default values, forcing the user to set limits.

[jmlrt]

Hi @rccrdpccl & @pbecotte,

We may rediscuss internally but I think our policy is to always set a default value for requests/limits in our chart to ensure this meets production criterias.

I think it was already discussed in an issue or PR but can't find the link.

Meanwhile, despite I'm not sure we'll want to merge #445, using --set resources=null allows you to disable default resources requests/limits (--set resources.limits=null to disable only limits).

[rafael-romero-carmona-claranet]

Hello @jmlrt it is not recommended to set CPU limits but to use request to assure at least what each pod needs. If you add limits and your pod needs more CPU it could be a problem instead of anything useful.

Some docs

• https://twitter.com/tpeitz_dus/status/1133648291332263936
• https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestslimits-for-costefficiency-and-latency-highload

[jmlrt]

Hi @rafael-romero-carmona-claranet,

There is documentation mentioning that in some use cases add CPU limits can increase latency because of throttling (here, here, and here for example), this seem partly fixed with 5.4 kernel by torvalds/linux@de53fd7aedb1 and torvalds/linux@763a9ec06c40 and I didn't find a current state of this issue (most of the link about this issue are dated from the end of 2018 or begining of 2019).

In the other way, at Elastic, we have a strong opinion that memory request should always be equals to memory limits for Elasticsearch. As for CPU limits, we also recommend setting CPU request = CPU limits (this is currently not the case in default value and I'll add a PR soon to fix it) to ensure that performance stay consistent and we don't run into performance problems because another pod is suddenly using more cpu.

Please keep in mind that the default values we provide are the ones we recommend for most general use cases to ensure that a deployment with default values match our production criterias in term of consistent performance and availability in most case.

However anyone having more critical performance needs should still have a testing and tunning phase and override the default values with the ones that fits better for its specific use case.

That's why default values are overridable.

[pbecotte]

Fair enough. Helm recommends -not- setting defaults, so it actually came as somewhat of a suprise to me when I realized that they were set here. I am not sure I 100% agree with that recommendation though, so if you feel strongly about it please feel free to close as a won't fix :)

[rafael-romero-carmona-claranet]

Thanks for the answer @jmlrt
I agree with @pbecotte