K8s Anti-Design Pattern Series – Deploying without memory and CPU limits

Introduction:

When using Kubernetes, applications have no constraints on the resources they can use. This gives your app the ability to possibly take over the entire cluster. Given that even a small memory leak or CPU hiccup can cause chaos for the rest of the applications, this is an issue in a staging cluster and a catastrophe in a production cluster.

Resource Limits:

Because of this, it is important to set resource limits for each of your apps (regardless of the cluster they’re destined for).  Even if you, as a developer, don’t need to know exactly how the limits are established, you still need to make sure that whoever is managing your cluster understands what those expectations are.Unfortunately, it’s not enough to just check how much time and resources a program typically uses. If you want to know how your application handles peak traffic and load, you need to look at it under extreme circumstances. This is the precise scenario in which you want to avoid the unexpected reset of your application.

Kubernetes’ resource flexibility is a major plus. Any benefits of using a cluster will be nullified if the cluster kills or restarts your application just as it is beginning to handle substantial load (because, for example, your online store is experiencing a surge in visitors). To the contrary, if you put your limits too high, your cluster will be less effective and will waste resources.

Automation:

Your programming languages’ usage habits and the way the underlying platform makes use of its resources should also be investigated. Common examples of legacy software with memory limit issues include Java apps written before JVM 1.5.  Keep in mind that you can automate the entire resource game with a vertical cluster auto-scaler once you have mastered Kubernetes and your application’s resource needs.