Resize pod resource requests and limits of the most inappropriately sized pods

There is a list of pods within a management cluster with a huge gap between effective usage and current memory request. Such pods deserve a resizing study (note that this view is regarding a stable unloaded management cluster with a single workload cluster attached, it does not represent consumption during special event or load):

ns	pod	mem request	mem usage %/R	MR
Flux-system	helm-controller	64 Mi	300	!3946 (merged)
Flux-system	kustomize-controller	64 Mi	300	!3962 (merged)
keycloak	cnpg-keycloak	4 Gi	3 to 15	!3553 (merged)
kube-system	kube-apiserver	1 Gi	450	sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster!753 (merged)
kube-system	rke2-ingress-nginx-controller	90 Mi	350	!3975 (merged)
kyverno	kyverno-background-controller	64 Mi	350	!3882 (merged)
loki	loki-chunks-cache	9830 Mi	8	!3767 (merged)
loki	loki-results-cache	1229 Mi	1	!3767 (merged)
minio-logging	logging-pool	128 Mi	400	!3914 (merged)

Note: in most of the situations, the limits can be kept as it is but there is also a special attention to have regarding the limits as soon as the effective usage is often reaching a high percentage of the limit (to prevent OoM). E.g. this the case regarding the thanos-receive pod (thanos ns) which is reaching 70% of its memory limit (it should be increased from 6 Gi to 8 Gi).