Bug 1633387 - KubeletTooManyPods statically compares against 100 instead of --max-pods (-10) [NEEDINFO]
Summary: KubeletTooManyPods statically compares against 100 instead of --max-pods (-10)
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Monitoring
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.1.0
Assignee: Frederic Branczyk
QA Contact: Junqi Zhao
Depends On:
Blocks: 1690951
TreeView+ depends on / blocked
Reported: 2018-09-26 21:04 UTC by Justin Pierce
Modified: 2019-11-15 08:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1690951 (view as bug list)
Last Closed: 2019-06-04 10:40:35 UTC
Target Upstream Version:
vjaypurk: needinfo? (fbranczy)

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 0 None None None 2019-06-04 10:40:45 UTC

Description Justin Pierce 2018-09-26 21:04:30 UTC
Description of problem:
In our starter clusters, --max-pods is set to 250. This leads to a persistent 
KubeletTooManyPods warning being raised. 

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

How reproducible:

Steps to Reproduce:
1. Set kubelet max-pods to something > 110 (the default). 
2. Fill node with > 100 pods
3. KubeletTooManyPods will be reported

Actual results:
KubeletTooManyPods reported.

Expected results:
KubeletTooManyPods should be relative to configured --max-pods.

Comment 1 Frederic Branczyk 2018-09-28 10:04:40 UTC
This is indeed a bug, and already in our backlog to improve. In the mean time the best thing I can suggest is to silence this alert, sorry for the inconvenience.

Comment 3 Frederic Branczyk 2019-02-22 16:42:40 UTC
This is bumped to 250 pods in 4.0, the patch that modified this: https://github.com/openshift/cluster-monitoring-operator/pull/238

Comment 5 Junqi Zhao 2019-02-26 08:19:58 UTC
The cloned issue https://jira.coreos.com/browse/MON-344 is fixed, set it to VERIFIED

Comment 7 Matthew Robson 2019-03-19 19:32:39 UTC
Frederic - is the simple change of bumping the default value to 250 something that can be backported for a 3.11.x errata or is silencing the only option?

Comment 8 Frederic Branczyk 2019-03-20 14:03:28 UTC
It's relatively straight forward, but does need to be scheduled into our sprints. This is a PM decision to make if/when.

Comment 9 Christian Heidenreich 2019-03-20 14:16:05 UTC
Since we have fixed this for OCP4 already and it came up a few times, it's ok w/ me to backport this for the next OCP 3.11 z-release if possible.

Comment 10 Frederic Branczyk 2019-03-20 14:22:00 UTC
In that case please create an item in our backlog and make it your responsibility to have it be part of an upcoming sprint.

Comment 12 errata-xmlrpc 2019-06-04 10:40:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.