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
This makes it difficult for us to effectively manage resources; the only quota that can be set for BestEffort class pods is a limit on the number of pods. If we want to better manage resources like memory we would like to prevent people from creating BestEffort pods.
There are two ways to do this:
We can just set the quota for BestEffort pods to 0. Probably solved! But now when someone attempts to submit a simple workload it fails, with a message like:
Error from server (Forbidden): error when creating "STDIN": pods "sleeper-besteffort" is forbidden: exceeded quota: besteffort-pods, requested: pods=1, used: pods=0, limited: pods=0
Alternately, we can add a LimitRange to the project, which would automatically apply limits (and requests) to pods that don't provide them explicitly, resulting in it having a qos class of Burstable or Guaranteed.
I think the second option is going to be friendlier to novice users, since it allows them to copy-and-paste manifests that they have found in online documentation and have them work as expected.
The text was updated successfully, but these errors were encountered:
When first starting out with Kubernetes, people are probably going to be submitting workloads that end up in the "BestEffort" quota class, such as:
This makes it difficult for us to effectively manage resources; the only quota that can be set for BestEffort class pods is a limit on the number of pods. If we want to better manage resources like memory we would like to prevent people from creating BestEffort pods.
There are two ways to do this:
We can just set the quota for BestEffort pods to 0. Probably solved! But now when someone attempts to submit a simple workload it fails, with a message like:
Alternately, we can add a LimitRange to the project, which would automatically apply limits (and requests) to pods that don't provide them explicitly, resulting in it having a qos class of Burstable or Guaranteed.
I think the second option is going to be friendlier to novice users, since it allows them to copy-and-paste manifests that they have found in online documentation and have them work as expected.
The text was updated successfully, but these errors were encountered: