While memory limits defined a set maximum, CPU limits are based on shares. These shares are a weight between how much processing time one process should get compared to another. If a CPU is idle, then the process will use all the available resources. If a second process requires the CPU then the available CPU time will be shared based on the weighting.

Example

Below is an example of starting a container with different shares. The --cpu-shares parameter defines a share between 0-768.

If a container defines a share of 768, while another defines a share of 256, the first container will have 75% share with the other having 25% of the available share total. These numbers are due to the weighting approach for CPU sharing instead of a fixed capacity.

Below the first container will be allowed to have 75% of the share. The second container will be limited to 25%.

docker run -d --name c768 --cpuset-cpus 0 --cpu-shares 768 benhall/stress
docker run -d --name c256 --cpuset-cpus 0 --cpu-shares 256 benhall/stress
sleep 5
docker stats --no-stream
docker rm -f c768 c256

It's important to note that a process can have 100% of the share, no matter defined weight, if no other processes is running.

While cgroups control how much resources a process can use, Namespaces control what a process and see and access.

Example

When containers are launched, a network interface is defined and create. This gives the container a unique IP address and interface.

docker run -it alpine ip addr show

By changing the namespace to host, instead of the container's network being isolated with its interface, the process will have access to the host machines network interface.

docker run -it --net=host alpine ip addr show

If the process listens on ports, they'll be listened on the host interface and mapped to the container.

As with networks, the processes a container can see depends on which namespace it belongs too. By changing the Pid namespace allows a container to interact with processes beyond its normal scope.

Example

The first container will run in its process namespace. As such the only processes it can access are the ones launched in the container.

docker run -it alpine ps aux

By changing the namespace to the host, the container can also see all the other processes running on the system.

docker run -it --pid=host alpine ps aux

Providing containers access to the host namespace is sometimes required, such as for debugging tooling, but is regarded as bad practice. This is because you're breaking out of the container security model which may introduce vulnerabilities. Instead, if it's required, use a shared namespace to provide access to only the namespaces the container requires.

Example

The first container starts a Nginx server. This will define a new network and process namespace. The Nginx server will bind itself to port 80 of the newly defined network interface.

docker run -d --name http nginx:alpine

Other containers can now reuse this namespace using the syntax container:<name>. Below the curl command can access the HTTP server running on localhost because they share the same network interface.

docker run --net=container:http benhall/curl curl -s localhost

It can also see and interface with the processes in the shared container.

docker run --pid=container:http alpine ps aux

This is useful for debugging tools, such as strace. This allows you to give more permissions to specific containers without changing or restarting the application.