scheduler: Allow configuration of schedulable masters. #2024
Conversation
openshift-ci-robot
added
the
size/L
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: russellb The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
This is an alternative to #2004 |
|
Looks like I had a bad rebase of the vendor patch, will fix |
russellb
force-pushed
the
schedulable-masters-alt
branch
from
8f213ed
to
1414269
Compare
|
I think this is better than #2004, stating the intention clearly. I'll let @eparis @abhinavdahiya to comment on it though |
|
Looks like this needs a rebase. Also, I like this approach much better as well. |
The scheduler config includes a new MastersSchedulable option. It's false by default, but include it in the manifest to make it a little easier for someone to change if they want to after running "create manifests".
This change makes use of a new configuration item on the scheduler CR that specifies that control plane hosts should be able to run workloads. This option is off by default, but can be changed through a new install-config option under controlPlane. The justification for a new install-config option for this is that this is a required tunable for some clusters to have a successful install. A 3-node cluster on bare metal for example will need schedulable masters.
russellb
force-pushed
the
schedulable-masters-alt
branch
from
1414269
to
ba32a62
Compare
openshift-ci-robot
added
size/S
@russellb curious, why on BM the control plane needs to allow running pods ? is it for cost reasons? |
Great question. Yes - we believe that with bare metal machines, they will commonly have substantially more capacity than what is required for masters. We also believe it makes sense to support bare metal clusters that don't have separate worker nodes at all, at least for the initial install. None of those concerns are specific to bare metal, though. It's just we believe they will be more common on bare metal. |
|
I prefer to have one less knob (the alternative), since 3 node clusters are a thing we want to make first class. As we tune resource usage of the control plane I would expect the most common ootb deploy configuration to be a 3 node clusters with burstable workers. That also forces us to create resilient control planes and to invest in proper resource scheduling preemption. |
|
/retest |
|
@russellb: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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/test-infra repository. I understand the commands that are listed here. |
|
We're going to take #2004 instead of this one /close |
|
@stbenjam: Closed this PR. In response to this:
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/test-infra repository. |
This change makes use of a new configuration item on the scheduler CR
that specifies that control plane hosts should be able to run
workloads. This option is off by default, but can be changed through
a new install-config option under controlPlane.
The justification for a new install-config option for this is that
this is a required tunable for some clusters to have a successful
install. A 3-node cluster on bare metal for example will need
schedulable masters.