-
Notifications
You must be signed in to change notification settings - Fork 40k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We should label master nodes #28687
Comments
1 implies, there could be a 2, 3, 4... So is "roles.kubernetes.io/master: true" any better? |
I'd expect daemonsets to just not schedule on unschedulable nodes, is that not the case (it isn't now, I'm asking if that's by design)? |
Currently, there is still no good way to avoid DaemonSet running on master. Even though we've let DaemonSet to respect affinity #28803. However, there is no node label to distinguish master and node. Should we add master and node labels? Or should we just add some kind of mechanism to let DaemonSet respect Unschedulable if we need that. Ref #30491. |
imho is DaemonSet does not respect "Unschedulable", then that is a bug. /cc @kubernetes/sig-scheduling |
@mikedanese Could you please take care of this from daemonset? Or some other suggestion on how to handle this? This prevent node-problem-detector from running on e2e tests. Thanks! |
Unschedule existing is a bug :) (ref #29178). We need more fine grained control here. The motivating use case for daemonsets is system components (node-problem-detector, log shipper, kube-proxy, sdn agent). Cluster operators want system components to be running and ready before workloads run on a given node. At the time the daemonset was introduced, the only way to gate the scheduler from scheduling to a node is to mark it unscheulable . Thus daemonset could not have satisfied it's motivating use case if it had respected unschedulable. The fix here is to:
|
Thanks , @mikedanese Did you already send PR for this? I'd like to track it. |
Is there a PR for this? |
Mostly fixed in #31647, |
This is not going to make it into v1.4 but will be fixed early v1.5. |
@mikedanese - switching this to 1.6 as it's too late for 1.5. ok? (please switch it right back if you disagree, cc @saad-ali @calebamiles) |
That's fine. |
Automatic merge from submit-queue add a configuration for kubelet to register as a node with taints and deprecate --register-schedulable ref #28687 #29178 cc @dchen1107 @davidopp @roberthbailey
Automatic merge from submit-queue (batch tested with PRs 41115, 41212, 41346, 41340, 41172) Enable PodTolerateNodeTaints predicate in DaemonSet controller Ref #28687, this enables the PodTolerateNodeTaints predicate to the daemonset controller cc @Random-Liu @dchen1107 @davidopp @mikedanese @kubernetes/sig-apps-pr-reviews @kubernetes/sig-node-pr-reviews @Kargakis @lukaszo ```release-note Make DaemonSet controller respect node taints and pod tolerations. ```
We should have a label for the master nodes, so that e.g. daemonsets can select masters
I propose:
roles.kubernetes.io/master: 1
androles.kubernetes.io/node: 1
(The "obvious" alternative,
kubernetes.io/role: master
does not allow for multiple roles)The text was updated successfully, but these errors were encountered: