Strimzi sizes a broker heap by asking the image's JDK 17 what heap it
would pick at MaxRAMPercentage=50, capped at 5 GiB.
On kernels built without CONFIG_MEMCG_V1 that JDK cannot see the limit
and reports host RAM, so every broker and controller starts with up to
a 5 GiB heap inside a 1Gi limit and is OOM-killed. The topic and user
operators run the same JDK with percentage-based defaults, and the
drain-time Cruise Control takes 75% of host RAM for its heap.

Each of these containers now gets JAVA_TOOL_OPTIONS with -XX:MaxRAM set
to its memory limit, plus -XX:ActiveProcessorCount where the chart sets
a CPU limit. The entity operators and Cruise Control have none in the
chart, so a LimitRange default still leaves them counting host CPUs:
Strimzi template env takes no resourceFieldRef. Every java in the
container reads JAVA_TOOL_OPTIONS, Strimzi's heap probe included, so
Strimzi's own heap rules and Kafka's G1 defaults apply to the real
memory limit. jvmOptions would not do: Strimzi turns -XX options into
KAFKA_JVM_PERFORMANCE_OPTS, and kafka-run-class.sh skips its G1 settings
when that is set. Each JVM prints a "Picked up JAVA_TOOL_OPTIONS" line
on start. Existing clusters roll once on upgrade, because the pod
environment changes.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>
(cherry picked from commit 479d17a)

The pre-install/pre-upgrade hook applies the node pools and the drain
KafkaRebalance with kubectl, and its container has no resources of its
own, so in a tenant with resource quotas it runs under the LimitRange
default of 128Mi. When it applies an object that already exists,
kubectl downloads the cluster's whole OpenAPI v2 document only to
decide that a custom resource takes a JSON merge patch: with the 374
CRDs of an e2e cluster that peaks at about 300Mi, so every upgrade of a
Kafka in such a tenant OOM-kills the hook and fails with "pre-upgrade
hooks failed".

--openapi-patch=false skips that lookup and builds the same three-way
merge patch from the last-applied annotation, peaking at about 35Mi on
the same cluster. A server-side apply would be as small but changes
what gets removed: the "kafka" pool is created with "kubectl create",
whose manager keeps co-owning every field it set, so a later
server-side apply leaves those fields in place when the chart drops
them. A larger memory limit would charge every upgrade against the
tenant quota instead.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>
(cherry picked from commit 6ba440f)