-
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
kubeadm: Remove cluster name from JoinConfiguration #70757
kubeadm: Remove cluster name from JoinConfiguration #70757
Conversation
/ok-to-test |
/priority important-soon |
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.
Same comment about failed conversion test.
/assign @fabriziopandini @luxas @timothysc |
I will add the conversion test tomorrow. |
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.
@ereslibre thanks for this PR!
if I got this right, JoinConfiguration.ClusterName
is used only to set the cluster name in the config map that gets returned from Discovery, and you are proposing to replace it with a constant.
I'm fine with this, even if I would use existing const DefaultClusterName
instead of creating a new const & I will remove parameter passing this const along the chain of calls.
Now, what should be decided is if it is fine to keep the above constant as a clusterName when the above config will be saved into the bootstrap-kubelet.conf
or if we want to replace the cluster name with ClusterConfiguration.ClusterName before saving bootstrap-kubelet.conf
.
In other words:
Discovery --> TLSBootstrap kubeconfig with clusterName = Constants --> bootstrap-kubelet.conf
or
Discovery --> TLSBootstrap kubeconfig with clusterName = Constants --> Replace cluster name with ClusterConfiguration.ClusterName --> bootstrap-kubelet.conf
@ereslibre @luxas @timothysc @neolit123 opinions?
+1 for this. |
+1 for this, will update the PR today. |
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.
@ereslibre
This version introduced a double second discovery, that is something we should avoid.
Could you kindly check if the approach I'm suggesting in comments is feasible for you?
cmd/kubeadm/app/cmd/join.go
Outdated
@@ -619,6 +619,12 @@ func fetchInitConfigurationFromJoinConfiguration(cfg *kubeadmapi.JoinConfigurati | |||
return nil, nil, err | |||
} | |||
|
|||
// Retrieve the final KubeConfig file with the cluster name discovered after fetching the cluster configuration |
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 don't think we should do discovery twice.
Instead I think we should change the TLS kubeconfig in place or create a new kubeconfig file from TLS kubeconfig but with a different cluster name (if you need prior art let me know)
This will allow to clean up the Discovery.For chain of calls from the clusterName field
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 changed the approach to generate a different one locally. Not resolving the conversation until you agree that is the best way.
/retest |
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.
LGTM apart from the comment
cmd/kubeadm/app/cmd/join.go
Outdated
@@ -619,6 +619,16 @@ func fetchInitConfigurationFromJoinConfiguration(cfg *kubeadmapi.JoinConfigurati | |||
return nil, nil, err | |||
} | |||
|
|||
// Create the final KubeConfig file with the cluster name discovered after fetching the cluster configuration | |||
clusterinfo := kubeconfigutil.GetClusterFromKubeConfig(tlsBootstrapCfg) | |||
tlsBootstrapCfg = kubeconfigutil.CreateWithToken( |
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 doesn't work, as the client cert returned from TLS bootstrap would be overridden with the tls bootstrap token.
The way to do this is:
- Extract
clusterinfo
(like you do) - Delete the existing cluster key and value in the .Clusters map
- Replace the current context's
.Cluster
value - Add
clusterinfo
back to the.Clusters
map with the newinitConfiguration.ClusterName
key
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.
@luxas Out of curiosity, in the case you are mentioning, this is where discovery.For
is supposed to return? (so len(cfg.Discovery.TLSBootstrapToken) == 0
):
kubernetes/cmd/kubeadm/app/discovery/discovery.go
Lines 45 to 47 in 91d6d75
if len(cfg.Discovery.TLSBootstrapToken) == 0 { | |
return config, nil | |
} |
PR rebased. |
/retest |
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ereslibre, timothysc 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 |
@ereslibre thanks! |
/retest |
What type of PR is this?
/kind cleanup
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Related kubernetes/kubeadm#1088
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?: