Move portuguese content to pt-br to correct shortcode problems and add redirection (#27413)
* Move portuguese content to pt-br to correct shortcode problems and add a redirection * Correct small shortcode * Move portuguese content to pt-br to correct shortcode problems and add a redirection * Add missing print page shortcodes
This commit is contained in:
parent
d342d4d9fe
commit
ae197690de
|
@ -399,15 +399,15 @@ time_format_blog = "02.01.2006"
|
||||||
# A list of language codes to look for untranslated content, ordered from left to right.
|
# A list of language codes to look for untranslated content, ordered from left to right.
|
||||||
language_alternatives = ["en"]
|
language_alternatives = ["en"]
|
||||||
|
|
||||||
[languages.pt]
|
[languages.pt-br]
|
||||||
title = "Kubernetes"
|
title = "Kubernetes"
|
||||||
description = "Orquestração de contêineres em nível de produção"
|
description = "Orquestração de contêineres em nível de produção"
|
||||||
languageName ="Português"
|
languageName ="Português"
|
||||||
weight = 9
|
weight = 9
|
||||||
contentDir = "content/pt"
|
contentDir = "content/pt-br"
|
||||||
languagedirection = "ltr"
|
languagedirection = "ltr"
|
||||||
|
|
||||||
[languages.pt.params]
|
[languages.pt-br.params]
|
||||||
time_format_blog = "02.01.2006"
|
time_format_blog = "02.01.2006"
|
||||||
# A list of language codes to look for untranslated content, ordered from left to right.
|
# A list of language codes to look for untranslated content, ordered from left to right.
|
||||||
language_alternatives = ["en"]
|
language_alternatives = ["en"]
|
||||||
|
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
@ -0,0 +1,105 @@
|
||||||
|
---
|
||||||
|
reviewers:
|
||||||
|
- dchen1107
|
||||||
|
- liggitt
|
||||||
|
title: Comunicação entre Node e Master
|
||||||
|
content_type: concept
|
||||||
|
weight: 20
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- 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).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<!-- 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.
|
||||||
|
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue