Kubernetes : Assign CPU Resource Defaults and Limits to Containers

By Alwyn Botha, Alibaba Cloud Tech Share Author. Tech Share is Alibaba Cloud’s incentive program to encourage the sharing of technical knowledge and best practices within the cloud community.

This tutorial demonstrates the following :

  • How to declare the CPU resource requirements of your Pods
  • How Kubernetes administrators define default CPU resource requirements
  • How Kubernetes administrators define CPU resource usage limits

CPU resource usage limits are needed to prevent any one Pod from totally consuming ALL the CPU time on one node ( server running Kubernetes and capable of hosting Pods ). You can use this functionality in development to prevent developers from accidentally hogging all CPU resources.

You can use this functionality in production — to ensure no accidental runaway process in one Pod from hogging all CPU resources — preventing everything else from doing productive work.

This tutorial will cover the following topics:

  • Pod declares CPU request and limits
  • Pod defines using half a CPU — Millicores syntax
  • Pod defines using half a CPU — fractional syntax
  • Pod declares no CPU request and limits
  • CPU LimitRanges
  • LimitRange with defaults and min, max values
  • Pod that does not adhere to CPU limits
  • LimitRanges and Namespaces

1) Pod Declares CPU Request and Limits

Pods can declare how much CPU they need.

See example below:

  • Pod declares it needs 1 full CPU at maximum
  • Pod declares it needs half a CPU at minimum

CPU resource limits are defines using two syntaxes:

  • 1, 2, 2.5 … defines 1, 2 and 2.5 CPUs
  • 1000m, 2500m, 150m … defines 1 CPU, 2.5 CPUs and 0.150 CPUs

The second syntax uses Millicores. 1000m equals one CPU on all computers.

( One Millicores is 1/1000 of a CPU, therefore 1000m equals 1 CPU )

A four core server has a CPU capacity of 4000m.

Millicores syntax is easy to read: 150m versus 0.150. Use the syntax you prefer. Have a standard at your company of which to use.

The Pod below defines it needs 500m minimum and 1 CPU maximum.

Create the Pod.

We now need to test how those CPU limits are enforced.

We do that using sysbench — a Linux benchmark utility.


sysbench — threads=1 — cpu-max-prime=8005005 — verbosity=0 cpu run

  • — threads=1 … run using 1 thread
  • — cpu-max-prime=8005005 … calculation of prime numbers up to this value
  • — verbosity=0 … do not show details while doing the run
  • cpu run … run the CPU run benchmark included in sysbench

( I randomly played with cpu-max-prime value till I got one that takes around 15 seconds to run. That is enough time to switch to the other console and do a screen capture of the top command output. )

We defined that our Pod needs 1 full CPU to do its work. We can test that using sysbench inside our Pod.

Use kubectl exec to ssh into the Pod. There we can run sysbench on the shown Linux Pod shell prompt.

Throughout this tutorial enter the sysbench command as shown in these output blocks.

As expected, our Pod uses 1 full CPU at 100%. You can see that in the 4 individual core detail lines as well in the process detail line of our thread.

In the test below we let sysbench run 2 threads.

How to filter top command output:

  • press letter o … this starts its filter functionality
  • in our specific case: enter COMMAND=sysbench and press enter
  • only sysbench processes shown
  • press l to hide the load average line
  • press m to hide the memory and swap line.

As expected, our Pod uses 1 full CPU overall at 100%.

You can see that in the 4 individual core detail lines that each thread runs on its own CPU — each using 50% CPU — to keep total usage at 100%

You will see that more clearly in tests below using 3 and 4 threads.

Test using 3 threads:

As expected, our Pod still uses 1 full CPU overall at 100%.

You can see that in the 4 individual core detail lines that each of the 3 threads run on its own CPU — each using 33% CPU — to keep total usage at 100%

As expected, our Pod still uses 1 full CPU overall at 100%.

You can see that in the 4 individual core detail lines that each of the 4 threads run on its own CPU — each using 25% CPU — to keep total usage at 100%

Basic demo completed, delete Pod.

I use — force — grace-period=0 to delete Pod immediately. Do not use in production. By default Pods get 30 seconds to do their shutdown routines ( after receiving delete command ).

2) Pod Defines Using Half a CPU — Millicores Syntax

Note CPU limit is 500m = half a CPU.

Create the Pod.

Exec into Pod:

Run benchmark.

Pod got limited to half a CPU — works as expected.

Demo completed, delete Pod.

3) Pod Defines Using Half a CPU — Fractional Syntax

Same Pod as before, only using 0.5 to define half a CPU.

Create the Pod.

Enter Pod:

Run sysbench:

Identical to previous test ( proving 500m = half a CPU )

Investigate how Kubernetes understands our Pod YAML spec.

( Output truncated — leaving only the good stuff. Rest of tutorial always only show relevant describe output )

Shows Millicores values, not 0.5

4) Pod Declares No CPU Request and Limits

Pod below has no reference to limits.

Create the Pod.

Enter Pod and run sysbench test.

Reckless Pod hogs all 4 cores at 100%. This is why you need CPU limits.

Delete this Pod:

5) CPU LimitRanges

We need CPU default limits that automatically limits ALL Pods on a node.

LimitRanges fits the bill.

LimitRange below adds default limits ALL Pods that do not declare their own limits.

Create the LimitRange.

We reuse the Pod spec from previous example : no limits in its spec.

Create the Pod.

Describe how Kubernetes executed our desired Pod spec.

Note the annotation :

LimitRanger automatically added a cpu limit for container mybench-container

The limits listed agree with the LimitRange spec.

Best Practice Have LimitRanges at your development shop.

Delete this specific LimitRange.

6) LimitRange with Defaults and Min, Max Values

Previously we used LimitRanges defaults.

LimitRanges also define min and max limits. See spec below:

3 examples of new Pod creations follow so you can see how this works. ( My tutorials teach via examples rather than long text descriptions with few demos. )

Create our LimitRange

Define our Pod.

Create the Pod.

This Pod does not need defaults — it declares its own.

This Pod spec limit fall within the allowed min-max LimitRange defined above . Pod create command went smoothly — nothing else to show here.

Describe Pod shows Pod created exactly as we specified.

7) Pod That Does Not Adhere to CPU Limits

Edit Pod spec.

Note our CPU request is below LimitRange min

Note our CPU limit is above LimitRange max

Attempt to create the Pod:

Error is as expected.

Modify Pod spec to be within limits.

Create the Pod.

Pod create worked. It falls within min and max limits.

Delete Pod and LimitRange .

and …

8) LimitRanges and Namespaces

LimitRanges live in Namespaces

If you are familiar with Namespaces all you need to know is that LimitRanges you create work in the Namespace you are currently in.

You should divide your development server into several Namespaces — per development team. Different teams may need different CPU and RAM limits. That is the purpose of Namespaces : separation of resources visibility based on your needs.

If you do not define any Namespaces and no LimitRanges your server is WIDE open to CPU and RAM abuse — deliberate and accidental.

For more information https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/


CPU defaults and limits are easy to understand, so let’s put this knowledge to test. Create your own LimitRange and modify your own Pod with:

  • Limit and request
  • Limit and without request
  • No limit and with request

Enter Pod via kubectl exec and run sysbench. Exceed self-declared limits and LimitRange max to learn how all this interacts.

Here are several other exercises for you to try:

  • Using just one Pod, request much more CPU cores than those available on your node.
  • Create 3 Pods that in total request CPU resources that exceed the number of CPU cores on the node
  • Create 3 Pods that in total limit CPU resources that exceed the number of CPU cores on the node
  • Since Pod may have several containers, create a Pod with 3 containers (each with different limits) and investigate how those limits are enforced. For example, if 3 containers in a Pod request 1 CPU each, the total Pod demand is 3 CPUs. You must attempt to run 3 Pods simultaneously if you want to test Pods that collectively exceed node cpu capability.

Hopefully by trying out these exercises, you can accurately predict any behavior for any Pod when given any LimitRange spec / definition.


Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store