[PT] Update content/pt/docs/concepts/architecture/control-plane-node-communication.md (#27415)

* Update doc to follow wg naming

* Rename master to control plane

* Add Konnectivity topic

* Remove unstranslated topic

* Fix some typos

* Remove blank lines

* Fix md typo

* Fix minor typos

* Fix typo (by review)

Author: edsoncelio

content/pt/docs/concepts/architecture/master-node-communication.md renamed to content/pt/docs/concepts/architecture/control-plane-node-communication.md

@@ -1,15 +1,12 @@
 ---
-reviewers:
-- dchen1107
-- liggitt
-title: Comunicação entre Node e Master
+title: Comunicação entre Nó e Control Plane
 content_type: concept
 weight: 20
 ---
 
 <!-- overview -->
 
-Este documento cataloga os caminhos de comunicação entre o Master (o
+Este documento cataloga os caminhos de comunicação entre o control plane (o
 apiserver) e o cluster Kubernetes. A intenção é permitir que os usuários
 personalizem sua instalação para proteger a configuração de rede
 então o cluster pode ser executado em uma rede não confiável (ou em IPs totalmente públicos em um
@@ -20,10 +17,10 @@ provedor de nuvem).
 
 <!-- body -->
 
-## Cluster para o Master
+## Nó para o Control Plane
 
-Todos os caminhos de comunicação do cluster para o Master terminam no
-apiserver (nenhum dos outros componentes do Master são projetados para expor
+Todos os caminhos de comunicação do cluster para o control plane terminam no
+apiserver (nenhum dos outros componentes do control plane são projetados para expor
 Serviços remotos). Em uma implantação típica, o apiserver é configurado para escutar
 conexões remotas em uma porta HTTPS segura (443) com uma ou mais clientes [autenticação](/docs/reference/access-authn-authz/authentication/) habilitado.
 Uma ou mais formas de [autorização](/docs/reference/access-authn-authz/authorization/)
@@ -41,30 +38,30 @@ para provisionamento automatizado de certificados de cliente kubelet.
 Os pods que desejam se conectar ao apiserver podem fazê-lo com segurança, aproveitando
 conta de serviço para que o Kubernetes injetará automaticamente o certificado raiz público
 certificado e um token de portador válido no pod quando ele é instanciado.
-O serviço `kubernetes` (em todos os namespaces) é configurado com um IP virtual
+O serviço `kubernetes` (no namespace `default`) é configurado com um IP virtual
 endereço que é redirecionado (via kube-proxy) para o endpoint com HTTPS no
 apiserver.
 
-Os componentes principais também se comunicam com o apiserver do cluster através da porta segura.
+Os componentes do control plane também se comunicam com o apiserver do cluster através da porta segura.
 
 Como resultado, o modo de operação padrão para conexões do cluster
-(nodes e pods em execução nos Nodes) para o Master é protegido por padrão
-e pode passar por redes não confiáveis ​​e / ou públicas.
+(nodes e pods em execução nos Nodes) para o control plane é protegido por padrão
+e pode passar por redes não confiáveis ​​e/ou públicas.
 
-## Master para o Cluster
+## Control Plane para o nó
 
-Existem dois caminhos de comunicação primários do mestre (apiserver) para o
-cluster. O primeiro é do apiserver para o processo do kubelet que é executado em
-cada Node no cluster. O segundo é do apiserver para qualquer Node, pod,
+Existem dois caminhos de comunicação primários do control plane (apiserver) para os nós.
+O primeiro é do apiserver para o processo do kubelet que é executado em
+cada nó no cluster. O segundo é do apiserver para qualquer nó, pod,
 ou serviço através da funcionalidade de proxy do apiserver.
 
 ### apiserver para o kubelet
 
 As conexões do apiserver ao kubelet são usadas para:
 
   * Buscar logs para pods.
-  * Anexar (através de kubectl) pods em execução.
-  * Fornecer a funcionalidade de encaminhamento de porta do kubelet.
+  * Anexar (através de kubectl) pods em execução.
+  * Fornecer a funcionalidade de encaminhamento de porta do kubelet.
 
 Essas conexões terminam no endpoint HTTPS do kubelet. Por padrão,
 o apiserver não verifica o certificado de serviço do kubelet,
@@ -94,12 +91,18 @@ Estas conexões **não são atualmente seguras** para serem usados por redes nã
 
 ### SSH Túnel
 
-O Kubernetes suporta túneis SSH para proteger o Servidor Master -> caminhos de comunicação no cluster. Nesta configuração, o apiserver inicia um túnel SSH para cada nó
+O Kubernetes suporta túneis SSH para proteger os caminhos de comunicação do control plane para os nós. Nesta configuração, o apiserver inicia um túnel SSH para cada nó
 no cluster (conectando ao servidor ssh escutando na porta 22) e passa
 todo o tráfego destinado a um kubelet, nó, pod ou serviço através do túnel.
 Este túnel garante que o tráfego não seja exposto fora da rede aos quais
 os nós estão sendo executados.
 
-Atualmente, os túneis SSH estão obsoletos, portanto, você não deve optar por usá-los, a menos que saiba o que está fazendo. Um substituto para este canal de comunicação está sendo projetado.
+Atualmente, os túneis SSH estão obsoletos, portanto, você não deve optar por usá-los, a menos que saiba o que está fazendo. O serviço Konnectivity é um substituto para este canal de comunicação. 
 
+### Konnectivity service
 
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+Como uma substituição aos túneis SSH, o serviço Konnectivity fornece proxy de nível TCP para a comunicação do control plane para o cluster. O serviço Konnectivity consiste em duas partes: o servidor Konnectivity na rede control plane e os agentes Konnectivity na rede dos nós. Os agentes Konnectivity iniciam conexões com o servidor Konnectivity e mantêm as conexões de rede. Depois de habilitar o serviço Konnectivity, todo o tráfego do control plane para os nós passa por essas conexões.
+
+Veja a [tarefa do Konnectivity](docs/tasks/extend-kubernetes/setup-konnectivity/) para configurar o serviço Konnectivity no seu cluster.