[Bug]: Strimzi operator v0.46.1 gets OOMKilled in Kind and Minikube.

[twoGiants]

Bug Description

After deploying the Kafka cluster kafka-ephemeral.yaml:

> kubectl apply -f https://raw.githubusercontent.com/strimzi/strimzi-kafka-operator/refs/tags/0.46.1/examples/kafka/kafka-ephemeral.yaml -n myproject

the Strimzi operator gets OOMKilled after a while and then every few minutes.

The number of nodes in the k8 cluster does not matter and if it is Kind or Minikube. It fails on both.

Here is a kubectl -n myproject describe pod strimzi-cluster-operator-... excerpt:

# ...
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 02 Oct 2025 11:23:33 +0200
      Finished:     Thu, 02 Oct 2025 11:23:48 +0200
    Ready:          False
    Restart Count:  6
    Limits:
      cpu:     1
      memory:  384Mi
    Requests:
      cpu:      200m
      memory:   384Mi
    Liveness:   http-get http://:http/healthy delay=10s timeout=1s period=30s #success=1 #failure=3
    Readiness:  http-get http://:http/ready delay=10s timeout=1s period=30s #success=1 #failure=3
# ...
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  26m                 default-scheduler  Successfully assigned myproject/strimzi-cluster-operator-d5f66d84c-nmxr8 to knative-worker2
  Normal   Pulled     4m1s (x7 over 26m)  kubelet            Container image "quay.io/strimzi/operator:0.46.1" already present on machine
  Normal   Created    4m1s (x7 over 26m)  kubelet            Created container: strimzi-cluster-operator
  Normal   Started    4m1s (x7 over 26m)  kubelet            Started container strimzi-cluster-operator
  Warning  BackOff    23s (x46 over 10m)  kubelet            Back-off restarting failed container strimzi-cluster-operator in pod strimzi-cluster-operator-d5f66d84c-nmxr8_myproject(24e343c2-8144-4102-8ea0-2479761fcf51)

Steps to reproduce

# 1.
kubectl create ns myproject

# 2.
kubectl apply -f https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.46.1/strimzi-cluster-operator-0.46.1.yaml -n myproject

# 3.
kubectl apply -f https://raw.githubusercontent.com/strimzi/strimzi-kafka-operator/refs/tags/0.46.1/examples/kafka/kafka-ephemeral.yaml -n myproject

Expected behavior

The Strimzi operator is expected to run without being OOMKilled.

Strimzi version

0.46.1

Kubernetes version

1.32.7

Installation method

YAML files

Infrastructure

Kind, Minikube

Configuration files and logs

Yaml files are linked above.

report-02-10-2025_11-46-57.zip

Additional context

• Fedora 42
• Docker

> docker version
Client: Docker Engine - Community
 Version:           28.4.0
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.4.0
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.7
  Git commit:       249d679
  Built:            Wed Sep  3 20:56:56 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

[see-quick]

I tried to run on kind with those steps you wrote, i.e.,

kubectl create ns myproject
kubectl apply -f https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.46.1/strimzi-cluster-operator-0.46.1.yaml -n myproject
kubectl apply -f https://raw.githubusercontent.com/strimzi/strimzi-kafka-operator/refs/tags/0.46.1/examples/kafka/kafka-ephemeral.yaml -n myproject

and everything seems to work:

NAME                                          READY   STATUS    RESTARTS   AGE
my-cluster-broker-0                           1/1     Running   0          2m29s
my-cluster-broker-1                           1/1     Running   0          2m29s
my-cluster-broker-2                           1/1     Running   0          2m29s
my-cluster-controller-3                       1/1     Running   0          2m28s
my-cluster-controller-4                       1/1     Running   0          2m28s
my-cluster-controller-5                       1/1     Running   0          2m28s
my-cluster-entity-operator-65849b56cf-vbvsz   2/2     Running   0          26s
strimzi-cluster-operator-6f498cb66-qnqbv      1/1     Running   0          4m10s

I wonder, how much memory have you allocated for minikube/kind?

[fvaleri]

I'm also having the same issue with both Minikube (driver: docker) and Kind (driver: podman) on Fedora 42. This may not be related to Strimzi, but a problem with how the container's memory is computed.

From system's logs you can see that with just one idle cluster to reconcile the operator's container is reported to take almost 15 GB of memory and, based on that, the kernel's OOM killer does its job. This doesn't match with the actual system's memory status, where I have around 8 GB of used memory.

$ journalctl -k -p err
Sep 28 16:57:37 p1gen7 kernel: Memory cgroup out of memory: Killed process 139878 (java) total-vm:15431388kB, anon-rss:387324kB, file-rss:24252kB, shmem-rss:0kB, UID:1001 pgtables:1300kB oom_score_adj:994

I haven't figured out how to fix this, but a workaround is to edit the operator's deployment and remove the memory limit.

[ppatierno]

I had the same issue on minikube by using docker as driver. I moved to use kvm and it works like a charm.

[twoGiants]

I wonder, how much memory have you allocated for minikube/kind?

@see-quick I should've said in the Bug description (will update) => all of it 😆 , I use Docker and have no memory limits configured. I am on Fedora 42, same as @fvaleri.

@fvaleri I have just doubled the limit and that fixed the issue, had no OOMKilled anymore. We now patch the operator.yaml to get around it.

[fvaleri]

@fvaleri I have just doubled the limit and that fixed the issue, had no OOMKilled anymore. We now patch the operator.yaml to get around it.

I'm afraid that's not the solution. It may work now, but you will hit the same with the operator managing more resources, or some other heavy custom resource with limits (e.g. KafkaConnect).

[twoGiants]

It may work now, but you will hit the same with the operator managing more resources, or some other heavy custom resource with limits (e.g. KafkaConnect).

@fvaleri you're absolutely right. Its just good enough for now, for testing stuff locally. But I might have to resort to removing the memory limit like you did.

[scholzj]

Comverting to discussion as this does not seem to be Strimzi but rather environment issue.

[scholzj]

• for what is worth, in my case - Minikube on Docker on MacOS - it seems to work fine.

[fvaleri]

The cause of this issue seems to be a JVM bug with cgroup v2:

https://bugs.openjdk.org/browse/JDK-8346874

For example, the following command should set 1GB as max heap (half of container memory):

# Java 17: max heap is half system memory
$ podman run -it -m 2g fedora:41 bash -c "dnf install -y java-17-openjdk-headless.x86_64 && java -XX:MaxRAMPercentage=50 -XshowSettings --version"
VM settings:
    Max. Heap Size (Estimated): 31.12G
...
Operating System Metrics:
    Provider: cgroupv2
    Memory Limit: 2.00G
...

# Java 25: max heap is half container memory
$ podman run -it -m 2g fedora:42 bash -c "dnf install -y java-25-openjdk-headless.x86_64 && java -XX:MaxRAMPercentage=50 -XshowSettings --version"
VM settings:
    Max. Heap Size (Estimated): 1.00G
...
Operating System Metrics:
    Provider: cgroupv2
    Memory Limit: 2.00G

It looks like they didn't backport this fix to older Java LTS releases.

[fvaleri]

Hi @jerboaa, thanks for checking.

We'd know if the user tested JDK 21

Tested. No issue with JDK 21. The problem is that we still need to support images with JDK 17.

So far this only affects specific kernel/OS combinations

$ uname -r
6.16.8-200.fc42.x86_64

[franz1981]

Sorry @jerboaa i have you little context 🙏 but yes, you got it

[jerboaa]

It's JDK-8347129, then. I'll backport it to 17u. F41+ is affected, but only few others.

[jerboaa]

@fvaleri Why do you care about F41+ deployment hosts? Shouldn't you deploy to RHEL/OCP?

[fvaleri]

I care because that's my dev environment. I'm not the only one in my team with this issue, and we are all on F42.