-
Notifications
You must be signed in to change notification settings - Fork 716
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
Pods can be scheduled in new masters between kubeadm init and master taint #1060
Comments
hello and thanks for the report,
before sending a PR, can you point to the source code changes that you would like to make to get this working - e.g. source code links + a short explanation? |
@neolit123 sorry for the delay, I took a time to get a look on the kubeadm code If I remove |
this is an interesting situation. this is linked to this comment for master nodes: for worker nodes we already do always set for master nodes we never do it, but later mark the master as one of the final phases: note that this also sets labels: if we always do in my opinion having the taints in the kubelet phases makes sense and also solves the issue for you but we have to talk with others about this. /assign @luxas |
Thanks @neolit123, no problem about not backport this. And yes, |
in 1.12 you can provide an initial taint on join and control-plane-join |
@timothysc How do you provide an initial taint on control-plane-join? I'm seeing this exact issue when joining new masters in a 1.15 cluster. I can't see any relevant parameters in the documentation for adding taints, and it's not possible to join using a config file:
Anyway, even if it did work, this seems like a workaround and not a fix. Is it not possible to taint the master at an earlier stage automatically? Seems like @neolit123 is having some ideas. |
BUG REPORT
Versions
kubeadm version (use
kubeadm version
):Environment:
kubectl version
):AWS
uname -a
):What happened?
If you have multiple masters, and a daemonset, when you register a new master the daemonset will scheduler a pod in this master before the master get tainted
What you expected to happen?
Pod without toleration to master taint, not get scheduled on master.
How to reproduce it (as minimally and precisely as possible)?
Anything else we need to know?
Put the taint in the kubelet config of master can solve that, also I can work on this issue.
The text was updated successfully, but these errors were encountered: