Comments on: Best Practices for Java Apps on Kubernetes

By: Halil-Cem Gürsoy

Halil-Cem Gürsoy — Tue, 11 Jul 2023 07:41:22 +0000

@dnastacio – sorry for the late reply, I don’t get a notification.

You have no guarantees.
Regarding the CPU finally the Kernel CFS decides how many CPU your process gets and this depends how all other processes are started on the node.
And regarding the memory, especially on cgroup v1 systems, there is no guarantee for the requested memory! This changes on cgroup v2 if this feature is configured in the kubelet – memory QoS is still alpha!

By: piotr.minkowski

piotr.minkowski — Mon, 19 Jun 2023 11:19:46 +0000

In reply to KAMESH. Thanks!

By: KAMESH

KAMESH — Tue, 13 Jun 2023 20:14:31 +0000

nice article, well thought out on various facets of the java app on a k8s env.

By: dnastacio

dnastacio — Thu, 16 Feb 2023 02:28:20 +0000

@Halil-Cem Gürsoy, a container, while running, will always have the requested resources. That is the guarantee.

If a parent pod has to be evicted, the pod containers are terminated and only then the resources are released for other purposes.

By: piotr.minkowski

piotr.minkowski — Wed, 15 Feb 2023 13:38:35 +0000

In reply to Matt Henry.

Yes, I know that. That’s why in summary I write there are some controversial bits of advice in the article. But now, if you carefully read what I wrote, and also read the 11th rule of 12-factor I think you may have a similar opinion as me. Since RabbitMQ is not the destination of my logs. Routing is not realized by my app – but by the amqp exchange. You can then send the logs queued by the rabbit to anywhere else – e.g. Logstash.

By: Halil-Cem Gürsoy

Halil-Cem Gürsoy — Wed, 15 Feb 2023 08:50:03 +0000

Please excuse my misleading statement.
My point is that there is no guarantee that the resources that were requested will be available later. One example is node eviction if the node goes low on resources.

Anyway, just forgot to say a good article.

By: wind57

wind57 — Tue, 14 Feb 2023 20:36:00 +0000

the problem with setting the CPU limit, is not the limit itself, imho. It is the fact that requests and limits on a CPU translate to very different things, which are rarele understood or even though about properly. When I had a lot more time, I even investigated that a lot: https://stackoverflow.com/questions/55047093/whats-the-difference-between-pod-resources-limits-and-resources-requests-in-kub/70591202#70591202 Otherwise there are multiple people aswell that I know that recommend not setting those limits at all, agreed.

By: Matt Henry

Matt Henry — Tue, 14 Feb 2023 14:08:30 +0000

Don’t configure your app to log to AMPQ. 12-Factor principles say that the application should log to the console (stdout) and it should be the infrastructures responsibility to ship the logs, using someone like Fluentd or Filebeat.

By: piotr.minkowski

piotr.minkowski — Tue, 14 Feb 2023 09:59:10 +0000

In reply to Halil-Cem Gürsoy. Ok, but exactly is not correct? I guess that you mean, the pod may not get the resources it requests and therefore it won't be scheduled on the node?

By: Halil-Cem Gürsoy

Halil-Cem Gürsoy — Tue, 14 Feb 2023 07:56:38 +0000

Dear Piotr,
you write “Anyway, from the Kubernetes perspective, the pod receives the resources it requests. The limit has nothing to do with it.”.
Unfortunately, this is not correct.
The requests (spec.containers[].resources.requests.memory and spec.containers[].resources.requests.cpu) are used by the scheduler to identify the node on which to start a container.
And later on, the memory request value is used to set the oom-score-adj parameter for the kernel. Based on this, the kernel memory manager decides which processes have to be killed in case of memory shortage or node eviction.