I agree, but this is a medium-term goal. For 1.3 we are going to leave limits as they were so far (i.e. pods/cluster, nodes/cluster, pods/node).

@wojtek-t we could probably create a patch that would default off but we-(Red Hat) could leverage. It would be no-op change for upstream, but our customers have much larger and denser nodes that they would like to leverage. Given this would be a 0-feature change for upstream, what is your opinion?

/cc @smarterclayton

Yeah - adding a "by-default" non-active limit sgtm.

#23349

Code is in, we'll just need to update defaults for 1.4

@timothysc @rrati @wojtek-t any more work needed for v1.4?

we've enabled flag over-rides in 1.3, but have not updated defaults for 1.4, so I'm moving out to 1.5.

I'd like to prioritize this as a 1.5 action item for @kubernetes/sig-node

I was pointed that this is correct thread for my question so here I am.
Can we change existing density tests, so we don't have hard coded number of pods (should allow starting 95 pods per node) but instead have number of pods calculated basing on the number of cores (should allow starting 1 pod per core). Or should there be another set of tests for that ?

@pskrzyns no, b/c upstream has not defaulted to this change, but we have defaulted to this on our side.

/cc @yujuhong

@timothysc is the changed version of those tests publicly available ?

We can probably share that data, we do a baseline overhead test @ 250 pods/node on our env.

But this will vary based upon the storage layer used by docker, and the docker version itself.

/cc @mffiedler

This needs to be triaged as a release-blocker or not for 1.5 @Random-Liu (or move to 1.6?) @timothysc

Not sure what we can do for 1.5 at this moment. Moving it to 1.6

Knobs are all there sig-node can update defaults as needed.