Document Kubernetes limits and requests for Garnet

[mloskot]

Feature request type

enhancement

Is your feature request related to a problem? Please describe

The official Helm chart includes an example of the resources limits/requests:

garnet/charts/garnet/values.yaml

Lines 117 to 124 in d7d2bc6

	# -- Resources
	resources: {}
	# limits:
	# cpu: 200m
	# memory: 64Mi
	# requests:
	# cpu: 10m
	# memory: 16Mi

but, there is no explanation of those are defaults or recommended values or just 'syntactical' placeholders.

Describe the solution you'd like

At least a suggestion of minimum and recommended limits/requests should be documented to give users an idea, bearings.

Ideally, if Garnet's chart could specify the resources requirements with pre-defined presets like this chart does it for Redis providing
none, nano, micro, small, ... presets:
https://github.com/bitnami/charts/blob/a401c96b685d790344f960eab46e5aba87308f63/bitnami/common/templates/_resources.tpl#L15-L44

Describe alternatives you've considered

Trial and error using the limits from the comment above:

Additional context

• OOM Exceptions on heavy Usage #610

[badrishc]

I am not sure how we can choose the best presets up front as this is highly workload dependent. You have to decide how to partition your total available memory across: (1) main store index; (2) main store log; (3) object store index; (4) object store log; (5) object store heap size; (6) AOF size in memory. These decisions are based on various workload-level attributes such as number of keys indexed, whether the workload is mostly strings or objects, whether AOF is enabled, etc.

I suppose we could make some rough assumptions and allocate accordingly. We don't really work with Helm charts actively, but if anyone in the community wants to take a stab at this, feel free to contribute.

[mloskot]

@badrishc Thank you for your response.
It is clear to me that an administrator is supposed to tune Garnet parameters. What I suggest is to provide some required or reasonable defaults. Perhaps Garnet could apply rationale similar to this bitnami/charts#23410

While it is true that this is a task of the operator to adapt the resources to their use case, we do not explicitly mention in our documentation that a deployment without resources is not recommended for production.
(...) a set of presets (nano, micro, small...), which will be configured in our charts by default to the smallest size that works in our testing.

The defaults could help Garnet users like myself, when I initially tried simplest storage-less test deployment of Garnet using resources based on Redis nano preset:

eventually realising it needs at least equivalent of small.