Skip to content

Commit a806f40

Browse files
rikatzTim Bannister
rikatz
and
Tim Bannister
authored
Add portuguese translation for networking concepts (#27300)
* Add portuguese translation for networking concepts * Correct minor typos * Apply suggestions from code review Co-authored-by: Tim Bannister <[email protected]> * Correct typos Co-authored-by: Tim Bannister <[email protected]>
1 parent 8b45d0f commit a806f40

File tree

3 files changed

+287
-0
lines changed

3 files changed

+287
-0
lines changed

‎content/pt/docs/concepts/cluster-administration/networking.md

Lines changed: 250 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,250 @@
1+
---
2+
title: Conectividade do Cluster
3+
content_type: concept
4+
weight: 50
5+
---
6+
7+
<!-- overview -->
8+
Conectividade é uma parte central do Kubernetes, mas pode ser desafiador
9+
entender exatamente como é o seu funcionamento esperado. Existem 4 problemas
10+
distintos em conectividade que devem ser tratados:
11+
12+
1. Comunicações contêiner-para-contêiner altamente acopladas: Isso é resolvido
13+
por {{< glossary_tooltip text="Pods" term_id="pod" >}} e comunicações através do `localhost`.
14+
2. Comunicações pod-para-pod: Esse é o foco primário desse documento.
15+
3. Comunicações pod-para-serviço (_service_): Isso é tratado em [Services](/docs/concepts/services-networking/service/).
16+
4. Comunicações Externas-para-serviços: Isso é tratado em [services](/docs/concepts/services-networking/service/).
17+
18+
<!-- body -->
19+
20+
Kubernetes é basicamente o compartilhamento de máquinas entre aplicações. Tradicionalmente,
21+
compartilhar máquinas requer a garantia de que duas aplicações não tentem utilizar
22+
as mesmas portas. Coordenar a alocação de portas entre múltiplos desenvolvedores é
23+
muito dificil de fazer em escala e expõe os usuários a problemas em nível do cluster e
24+
fora de seu controle.
25+
26+
A alocação dinâmica de portas traz uma série de complicações para o sistema - toda
27+
aplicação deve obter suas portas através de flags de configuração, os servidores de API
28+
devem saber como inserir números dinämicos de portas nos blocos de configuração, serviços
29+
precisam saber como buscar um ao outro, etc. Ao invés de lidar com isso, o Kubernetes
30+
faz de uma maneira diferente.
31+
32+
## O modelo de conectividade e rede do Kubernetes
33+
34+
Todo `Pod` obtém seu próprio endereço IP. Isso significa que vocë não precisa
35+
criar links explícitos entre os `Pods` e vocë quase nunca terá que lidar com o
36+
mapeamento de portas de contêineres para portas do host. Isso cria um modelo simples,
37+
retro-compatível onde os `Pods` podem ser tratados muito mais como VMs ou hosts
38+
físicos da perspectiva de alocação de portas, nomes, descobrimento de serviços
39+
(_service discovery_), balanceamento de carga, configuração de aplicações e migrações.
40+
41+
O Kubernetes impõe os seguintes requisitos fundamentais para qualquer implementação de
42+
rede (exceto qualquer política de segmentação intencional):
43+
* pods em um nó podem se comunicar com todos os pods em todos os nós sem usar _NAT_.
44+
* agentes em um nó (por exemplo o kubelet ou um serviço local) podem se comunicar com
45+
todos os Pods naquele nó.
46+
47+
Nota: Para as plataformas que suportam `Pods` executando na rede do host (como o Linux):
48+
49+
* pods alocados na rede do host de um nó podem se comunicar com todos os pods
50+
em todos os nós sem _NAT_.
51+
52+
Esse modelo não só é menos complexo, mas é principalmente compatível com o
53+
desejo do Kubernetes de permitir a portabilidade com baixo esforço de aplicações
54+
de VMs para contêineres. Se a sua aplicação executava anteriormente em uma VM, sua VM
55+
possuía um IP e podia se comunicar com outras VMs no seu projeto. Esse é o mesmo
56+
modelo básico.
57+
58+
Os endereços de IP no Kubernetes existem no escopo do `Pod` - contêineres em um `Pod`
59+
compartilham o mesmo _network namespace_ - incluíndo seu endereço de IP e MAC.
60+
Isso significa que contêineres que compõem um `Pod` podem se comunicar entre eles
61+
através do endereço `localhost` e respectivas portas. Isso também significa que
62+
contêineres em um mesmo `Pod` devem coordenar a alocação e uso de portas, o que não
63+
difere do modelo de processos rodando dentro de uma mesma VM. Isso é chamado de
64+
modelo "IP-por-pod".
65+
66+
Como isso é implementado é um detalhe do agente de execução de contêiner em uso.
67+
68+
É possível solicitar uma porta no nó que será encaminhada para seu `Pod` (chamado
69+
de _portas do host_), mas isso é uma operação muito específica. Como esse encaminhamento
70+
é implementado é um detalhe do agente de execução do contêiner. O `Pod` mesmo
71+
desconhece a existência ou não de portas do host.
72+
73+
## Como implementar o modelo de conectividade do Kubernetes
74+
75+
Existe um número de formas de implementar esse modelo de conectividade. Esse
76+
documento não é um estudo exaustivo desses vários métodos, mas pode servir como
77+
uma introdução de várias tecnologias e serve como um ponto de início.
78+
79+
A conectividade no Kubernetes é fornecida através de plugins de
80+
{{< glossary_tooltip text="CNIs" term_id="cni" >}}
81+
82+
As seguintes opções estão organizadas alfabeticamente e não implicam preferência por
83+
qualquer solução.
84+
85+
{{% thirdparty-content %}}
86+
87+
### Antrea
88+
89+
O projeto [Antrea](https://github.com/vmware-tanzu/antrea) é uma solução de
90+
conectividade para Kubernetes que pretende ser nativa. Ela utiliza o Open vSwitch
91+
na camada de conectividade de dados. O Open vSwitch é um switch virtual de alta
92+
performance e programável que suporta Linux e Windows. O Open vSwitch permite
93+
ao Antrea implementar políticas de rede do Kubernetes (_NetworkPolicies_) de
94+
uma forma muito performática e eficiente.
95+
96+
Graças à característica programável do Open vSwitch, o Antrea consegue implementar
97+
uma série de funcionalidades de rede e segurança.
98+
99+
### AWS VPC CNI para Kubernetes
100+
101+
O [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) oferece conectividade
102+
com o AWS Virtual Private Cloud (VPC) para clusters Kubernetes. Esse plugin oferece
103+
alta performance e disponibilidade e baixa latência. Adicionalmente, usuários podem
104+
aplicar as melhores práticas de conectividade e segurança existentes no AWS VPC
105+
para a construção de clusters Kubernetes. Isso inclui possibilidade de usar o
106+
_VPC flow logs_, políticas de roteamento da VPC e grupos de segurança para isolamento
107+
de tráfego.
108+
109+
O uso desse plugin permite aos Pods no Kubernetes ter o mesmo endereço de IP dentro do
110+
pod como se eles estivessem dentro da rede do VPC. O CNI (Container Network Interface)
111+
aloca um _Elastic Networking Interface_ (ENI) para cada nó do Kubernetes e usa uma
112+
faixa de endereços IP secundário de cada ENI para os Pods no nó. O CNI inclui
113+
controles para pré alocação dos ENIs e endereços IP para um início mais rápido dos
114+
pods e permite clusters com até 2,000 nós.
115+
116+
Adicionalmente, esse CNI pode ser utilizado junto com o [Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)
117+
para a criação de políticas de rede (_NetworkPolicies_). O projeto AWS VPC CNI
118+
tem código fonte aberto com a [documentação no Github](https://github.com/aws/amazon-vpc-cni-k8s).
119+
120+
### Azure CNI para o Kubernetes
121+
[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) é um
122+
plugin de [código fonte aberto](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)
123+
que integra os Pods do Kubernetes com uma rede virtual da Azure (também conhecida como VNet)
124+
provendo performance de rede similar à de máquinas virtuais no ambiente. Os Pods
125+
podem se comunicar com outras VNets e com ambientes _on-premises_ com o uso de
126+
funcionalidades da Azure, e também podem ter clientes com origem dessas redes.
127+
Os Pods podem acessar serviços da Azure, como armazenamento e SQL, que são
128+
protegidos por _Service Endpoints_ e _Private Link_. Você pode utilizar as políticas
129+
de segurança e roteamento para filtrar o tráfico do Pod. O plugin associa IPs da VNet
130+
para os Pods utilizando um pool de IPs secundário pré-configurado na interface de rede
131+
do nó Kubernetes.
132+
133+
O Azure CNI está disponível nativamente no [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
134+
135+
### Calico
136+
137+
[Calico](https://docs.projectcalico.org/) é uma solução de conectividade e
138+
segurança para contêineres, máquinas virtuais e serviços nativos em hosts. O
139+
Calico suporta múltiplas camadas de conectividade/dados, como por exemplo:
140+
uma camada Linux eBPF nativa, uma camada de conectividade baseada em conceitos
141+
padrão do Linux e uma camada baseada no HNS do Windows. O calico provê uma
142+
camada completa de conectividade e rede, mas também pode ser usado em conjunto com
143+
[CNIs de provedores de nuvem](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)
144+
para permitir a criação de políticas de rede.
145+
146+
### Cilium
147+
148+
[Cilium](https://github.com/cilium/cilium) é um software de código fonte aberto
149+
para prover conectividade e segurança entre contêineres de aplicação. O Cilium
150+
pode lidar com tráfego na camada de aplicação (ex. HTTP) e pode forçar políticas
151+
de rede nas camadas L3-L7 usando um modelo de segurança baseado em identidade e
152+
desacoplado do endereçamento de redes, podendo inclusive ser utilizado com outros
153+
plugins CNI.
154+
155+
### Flannel
156+
157+
[Flannel](https://github.com/coreos/flannel#flannel) é uma camada muito simples
158+
de conectividade que satisfaz os requisitos do Kubernetes. Muitas pessoas
159+
reportaram sucesso em utilizar o Flannel com o Kubernetes.
160+
161+
### Google Compute Engine (GCE)
162+
163+
Para os scripts de configuração do Google Compute Engine, [roteamento
164+
avançado](https://cloud.google.com/vpc/docs/routes) é usado para associar
165+
para cada VM uma sub-rede (o padrão é `/24` - 254 IPs). Qualquer tráfico direcionado
166+
para aquela sub-rede será roteado diretamente para a VM pela rede do GCE. Isso é
167+
adicional ao IP principal associado à VM, que é mascarado para o acesso à Internet.
168+
Uma _brige_ Linux (chamada `cbr0`) é configurada para existir naquela sub-rede, e é
169+
configurada no docker através da opção `--bridge`.
170+
171+
O Docker é iniciado com:
172+
173+
174+
```shell
175+
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
176+
```
177+
178+
Essa _bridge_ é criada pelo Kubelet (controlada pela opção `--network-plugin=kubenet`)
179+
de acordo com a informação `.spec.podCIDR` do Nó.
180+
181+
O Docker irá agora alocar IPs do bloco `cbr-cidr`. Contêineres podem alcançar
182+
outros contêineres e nós através da interface `cbr0`. Esses IPs são todos roteáveis
183+
dentro da rede do projeto do GCE.
184+
185+
O GCE mesmo não sabe nada sobre esses IPs, então não irá mascará-los quando tentarem
186+
se comunicar com a internet. Para permitir isso uma regra de IPTables é utilizada para
187+
mascarar o tráfego para IPs fora da rede do projeto do GCE (no exemplo abaixo, 10.0.0.0/8):
188+
189+
```shell
190+
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
191+
```
192+
193+
Por fim, o encaminhamento de IP deve ser habilitado no Kernel de forma a processar
194+
os pacotes vindos dos contêineres:
195+
196+
```shell
197+
sysctl net.ipv4.ip_forward=1
198+
```
199+
200+
O resultado disso tudo é que `Pods` agora podem alcançar outros `Pods` e podem também
201+
se comunicar com a Internet.
202+
203+
### Kube-router
204+
205+
[Kube-router](https://github.com/cloudnativelabs/kube-router) é uma solução construída
206+
que visa prover alta performance e simplicidade operacional. Kube-router provê um
207+
proxy de serviços baseado no [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html),
208+
uma solução de comunicação pod-para-pod baseada em encaminhamento de pacotes Linux e sem camadas
209+
adicionais, e funcionalidade de políticas de redes baseadas no IPTables/IPSet.
210+
211+
### Redes L2 e bridges Linux
212+
213+
Se você tem uma rede L2 "burra", como um switch em um ambiente "bare-metal",
214+
você deve conseguir fazer algo similar ao ambiente GCE explicado acima.
215+
Note que essas instruções foram testadas casualmente - parece funcionar, mas
216+
não foi propriamente testado. Se você conseguir usar essa técnica e aperfeiçoar
217+
o processo, por favor nos avise!!
218+
219+
Siga a parte _"With Linux Bridge devices"_ desse
220+
[tutorial super bacana](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) do
221+
Lars Kellogg-Stedman.
222+
223+
### Multus (Plugin multi redes) {#multus}
224+
225+
[Multus](https://github.com/Intel-Corp/multus-cni) é um plugin Multi CNI para
226+
suportar a funcionalidade multi redes do Kubernetes usando objetos baseados em {{< glossary_tooltip text="CRDs" term_id="CustomResourceDefinition" >}}.
227+
228+
Multus suporta todos os [plugins referência](https://github.com/containernetworking/plugins) (ex. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel),
229+
[DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp),
230+
[Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan))
231+
que implementam a especificação de CNI e plugins de terceiros
232+
(ex. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave),
233+
[Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)).
234+
Adicionalmente, Multus suporta cargas de trabalho no Kubernetes que necessitem de funcionalidades como
235+
[SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni),
236+
[OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin).
237+
238+
### OVN (Open Virtual Networking)
239+
240+
OVN é uma solução de virtualização de redes de código aberto desenvolvido pela
241+
comunidade Open vSwitch. Permite a criação de switches lógicos, roteadores lógicos,
242+
listas de acesso, balanceadores de carga e mais, para construir diferences topologias
243+
de redes virtuais. Esse projeto possui um plugin específico para o Kubernetes e a
244+
documentação em [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
245+
246+
## {{% heading "whatsnext" %}}
247+
248+
Design inicial do modelo de conectividade do Kubernetes e alguns planos futuros
249+
estão descritos com maiores detalhes no
250+
[documento de design de redes](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).

‎content/pt/docs/reference/glossary/cni.md

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
---
2+
title: Container network interface (CNI)
3+
id: cni
4+
date: 2018-05-25
5+
full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
6+
short_description: >
7+
Plugins Container network interface (CNI) são um tipo de plugin de Rede em conformidade com a especificação appc/CNI.
8+
9+
10+
aka:
11+
tags:
12+
- networking
13+
---
14+
Plugins Container network interface (CNI) são um tipo de plugin de Rede em conformidade com a especificação appc/CNI.
15+
<!--more-->
16+
17+
* Para informações sobre Kubernetes e CNI, veja [aqui](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni).
18+
* Para informações sobre Kubernetes e CNI, veja ["Plugins de rede"](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni).

‎content/pt/docs/reference/glossary/customresourcedefinition.md

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
---
2+
title: CustomResourceDefinition
3+
id: CustomResourceDefinition
4+
date: 2018-04-12
5+
full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
6+
short_description: >
7+
Código customizado que define um recurso a ser adicionado ao seu servidor de API Kubernetes sem a necessidade de construir um servidor customizado.
8+
9+
aka:
10+
tags:
11+
- fundamental
12+
- operation
13+
- extension
14+
---
15+
Código customizado que define um recurso a ser adicionado ao seu servidor de API Kubernetes sem a necessidade de construir um servidor customizado.
16+
17+
<!--more-->
18+
19+
CustomResourceDefinitions permitem você extender a API do Kubernetes para seu ambiente caso as APIs atuais não cumpram com seus requisitos.

0 commit comments

Comments
 (0)