-
Notifications
You must be signed in to change notification settings - Fork 706
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
Improve kubeadm join experience #2656
Comments
/kind support have you seen this in the HA docs? |
I had not to be honest - I think that would be a good idea to have as output of the cluster init command - if its possible to do after the cluster has been inited that is. I will try to recreate my test cluster and include the --upload-certs and see if that fixes my issue. Thanks |
in the other ticket where you commented you've mentioned external CA. i don't recall how "upload-certs" interacts with that, but i'm assuming it will not try to upload the missing CA.key in that case. so please give it a try and report if it works. obviously with this functionality we only "copy" the "certs" that are sharable between CP nodes (listed here): and if you are using external CA you have to sign the rest of the certs for secondary CP nodes.
we assume that users read the HA docs, that include a number of caveats. |
That worked - thanks - and sorry for creating an issue for this. I still think the output of cluster init could use a notice about this. Also - I tried doing sudo kubeadm init phase upload-certs --upload-certs Which gave me this output:
And then delete my certs on my "other" node - and rerunning the cluster control-plane join command - but since the original did not contain the --certificate-key it obviously did not work. So another solution could be that the 'kubeadm init phase upload-certs --upload-certs' actually output the full cluster join command again - including the --certificate-key So dum dum's like myself did not have to read documentation :-) P.S. (if you do it on an existing cluster that is) |
Assuming that people read documentation is probably okay, but making it easy is better - and it should be possible to make the output write just a little hint that if you did not use --upload-certs, then you have to manually run it - or copy the correct cerfificate files (with link to doc). |
the upload-certs phase does not know about the full join command and especially about the bootstrap token. printing the join command for a new token is possible: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token/#cmd-token-create the |
okay - so the correct workflow if you want to join another node after the initial join token has expired is to do: token=$(kubeadm token generate)
certkeyout=$(sudo kubeadm init phase upload-certs --upload-certs)
#copy the contents of certkeyout variable into an array and now a[1] contains the certificate key
readarray -td ':' a <<<"$certkeyout";declare -p a
certkey=${a[1]}
sudo kubeadm token create $token --print-join-command --certificate-key $certkey That seems like a lot of work - I will definately try to remember this flow - and it would be nice if you could invoke one command with kubeadm - that did all of the above and just output a new "join command" |
...or just use the original join command that init gave you and pass --certificate-key... thanks for testing. |
Choose one: FEATURE REQUEST/BUG
Versions
kubeadm version (use
kubeadm version
):v1.23.3Environment:
kubectl version
):v1.23.3What happened?
When executing the cluster join command as a control-plane - it fails because all the required certificates are not available on the node that wants to join the cluster.
i.e. when executing a command similar to
Output from the command is:
Fixing it requires that the user manually copies all the certificates to the local node first e.g. by executing
Rerunning the join command makes it possible to get further in the process, since it now actually tries to join the cluster
What you expected to happen?
I would expect that the join command automatically pulled the certificates from whatever secrets they probably live in.
If that is not possible, it would be nice that the cluster init command made that obvious - that any node needs to have a copy of ALL the certificates generated on the master node.
How to reproduce it (as minimally and precisely as possible)?
Run
On "master" node do
On another node whatever the master node output as its cluster join command as a control-panel:
Anything else we need to know?
As a side node I can also tell that even though the command proceeds, it then fails because the certificates that I copied - now contains the CN for the master node - and that is obbiously not working on any other nodes.
So my guess is that whoever want to do this workaround - needs to copy only the "right" certificates - and not ALL as I did.
The text was updated successfully, but these errors were encountered: