Change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: uses the outdated term “master” and “master node”. Proposed Solution: Replace references to the control plane that use the term “master” with the current term: “control plane”. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /kind cleanup /wg naming
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle “Kubelet TLS Bootstrapping” uses outdated wording
I would like to take up this issue
/assign

Discussion:
<!-- overview --> <del> In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver. </del> <ins> In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes control plane components, specifically kube-apiserver. </ins> In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly recommend using client TLS certificates on nodes.

All of the following are responsibilities of whoever sets up and manages the cluster: 1. Creating the CA key and certificate <del> 2. Distributing the CA certificate to the master nodes, where kube-apiserver is running </del> <ins> 2. Distributing the CA certificate to the control plane nodes, where kube-apiserver is running </ins> 3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet 4. Signing the kubelet certificate using the CA key 5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running

## Certificate Authority As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used <del> to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes. </del> <ins> to sign the kubelet certificate. As before, it is your responsibility to distribute them to control plane nodes. </ins> <del> For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key). </del> <ins> For the purposes of this document, we will assume these have been distributed to control plane nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key). </ins> We will refer to these as "Kubernetes CA certificate and key". All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded.

### Access to key and certificate <del> As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the master nodes. </del> <ins> As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the control plane nodes. </ins> These will be used by the controller-manager to sign the kubelet certificates. Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA

## kubelet configuration <del> Finally, with the master nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet. </del> <ins> Finally, with the control plane nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet. </ins> The kubelet requires the following configuration to bootstrap: