Code change:
or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. <del> Nodes should be provisioned with the public root certificate for the cluster such that they can </del> <ins> Nodes should be provisioned with the public root {{< glossary_tooltip text="certificate" term_id="certificate" >}} for the cluster such that they can </ins> connect securely to the API server along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. <del> Pods that wish to connect to the API server can do so securely by leveraging a service account so </del> <ins> {{< glossary_tooltip text="Pods" term_id="pod" >}} that wish to connect to the API server can do so securely by leveraging a service account so </ins> that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is <del> redirected (via `kube-proxy`) to the HTTPS endpoint on the API server. </del> <ins> redirected (via `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) to the HTTPS endpoint on the API server. </ins> The control plane components also communicate with the API server over the secure port. <del> As a result, the default operating mode for connections from the nodes and pods running on the </del> <ins> As a result, the default operating mode for connections from the nodes and pod running on the </ins> nodes to the control plane is secured by default and can run over untrusted and/or public networks. ## Control plane to node There are two primary communication paths from the control plane (the API server) to the nodes. <del> The first is from the API server to the kubelet process which runs on each node in the cluster. </del> <ins> The first is from the API server to the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} process which runs on each node in the cluster. </ins> The second is from the API server to any node, pod, or service through the API server's _proxy_ functionality.

Related discussion:
text: This is a Feature Request What would you like to be There are terms that can use the addition of a glossary tooltip to show the meaning of the said term. There is no or reference section Some terms can use references like : , Why is this needed Rather than searching for the definitions of some terms , the references can help understanding the concept while staying on same page or finding more about the concept with right link. it will enhance user experience and bring more clarity and less confusion. Comments The page needed to be updated here is :
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
/kind feature /language en /sig docs
If the triage is accepted would be happy to contribute references I have searched while reading the concept. /assign
Worth doing, but the change I outline in is more valuable to work on.
here seems to be about the and page in particular. I'd agree with the general idea of making the content brief and putting extra information in the reference. For control-plane-node-communication page, I see your comment about adding a diagram there. Will try to add that as well.
For now, I'll push this commit, in case even if we shift this content to reference or another section, we would still need some of the links and references.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale