To limit, or not to limit - this is the question that Java developers ask themselves when configuring CPU resources for their Kubernetes pods. Avoiding a strict pod CPU limit can be beneficial for latency-sensitive workloads, as it prevents pauses caused by CPU throttling. At the same time, running without a CPU limit removes an important signal the JVM uses to size its internal thread pools.

When there’s no CPU limit set, even modern Java versions will “see” all CPUs available on the Kubernetes node. In these cases, it’s often beneficial to explicitly override the ActiveProcessorCount to prevent JVM and your frameworks/libraries from using too many threads and increase performance predictability.

The JVM has spoiled us with its cleverness. It makes so many decisions behind the scenes, that lots of us gave up on looking at what’s inside. Memory-related discussions are probably more likely to appear at a conference or during a job interview than at “real” work. Of course, depending on what you work on.

Java apps are often run in containers these days. Built-in container awareness makes the JVM respect various container-specific limits (e.g. CPU, memory). This means, that even when running an app with a dummy java -jar app.jar (which is usually not the best idea), everything should just work. That’s probably why the only memory-related option provided is often the -Xmx flag (or any of its equivalents). In other words, we tend to only limit the maximum heap size, like this:

In this post, I’d like to describe the issue I’ve recently encountered when using Helm umbrella charts. Long story short, it turned out that subcharts are not completely isolated from each other, contrary to what we probably would expect. This feature has also some important consequences for building umbrella charts and combining different dependencies into one parent chart, which I want to outline as well.

Umbrella charts basics

Helm umbrella charts are an easy and powerful way of installing multiple components as a single one. They allow us to set up pretty complex configurations like Kafka cluster or Elastic stack with minimal effort - by installing just a single chart (one helm install call).