Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-3443

[4.12] Descheduler pod is OOM killed when using descheduler-operator profiles on big clusters

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • 4.10
    • kube-scheduler
    • None
    • Moderate
    • None
    • False
    • Hide

      None

      Show
      None
    • Hide
      The {product-title} {product-version} release changes the behavior of the descheduler during initialization, so that the descheduler no longer consumes memory to the point where it could lead to out-of-memory (OOM) issues.

      In previous releases of {product-title}, if you deployed the Kube Descheduler Operator on an {product-title} cluster, and you changed the default resource limit values for a deployed pod, the pod's values would revert to the default values. This caused the descheduler to incorrectly record events when it evicted the pod from a node.

      (link:https://issues.redhat.com/browse/OCPBUGS-3443)[*OCPBUGS-3443*]
      Show
      The {product-title} {product-version} release changes the behavior of the descheduler during initialization, so that the descheduler no longer consumes memory to the point where it could lead to out-of-memory (OOM) issues. In previous releases of {product-title}, if you deployed the Kube Descheduler Operator on an {product-title} cluster, and you changed the default resource limit values for a deployed pod, the pod's values would revert to the default values. This caused the descheduler to incorrectly record events when it evicted the pod from a node. (link: https://issues.redhat.com/browse/OCPBUGS-3443) [* OCPBUGS-3443 *]
    • Bug Fix
    • Done

      Description of problem:

      When deploying the Kube Descheduler Operator on a OCP Cluster
is not possible to modify the resources(request/limits) of the deployed pods.

This is problematic in big environments as it eventually hits an OOM scenario where the pod is restarting.

      Version-Release number of selected component (if applicable):

      4.10

      How reproducible:

      Always

      Steps to Reproduce:

      1. Deploy operator
2. Try to modify the resource values of the pod/deployment
3. Operator defaults the values back.

      Actual results:

      Not possible to change resources in the pod

      Expected results:

      Pod running with different resource values.

      Additional info:

       

              jchaloup@redhat.com Jan Chaloupka
              rhn-support-mblach Miguel Blach
              Rama Kasturi Narra Rama Kasturi Narra
              Darragh Fitzmaurice Darragh Fitzmaurice
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: