When CPU requests and limits are assigned to a pod,
the pod will be guaranteed the requests, up to the limits.
Even if there are spare CPU cycles, the pod cannot use
them. Thus, pods can be unnecessarily denied compute
when they need to burst if the limits are set.
Therefore, it is not recommended to set CPU limits
since the CPU requests are already guaranteeing that
no pod will be starved at least for its requests.
Signed-off-by: travisn <tnielsen@redhat.com>
The sample files placement rules are too restrictive for small clusters.
The comment provides a hint how to fix this.
Closes: https://github.com/rook/rook/issues/11658
Signed-off-by: Michael Lipp <mnl@mnl.de>
This commit updates the CephFS mirroring documentation
around Peer tokens to get the token created correctly.
Signed-off-by: Gaurav Sitlani <gauravsitlani@riseup.net>
By default, we should set the priority class to one of the built-in
priority class names to ensure that pods critical to the storage
will be able to remain running when resources are low. Otherwise,
critical rook pods could be evicted and affect many other pods
that rely on the storage to continue functioning. The options have
been available in the CRs, but until now we have just not set the
defaults in the examples. Critical rook components are now set to
the priority class system-node-critical if they are generally pinned
to a node, and system-cluster-critical if they are critical to the storage.
Some pods such as the operator and crash collector do not have a
default priority class set in the examples since they don't affect
the data path.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Blaine Gardner
travisn
parth-gr
Michael N. Lipp
Gaurav Sitlani
Denis Egorenko
Sébastien Han