Bug 1633387 - KubeletTooManyPods statically compares against 100 instead of --max-pods (-10)
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: 2023-09-14 04:39 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:

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.


Comment 18 Red Hat Bugzilla 2023-09-14 04:39:02 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days

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