Managing Container Resources

When you create a container, it's associated with specific cgroups (Control Groups) that manage its resources. cgroups allow you to set limits on resources such as memory, CPU, and block I/O for the container, and restrict its access to these resources.

Control Groups are a Linux kernel feature that can account for and control the resource usage of a process (or group of processes). What happens when a container hits a limit depends on the resource:

• CPU limits typically result in throttling (the container gets less CPU time).
• Block I/O limits typically result in throttling (reduced read/write throughput).
• Memory limits can trigger the kernel's OOM behavior for that cgroup, which may kill one or more processes inside the container.

By default, when you start a container, it has no limitations. It can utilize as much CPU and memory as permitted by the host's kernel scheduler. You can fine-tune the resources available to a container by configuring limits.

Similarly, you can configure soft limits and relative priorities. These settings influence how resources are shared when the host is under contention, but they are not strict guarantees of dedicated CPU or memory. (Hard limits, such as memory limits, are enforced more strictly and can cause OOM kills inside the container if exceeded.)

In development environments, it's common to run containers without any resource limits or reservations unless the host machine has limited resources. In production environments, if you are running a standalone container (not managed by an orchestrator like Kubernetes), it's advisable to set limits and reservations for each container. However, in most cases, containers are managed by an orchestrator in production environments and, in this case, the resource limits and reservations are typically handled by the orchestrator, not by Docker directly.