Between predictable and practical - on kubernetes limits
Find out how resource consumption behavior of workloads in Kubernetes can help you make informed decisions about limit and request settings
You might think that limits are a Kubernetes admin’s best friend. By restricting the CPU and memory that Pods can consume, you can avoid “noisy neighbor” issues, streamline resource allocation and keep your clusters humming smoothly, right?
Well, not necessarily. Limits have their limitations. Although it’s good and well to set limits for those workloads that are predictable enough to benefit from resource consumption restrictions, limits can do more harm than good in cases where workloads are very “spiky.”
That’s why, on the whole, we think use of limits should be limited. As working with CPU limits requires a deep understanding of the implications, there are approaches that suggest avoiding the use of CPU limits. While it’s critical to get to know your workloads well before making strategic decisions on whether to set limits, and which kinds of limits to apply if so, we would like to shed some light on use-cases where CPU limits can really come in handy.
Let’s dive in…
How Kubernetes limits work
Limits in Kubernetes work in a pretty straightforward way: They restrict how many CPU and/or memory resources Pods or containers can access. For example, if you want to set a CPU limit of 500m for a container inside your Pod, you’d describe it with YAML such as the following:
Explore related posts
Going for the gold: How K8s warriors can monitor the four golden signals
Find out how the four golden signals work, and how to apply them in the context of modern application monitoring
What is eBPF, anyway, and why should Kubernetes admins care?
Discover the ins and outs of eBPF and why it is particularly exciting when it comes to observing your containers and Kubernetes clusters