Allow Different Values for Resource Requests and Limits

[v3nturetheworld]

What is the motivation or use case for the feature?

Crunchy Postgres Operator added a number of flags that allow clusters to set different resource requests for CPU and Memory for Crunchy Postgres components. The --enable-memory-limits and --cpu flags (from what I understand from container-resources.json) sets the limit = request sizes. For our use case we force the CPU/memory limits cluster wide to be so small that pods will be unable to run unless the resource/memory limits are configured, basically to ensure there are always some reasonable limits in place and a memory/cpu leak doesn't get missed. Because of this, each pod has different values for resource requests and limits. Additionally it would be useful to be able to set container resource values on pgBackRest jobs.

Describe the solution you'd like

It would be useful to keep the default limits to be set to what the resource request size is like Crunchy currently has, but having additional flags such as --memory-limit, --memory-request, --cpu-limit and --cpu-request would allow more fine grain tuning of resource usage of a Postgres Cluster.

Describe any alternatives you've considered
Currently our approach is hard coding the memory limit and disabling the cpu limit using sed before the installer/postgres-operator.yaml is run like so:

Please tell us about your environment:

• Operating System: RHEL7
• Where is this running ( Local , Cloud Provider): local
• Storage being used (NFS, Hostpath, Gluster, etc): etcd and localstorage
• Container Image Tag: centos latest
• PostgreSQL Version: latest
• Platform (Docker, Kubernetes, OpenShift): Openshift
• Platform Version: 3.11

Additional context
Add any other context or screenshots about the feature request here.

[jkatz]

This is committed in 2f36f25 and 83689f3. This adds a slew of new flags (listed in #1567) that allows for the fine tuning of and remove the short-lived --enable-memory-limit / --enable-cpu-limit.

The original implementation was intended not to be limiting (no pun intended) but to coincide with some of our learnings about deploying PostgreSQL in Kubernetes and derived environments. However, it seems that it was too opinionated, and we decided to opt to provide more flexibility for deployments, much as @v3nturetheworld put forward.

This focused just on the "core 3" deployments, i.e. PostgreSQL, pgBackRest, and pgBouncer. Future work could be done on allowing the various Jobs to be tuned in a similar way, though it is possible to tune the template files for the jobs in the pgo-config ConfigMa.