-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
Remove node.alpha.kubernetes.io/ismaster taint from kube-up.sh #43537
Remove node.alpha.kubernetes.io/ismaster taint from kube-up.sh #43537
Conversation
214069a
to
26e8f00
Compare
This fixes a breaking change, so mark as release blocking. |
cluster/gce/configure-vm.sh
Outdated
@@ -447,6 +447,7 @@ initial_etcd_cluster_state: '$(echo "${INITIAL_ETCD_CLUSTER_STATE:-}" | sed -e " | |||
ca_cert_bundle_path: '$(echo "${CA_CERT_BUNDLE_PATH:-}" | sed -e "s/'/''/g")' | |||
hostname: $(hostname -s) | |||
enable_default_storage_class: '$(echo "$ENABLE_DEFAULT_STORAGE_CLASS" | sed -e "s/'/''/g")' | |||
enable_master_noschedule_taint: '$(echo "$ENABLE_MASTER_NOSCHEDULE_TAINT" | sed -e "s/'/''/g")' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not necessary, nodes don't need to know about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, will remove this.
I'd say just remove the flag, don't add a configuration option. |
@@ -516,7 +516,9 @@ function start-kubelet { | |||
if [[ "${REGISTER_MASTER_KUBELET:-false}" == "true" ]]; then | |||
flags+=" --api-servers=https://${KUBELET_APISERVER}" | |||
flags+=" --register-schedulable=false" | |||
flags+=" --register-with-taints=node.alpha.kubernetes.io/ismaster=:NoSchedule" | |||
if [[ "${ENABLE_MASTER_NOSCHEDULE_TAINT:-false}" == "true" ]]; then | |||
flags+=" --register-with-taints=node.alpha.kubernetes.io/ismaster=:NoSchedule" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why was this alpha in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You reviewed and lgtm'd this taint key :) why should it not be?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does Kubelet support the beta taint fields in the implementation of this flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does Kubelet support the beta taint fields in the implementation of this flag?
Yes, Kubelet in 1.6 uses field, not annotation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You reviewed and lgtm'd this taint key
I guess I was thinking this was an experimental feature because we still have Unschedulable. Maybe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kubelet uses .node.spec.taints. The alpha indicates that the name of the key is alpha, like we do with label and annotation keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If reverting this is necessary, it will be impossible for us to migrate to taints from unscheduable because that would be an unacceptable breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If reverting this is necessary to revert, it will be impossible for us to migrate to taints from unscheduable because that would be an unacceptable breaking change.
That's why we should make this opt-in
, and if needed, we should explain this somewhere to recommend user to enable the taint and gradually add tolerance on their pods, so that in the future we could enable this by default someday.
I think we should eventually enable this, so it would be better to make this opt-in. |
What is the roadmap for enabling this permanently? xref #39112 |
26e8f00
to
8d864fc
Compare
I'm weary of adding permanent disabled configuration bits to turnup without an actually timeline for enabling them. If there's a chance we might want this in the vague hand wavy future, I would prefer we just remove it for now. Can someone make a plan on how to turn this on and have @bgrant0607 sign off? |
@k8s-bot gci gce e2e test this |
@mikedanese I'm totally fine with completely removing this, but may need to know whether it is ok for @kubernetes/sig-scheduling-misc @kubernetes/sig-cluster-lifecycle-misc Should we remove the flag completely? |
To be clear: not remove the flag completely (it's used by kubeadm) but don't pass the flag in kube-up and don't add a configuration option to pass the flag. |
My view is that the scheduling SIG is responsible for the implementation of taints and tolerations, but not how they are used. Usage is the domain of @kubernetes/sig-cluster-lifecycle-misc My suggestion here is to just make sure @mikedanese and @justinsb buy into whatever you decide. |
8d864fc
to
3ab5feb
Compare
Sorry, I just mean that. :) I removed the line setting |
What about in salt?
|
3ab5feb
to
965c262
Compare
@enisoc Thanks for pointing out! Missed that, I thought we only enable it on gci/coreos. Updated the PR. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Random-Liu, mikedanese
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
Automatic merge from submit-queue |
@Random-Liu Thanks. Please cherrypick this. |
@Random-Liu Please update the PR title, which is no longer correct |
Dan said there is no need to cherrypick yet, because the release branch will be advanced to pick it up. |
This PR changed master
NoSchedule
taint to opt-in.As is discussed with @bgrant0607 @janetkuo,
NoSchedule
master taint breaks existing user workload, we should not enable it by default.Previously, NPD required the taint because it can only support one OS distro with a specific configuration. If master and node are using different OS distros, NPD will not work either on master or node. However, we've already fixed this in #40206, so for NPD it's fine to disable the taint.
This should work, but I'll still try it in my cluster to confirm.
@kubernetes/sig-scheduling-misc @dchen1107 @mikedanese