-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
🌱 Support new control plane label and taint #5919
🌱 Support new control plane label and taint #5919
Conversation
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.
Minor nit, rest LGTM
1982b7a
to
892bd88
Compare
@@ -980,6 +980,9 @@ func fakeNode(name string, options ...fakeNodeOption) *corev1.Node { | |||
p := &corev1.Node{ | |||
ObjectMeta: metav1.ObjectMeta{ | |||
Name: name, | |||
Labels: map[string]string{ | |||
labelNodeRoleControlPlane: "", |
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 now necessary because the old implementation of getControlPlaneNodes
did select all nodes as control plane nodes independent of the label when using fakeClient (I assume because ctrlclient.MatchingLabels(labels)
is not implemented in fake client)
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.
There are tests for it https://github.com/kubernetes-sigs/controller-runtime/blob/f20692b7ce2a9dda7eb298504a9c47aaf5a96544/pkg/client/fake/client_test.go#L314-L324 and it should be supported afaik.
The code that does the selection is in https://github.com/kubernetes-sigs/controller-runtime/blob/4e7f0c968b90a306fb9ef22f8e92fa36b98b4ef1/pkg/cache/internal/cache_reader.go#L107-L108 — are we not using a cache here perhaps?
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.
I'll take a closer look.
To be clear for the new code everything works fine. I think it's now mostly a question of why didn't we have to set the control plane node label with the old code. (aka is there something wrong with fake client or our usage of it)
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.
Okay everything worked/works as expected.
In the relevant unit test we're injecting the list result:
cluster-api/controlplane/kubeadm/internal/workload_cluster_conditions_test.go
Lines 84 to 88 in 5026786
injectClient: &fakeClient{ | |
list: &corev1.NodeList{ | |
Items: []corev1.Node{*fakeNode("n1")}, | |
}, | |
}, |
Previously, we didn't have to set the control plane label as the result of the list was automatically the list of control plane nodes. As we're now iterating through the result and checking for the label it became relevant.
@sbueringer: The
The following commands are available to trigger optional jobs:
Use
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. |
/test pull-cluster-api-verify-main |
thanks @sbueringer! |
test/framework/deployment_helpers.go
Outdated
|
||
// Use the control-plane label for Kubernetes version >= v1.20.0. | ||
if utilversion.MustParseGeneric(serverVersion.String()).AtLeast(utilversion.MustParseGeneric("v1.20.0")) { | ||
workloadDeployment.Spec.Template.Spec.NodeSelector = map[string]string{"node-role.kubernetes.io/control-plane": ""} |
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.
should the strings be constants here and below?
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.
Yup, done.
892bd88
to
6893268
Compare
/lgtm |
found this entry in the TS guide that might have to be updated: |
both will be applied on nodes in 1.24. xref KEP:
yes, for new CP nodes (init or join) only the "control-plane" label will be added. |
Thank you! Will update accordingly |
6893268
to
a758f8f
Compare
a758f8f
to
c2a843c
Compare
I've updated @fabriziopandini ptal :) |
c2a843c
to
eb6d6b6
Compare
Hey folks, |
eb6d6b6
to
f44f816
Compare
Signed-off-by: Stefan Büringer [email protected]
f44f816
to
2497fcc
Compare
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.
/approve
/lgtm
Should we include this PR in the v1.1 release? |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I'm not sure. On one side we would need this PR to support v1.24, on the other side we will need more than that. (see release specific issues in #5968) So this PR alone is not enough to support the upcoming v1.24 release. I'm also not sure if we want to use v1.24 support as a forcing function so folks are upgrading to CAPI v1.2 :) Even if we don't cherry-pick now, once we know what we need to support v1.24.0 (after its release) we can still cherry-pick that for a new v1.1.x release if we have consensus that we want to cherry-pick 1.24 support into CAPI v1.1.x /cc @fabriziopandini |
fwiw 1.24 is planned for Tuesday 19th April 2022 Given the timelines I'd be in favour of supporting 1.24 in 1.1.x. For ref #5968 |
I don't have a strong opinion either way, but we should only consider cherry-picking it if we plan to support v1.24 in v1.1.x |
We'll bring it up in the office hours today, but we would want to support v1.24 in v1.1.x. (we'll wait with merging the cherry-pick until after the meeting) |
@sbueringer: new pull request created: #6084 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. |
@sbueringer Would it be ok to cherry pick this for release-0.4 ? If not, v1a4 cluster wont be able to migrate to 1.24.x because of the missing node role label check. |
CAPI v0.4.x doesn't support Kubernetes 1.24: https://cluster-api.sigs.k8s.io/reference/versions.html For v1.24 support you have to upgrade to CAPI v1.1. Note: CAPI v0.4 is out of support since 2022-04-06 and there won't be another v0.4.x release. P.S. This is not the only PR we would have to backport to make this happen |
Ah ok , missed that, thanks |
Signed-off-by: Stefan Büringer [email protected]
What this PR does / why we need it:
This PR is required to be compatible with the latest changes in Kubernetes 1.24.
In Kubernetes 1.24 on control plane nodes kubeadm now:
node-role.kubernetes.io/control-plane
andnode-role.kubernetes.io/master
taintsnode-role.kubernetes.io/master
label anymore (onlynode-role.kubernetes.io/control-plane
)Thus:
node-role.kubernetes.io/control-plane
is additionally added so our controllers can also run on 1.24 control-plane nodes.xref: corresponding kubeadm issue kubernetes/kubeadm#2200
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Partially implements #3279