Update content/es/docs/concepts/architecture/control-plane-node-communication.md

Co-authored-by: Victor Morales <[email protected]>

Author: krol3

content/es/docs/concepts/architecture/control-plane-node-communication.md

@@ -23,7 +23,7 @@ habilitadas, especialmente si las [peticiones anónimas](/docs/reference/access-
 Los nodos deben ser aprovisionados con el {{< glossary_tooltip text="certificado" term_id="certificate" >}} raíz público del clúster, de modo que puedan
 conectarse de forma segura al servidor API en conjunto con credenciales de cliente válidas. Un buen enfoque es que las credenciales de cliente proporcionadas al kubelet estén en forma de certificado de cliente. Véase el [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) para ver cómo aprovisionar certificados de cliente kubelet de forma automática.
 
-{{< glossary_tooltip text="Pods" term_id="pod" >}} que deseen conectar con el apiserver pueden hacerlo de forma segura a través de una cuenta de servicio, de esta forma Kubernetes inserta de forma automática el certificado raíz público y un bearer token válido en el pod cuando es instanciado. El servicio `kubernetes` (en todos los namespaces) se configura con una dirección IP virtual que es redireccionada (via `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) al punto de acceso HTTPS en el apiserver.
+Los {{< glossary_tooltip text="Pods" term_id="pod" >}} que deseen conectar con el apiserver pueden hacerlo de forma segura a través de una cuenta de servicio, de esta forma Kubernetes inserta de forma automática el certificado raíz público y un bearer token válido en el pod cuando es instanciado. El servicio `kubernetes` (en todos los namespaces) se configura con una dirección IP virtual que es redireccionada (via `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) al punto de acceso HTTPS en el apiserver.
 
 Los componentes del plano de control también se comunican con el apiserver del clúster a través de un puerto seguro.