You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initally sparked by a casual conversation with @nirs about a bug around secret objects,
I took a peek at the source code and it indeed looks like some controllers are caching all configmaps and secrets.
This both:
Aggressively increases memory usage (think: production cluster of an org with infinite CMs/Secrets)
Poses a security threat with Ramen having access to all user sensitive data in the cluster - rbac practice reference
This can be solved by instead only caching the secrets/configmaps in the ramen namespace
From a quick read, ramen only cares about those anyway
May have to kill the existing ramen pod.
Could also watch the memory usage grow with minikube addons enable metrics-server --profile dr1
and then kubectl --context dr1 top pod -n ramen-system
See also
https://bugzilla.redhat.com/2283489 Bug causing creation of up to 47,000 secrets consuming 329 MiB, leading to OOM in ramen and other operators.
The text was updated successfully, but these errors were encountered:
Initally sparked by a casual conversation with @nirs about a bug around secret objects,
I took a peek at the source code and it indeed looks like some controllers are caching all configmaps and secrets.
This both:
This can be solved by instead only caching the secrets/configmaps in the ramen namespace
From a quick read, ramen only cares about those anyway
ramen/controllers/drcluster_controller.go
Lines 162 to 165 in da2b47b
This can be demonstrated in one of the default
drenv
environments (I usedtest/envs/regional-dr-kubevirt.yaml
):May have to kill the existing ramen pod.
Could also watch the memory usage grow with
minikube addons enable metrics-server --profile dr1
and then
kubectl --context dr1 top pod -n ramen-system
See also
The text was updated successfully, but these errors were encountered: