Thanks Derek, this info is real useful. Will take a look limitRequestRatio and how it useful.
Would be great if you explain little bit on this parameter. We have all types of clients in terms of Qos. Since ours is corporate, we have to provide decent QOS and less contention at same time managing platform objectives of high density, better utilization of compute resources. At same time, we don’t want too much control from platform side except higher level and let app teams to manage their limits as suites to their apps. So tuning is little challenging -- Srinivas Kotaru From: Derek Carr <[email protected]<mailto:[email protected]>> Date: Wednesday, August 10, 2016 at 12:08 PM To: skotaru <[email protected]<mailto:[email protected]>> Cc: dev <[email protected]<mailto:[email protected]>> Subject: Re: few questions on quotas and limits Is there a particular density you are targeting? 1. pods per node 2. over-commit ratio for cpu 3. over-commit ratio for memory 4. do you want to allow for BestEffort pods to consume slack resources Answers to your questions: 1. If you create a per-project quota, you can quota requests separate from limits -see example 3 [1]. In this setup, a client is required to specify a request and limit, but they can improve their QOS by setting the limit closer to their request. I imagine many users would want a better QOS on memory, and would be ok with a lower QOS for CPU depending on the application. 2. If you create a per-project quota and limit range, you have a mechanism to control for the shape of a pod (min/max), as well as the default resource consumption, and the ability to mandate a particular overcommit ratio using limitRequestRatio. For example, if you want a project with the highest possible QOS, you could set limitRequestRatio to 1 for both cpu and memory. The client is able to tune both the request and limit on a per pod basis without issue. The limit range defaults are only applied if the pod omits a resource requirement. 3. Since I wrote both the Kubernetes/OpenShift documentation, I am not surprised they are similar. I am happy to improve those documents though based on use cases which I think are largely tied to the above questions. [1] https://docs.openshift.org/latest/admin_guide/quota.html On Wed, Aug 10, 2016 at 2:26 PM, Srinivas Naga Kotaru (skotaru) <[email protected]<mailto:[email protected]>> wrote: Need some clarity on quotas and limits As a platform team, we want control quotas on cpu and memory and put upper bounds and same time provide more flexibility to app team to control or decide what is limits for their apps. Our clients come to our own UI and ask for project. They don’t’ have right to create projects. We disabled it. Our robot account will create project, setup initial project admin, and appropriate roles ( edit, view, admins etc) One activity we want to control from UI is set quotas and put limits. Robot account will be used to create quota and limit range on every project. These numbers different project to project depending on client type or apps types. We want to optimize better density + best QOS so both infra and apps will be happier in terms of better utilization of resources. Documentation is good but not answering real time scenarios or examples unless you understood big picture. Questions: 1. What if we just define per project quota but don’t create limitrange? Can client control request and limits by himself at pod level subject to with in the upper controls of cpu/memory? 2. What if if we create both quota and limit range with defaults values for better density ( scheduler to place pods with decent default request) but later client to control both request and limits subject to quota limitations. Can they able to do or limitrange defaults always take precedence? default: cpu: “500m" memory: “1Gi" defaultRequest: cpu: “300m" memory: “512Mi” 3. Any decent documentation which explain real use cases rather high level which is available from project docs. ( I think it is cut and paste from official Kubernetes docs) -- Srinivas Kotaru _______________________________________________ dev mailing list [email protected]<mailto:[email protected]> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
