-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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] Add support for clusterName in config file. #60852
[kubeadm] Add support for clusterName in config file. #60852
Conversation
2cf6031
to
ca6e681
Compare
ca6e681
to
668bf1d
Compare
/retest |
668bf1d
to
2f4a878
Compare
/retest |
Tests seem to be failing with merge conflicts - my branch and this PR are up-to-date so not sure why.
|
/assign @krousey |
@karan $ git fetch upstream
$ git checkout kubeadm-cluster-name
$ git rebase upstream/master |
Correct,
|
I see build errors:
Seems like you didn't update the logic that generates ETCD certs as well. |
14a9d56
to
836696d
Compare
With the latest changes, this builds locally now.
|
ba345d7
to
ff14e48
Compare
/assign luxas |
6fe67bb
to
36ce347
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.
What's the use-case / motivation behind this?
I'm very hesitant against adding more flags to kubeadm init, in fact I think we've declared a freeze there. I could maybe see it going into the config file, but I don't want to over-engineer that either. We have phases for a reason, can the use case here be done via that API instead? In other words, is this an advanced use-case enough to justify going phases route vs the init one?
/assign @timothysc
The use case here is to be able to generate a kubeconfig that references the cluster with a name other than "kubernetes" so we can have multiple clusters in the same config file. The motivation is to allow the cluster-api tooling to manage multiple clusters, by referencing names rather than IP addresses. This PR is not urgent so we can wait until the freeze. |
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.
just a couple of nits. otherwise LGTM. However, @luxas concern sounds reasonable.
@@ -224,6 +227,8 @@ type NodeConfiguration struct { | |||
Token string `json:"token"` | |||
// CRISocket is used to retrieve container runtime info. | |||
CRISocket string `json:"criSocket,omitempty"` | |||
// ClusterName is the name for the cluster in kubeconfig. | |||
ClusterName string `json:"clusterName"` |
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.
It should be an optional field, right?
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.
Right. made it so
cmd/kubeadm/app/cmd/init.go
Outdated
@@ -107,7 +107,7 @@ var ( | |||
|
|||
// NewCmdInit returns "kubeadm init" command. | |||
func NewCmdInit(out io.Writer) *cobra.Command { | |||
cfg := &kubeadmapiext.MasterConfiguration{} | |||
cfg := &kubeadmapiext.MasterConfiguration{ClusterName: kubeadmapiext.DefaultClusterName} |
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.
Is ClusterName: kubeadmapiext.DefaultClusterName
needed to be specified here? I think it will be defaulted to the value by legacyscheme.Scheme.Default
.
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're right. Did not know that's what legacyscheme did. Thanks
cmd/kubeadm/app/cmd/join.go
Outdated
@@ -101,7 +101,7 @@ var ( | |||
|
|||
// NewCmdJoin returns "kubeadm join" command. | |||
func NewCmdJoin(out io.Writer) *cobra.Command { | |||
cfg := &kubeadmapiext.NodeConfiguration{} | |||
cfg := &kubeadmapiext.NodeConfiguration{ClusterName: kubeadmapiext.DefaultClusterName} |
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 as above
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.
Done
36ce347
to
24d6483
Compare
93f41c6
to
169792b
Compare
This is now not using a flag but config file. |
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.
Thank you for scoping this down.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: karan, 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 |
Automatic merge from submit-queue (batch tested with PRs 58178, 62491, 60852). If you want to cherry-pick this change to another branch, please follow the instructions here. |
So I am concerned with how this PR played out. @luxas said
As of the current version of Kubernetes 10 months later, there doesn't appear to be any documentation for the config file. The only thing said here: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file is
And worse, the man page which does show the config file option continues to say:
So it this experimental, or beta? Those would indicate very different levels of support. And either way, there's no clear documentation of what the config file should look like. Is this what it refers to? https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1#hdr-Kubeadm_init_configuration_types While I much prefer config files to command line arguments, and agree this was the right approach, it seems we need to button this up a bit more with consistent documentation. |
What this PR does / why we need it: Adds a
--cluster-name
arg to kubeadm init.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):See kubernetes-retired/kube-deploy#636
Code inspired by #52470
Special notes for your reviewer:
Release note: