Adding master-node-communication in PT (#13986)

content/pt/docs/concepts/architecture/cloud-controller.md

@@ -29,8 +29,6 @@ No diagrama anterior, o Kubernetes e o provedor de nuvem são integrados atravé
 * Kubernetes controller manager
 * Kubernetes API server
 
-The CCM consolidates all of the cloud-dependent logic from the preceding three components to create a single point of integration with the cloud. The new architecture with the CCM looks like this
-
 O CCM consolida toda a lógica que depende da nuvem dos três componentes anteriores para criar um único ponto de integração com a nuvem. A nova arquitetura com o CCM se parece com isso:
 
 ![CCM Kube Arch](/images/docs/post-ccm-arch.png)

content/pt/docs/concepts/architecture/master-node-communication.md

@@ -0,0 +1,106 @@
+---
+reviewers:
+- dchen1107
+- roberthbailey
+- liggitt
+title: Comunicação entre Node e Master
+content_template: templates/concept
+weight: 20
+---
+
+{{% capture overview %}}
+
+Este documento cataloga os caminhos de comunicação entre o Master (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
+provedor de nuvem).
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Cluster para o Master
+
+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
+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/)
+deve ser habilitado, especialmente se [requisições anônimas](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
+ou [tokens da conta de serviço](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
+são autorizados.
+
+Os nós devem ser provisionados com o certificado root público para o cluster
+de tal forma que eles podem se conectar de forma segura ao apiserver junto com o cliente válido
+credenciais. Por exemplo, em uma implantação padrão do GKE, as credenciais do cliente
+fornecidos para o kubelet estão na forma de um certificado de cliente. Vejo
+[bootstrapping TLS do kubelet](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+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
+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.
+
+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.
+
+## Master para o Cluster
+
+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,
+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.
+
+Essas conexões terminam no endpoint HTTPS do kubelet. Por padrão,
+o apiserver não verifica o certificado de serviço do kubelet,
+o que torna a conexão sujeita a ataques man-in-the-middle, o que o torna
+**inseguro** para passar por redes não confiáveis ​​e / ou públicas.
+
+Para verificar essa conexão, use a flag `--kubelet-certificate-authority` para
+fornecer o apiserver com um pacote de certificado raiz para usar e verificar o
+certificado de serviço da kubelet.
+
+Se isso não for possível, use o [SSH túnel](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
+entre o apiserver e kubelet se necessário para evitar a conexão ao longo de um
+rede não confiável ou pública.
+
+Finalmente, [Autenticação e/ou autorização do Kubelet](/docs/admin/kubelet-authentication-authorization/)
+deve ser ativado para proteger a API do kubelet.
+
+### apiserver para nós, pods e serviços
+
+As conexões a partir do apiserver para um nó, pod ou serviço padrão para simples
+conexões HTTP não são autenticadas nem criptografadas. Eles
+podem ser executados em uma conexão HTTPS segura prefixando `https:` no nó,
+pod, ou nome do serviço no URL da API, mas eles não validarão o certificado
+fornecido pelo ponto de extremidade HTTPS, nem fornece credenciais de cliente, enquanto
+a conexão será criptografada, não fornecerá nenhuma garantia de integridade.
+Estas conexões **não são atualmente seguras** para serem usados por redes não confiáveis ​​e/ou públicas.
+
+### 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ó
+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.
+
+{{% /capture %}}