CPU is expressed in millicores. The node does the following to determine the cpu capacity:
NUM_CORES=$(cat /proc/cpuinfo | grep 'processor\t*' | wc -l) NODE_CAPACITY=$(($NUM_CORES * 1000)) If you want 50% of a single core, you can say the following: --requests=cpu=.5 --requests=cpu=500m If you want 100% of a single core, you can say the following: --requests=cpu=1 --requests=cpu=1000m If you want 2.5 cpu cores, you can say the following: --requests=cpu=2.5 --requests=cpu=1500m Thanks, Derek On Wed, Aug 10, 2016 at 5:00 PM, Srinivas Naga Kotaru (skotaru) < [email protected]> wrote: > While repressing Cpu in quota’s and limit range or per definition’s what > is the unit ? Is it number of cpu’s or cpu shares or some other unit? We > are confusing how to ask client and represent in quotas/limits ../?? > > > -- > *Srinivas Kotaru* > > From: Derek Carr <[email protected]> > Date: Wednesday, August 10, 2016 at 12:08 PM > To: skotaru <[email protected]> > Cc: dev <[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]> 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] >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >> >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
