The Kubernetes scheduler regards a "request" for resources as a minimum amount to allocate to a new container. That is the primary value it looks to when choosing where to place the pod in the cluster. Too high a request and the pod can be deemed unschedulable on any node. By contrast, the limit is the point where k8s will kill the container if it goes too high.

The webservice command, when increasing limits, should also increase requests proportionally. This will ensure that the "Burstable" qosClass isn't really a timebomb for nodes. It also will discourage people from automatically requesting very high limits since it will prevent their app from being scheduled if they are trying to claim too large a slice of the pie. Naturally, quotas still override this anyway, but this will bake smarter logic into the webservice CLI.