[OOMKilled] controller-manager pod

[sinios-devops]

Description

The controller-manager pod in the openshift-sandboxed-containers-operator namespace is repeatedly being terminated with OOMKilled.
This happens without any manual restarts from our side and affects functionality of the operator.

Expected Behavior

The controller-manager pod should run continuously without exceeding its memory limit.

Environment

Operator version: sandboxed-containers-operator.v1.10.1
OpenShift version: 4.16.11

Pod & Events

Containers:
  manager:
    Container ID:  cri-o://9cf48de24c009c7bd58ea77647b14130af0fee71e4db37753ef63e0dd6e74b64
    Image:         registry.redhat.io/openshift-sandboxed-containers/osc-rhel9-operator@sha256:4fb018ce03cfaa06b983e801508036352247d3f9fc09981949f85b7e8ab4520b
    Image ID:      registry.redhat.io/openshift-sandboxed-containers/osc-rhel9-operator@sha256:4fb018ce03cfaa06b983e801508036352247d3f9fc09981949f85b7e8ab4520b
    Port:          9443/TCP
    Host Port:     0/TCP
    Command:
      /manager
    Args:
      --metrics-bind-address=127.0.0.1:8080
      --leader-elect
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Wed, 27 Aug 2025 09:33:28 +0200
      Finished:     Wed, 27 Aug 2025 09:33:51 +0200
    Ready:          False
    Restart Count:  241
    Limits:
      cpu:     200m
      memory:  256Mi
    Requests:
      cpu:     100m
      memory:  40Mi

Steps to Reproduce

1. Deploy openshift-sandboxed-containers-operator with default configuration.
2. Wait for the controller-manager pod to run.
3. Observe memory usage over time until it is killed with OOMKilled.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

Details

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[gkurz]

/remove-lifecycle rotten

[gkurz]

Hi @sinios-devops !

Sorry for the insane delay. Bugs and enhancements for this project are usually tracked at https://issues.redhat.com/projects/KATA but let's continue here 😄

Steps to Reproduce

1. Deploy openshift-sandboxed-containers-operator with default configuration.
2. Wait for the controller-manager pod to run.
3. Observe memory usage over time until it is killed with OOMKilled.

Of course I don't reproduce this in my setup. I'd like to know some more details on the scenario :

• Are you still experiencing this ?
• How reproducible is this ?
• Was a KataConfig CR created ?
• Did you try to raise the limit in the CSV ?

Thanks !