From 2e519b024b4d1d70e1c8e0d5b52fa53494453f18 Mon Sep 17 00:00:00 2001 From: "Edson C. (aka tuxpilgrim)" Date: Tue, 6 Apr 2021 16:04:20 -0300 Subject: [PATCH] [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) --- ...md => control-plane-node-communication.md} | 43 ++++++++++--------- 1 file changed, 23 insertions(+), 20 deletions(-) rename content/pt/docs/concepts/architecture/{master-node-communication.md => control-plane-node-communication.md} (66%) diff --git a/content/pt/docs/concepts/architecture/master-node-communication.md b/content/pt/docs/concepts/architecture/control-plane-node-communication.md similarity index 66% rename from content/pt/docs/concepts/architecture/master-node-communication.md rename to content/pt/docs/concepts/architecture/control-plane-node-communication.md index 8cf2ad86c6..de69ad8ea8 100644 --- a/content/pt/docs/concepts/architecture/master-node-communication.md +++ b/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 --- -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). -## 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,21 +38,21 @@ 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 @@ -63,8 +60,8 @@ ou serviço através da funcionalidade de proxy do apiserver. 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.