mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-12 23:54:01 +09:00
Aleksei Sviridkin
b255dc4dd8
The JDK 17 in the Strimzi 0.45.1-rc1 operator image decides whether to read the container limits by looking at /proc/cgroups. Kernels 6.12 and newer built without CONFIG_MEMCG_V1 no longer list the memory controller there, so the JVM turns container support off and takes host RAM and host CPUs as its budget: on a 128 GiB node it picks G1 with a 25 GiB max heap and a 2 GiB initial heap inside a 512Mi limit, and the kernel OOM-kills the operator under load. A restart at the wrong moment leaves a freshly created StrimziPodSet without pods for up to the five-minute informer resync, which is how a KRaft controller pool ends up never starting within an e2e timeout. The limits now reach the JVM through the downward API as -XX:MaxRAM and -XX:ActiveProcessorCount, so they follow any later change to the container resources. In a test cluster the operator then picks Serial GC and a heap of about 100 MiB. The upstream JDK fix is JDK-8347811, backported to 17.0.20 and 21.0.10. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>