Reconstructing the Join Command for Kubeadm

 Published on 15 Aug 2019 ·  Filed in Explanation ·  415 words (estimated 2 minutes to read)

If you’ve used kubeadm to bootstrap a Kubernetes cluster, you probably know that at the end of the kubeadm init command to bootstrap the first node in the cluster, kubeadm prints out a bunch of information: how to copy over the admin Kubeconfig file, and how to join both control plane nodes and worker nodes to the cluster you just created. But what if you didn’t write these values down after the first kubeadm init command? How does one go about reconstructing the proper kubeadm join command?

Fortunately, the values needed for a kubeadm join command are relatively easy to find or recreate. First, let’s look at the values that are needed.

Here’s the skeleton of a kubeadm join command for a control plane node:

kubeadm join <endpoint-ip-or-dns>:<port> \
--token <valid-bootstrap-token> \
--discovery-token-ca-cert-hash <ca-cert-sha256-hash> \
--control-plane \
--certificate-key <certificate-key>

And here’s the skeleton of a kubeadm join command for a worker node:

kubeadm join <endpoint-ip-or-dns>:<port> \
--token <valid-bootstrap-token> \
--discovery-token-ca-cert-hash <ca-cert-sha256-hash> \

As you can see, the information needed for the worker node is a subset of the information needed for a control plane node.

Here’s how to find or recreate all the various pieces of information you need:

• The value for <endpoint-ip-or-dns>:<port> can be retrieved from the “kubeadm-config” ConfigMap in the cluster’s “kube-system” namespace. Just run kubectl -n kube-system get cm kubeadm-config -o yaml and then look for the value specified for controlPlaneEndpoint.
• For <valid-bootstrap-token>, there’s no way to find out the original token. It is, however, easy to create a new token. Just run kubeadm token create and note the output. Be aware that tokens have a default lifetime of 24 hours.
• For <ca-cert-sha256-hash>, see this blog post.
• For <certificate-key>, you can’t get whatever original value was output by kubeadm init. You can, though, generate another value. (This value is only good for two hours, so it’s far more likely you’d need to generate another value anyway.) Run kubeadm init phase upload-certs --upload-certs and make a note of the output of the command.

There you have it—how to easily reconstruct all the information needed to use kubeadm join to join a node (either control plane node or worker node) to a Kubernetes cluster. Note that this information also applies to gathering the information needed for a JoinConfiguration stanza in a kubeadm configuration file, like one used in this post to join control plane nodes or worker nodes to a cluster.

If I’ve missed anything here, feel free to contact me on Twitter. Thanks!

Metadata and Navigation

 CLI  Kubeadm  Kubernetes  Linux
Previous Post: Setting up an AWS-Integrated Kubernetes 1.15 Cluster with Kubeadm
Next Post: Creating Tagged Subnets Across AWS AZs Using Pulumi

Be social and share this post!