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 <tim@scalefactory.com>

* Correct typos

Co-authored-by: Tim Bannister <tim@scalefactory.com>

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

@@ -0,0 +1,250 @@
+---
+title: Conectividade do Cluster
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+Conectividade é uma parte central do Kubernetes, mas pode ser desafiador 
+entender exatamente como é o seu funcionamento esperado. Existem 4 problemas
+distintos em conectividade que devem ser tratados:
+
+1. Comunicações contêiner-para-contêiner altamente acopladas: Isso é resolvido
+   por {{< glossary_tooltip text="Pods" term_id="pod" >}} e comunicações através do `localhost`.
+2. Comunicações pod-para-pod: Esse é o foco primário desse documento.
+3. Comunicações pod-para-serviço (_service_): Isso é tratado em [Services](/docs/concepts/services-networking/service/).
+4. Comunicações Externas-para-serviços: Isso é tratado em [services](/docs/concepts/services-networking/service/).
+
+<!-- body -->
+
+Kubernetes é basicamente o compartilhamento de máquinas entre aplicações. Tradicionalmente,
+compartilhar máquinas requer a garantia de que duas aplicações não tentem utilizar
+as mesmas portas. Coordenar a alocação de portas entre múltiplos desenvolvedores é 
+muito dificil de fazer em escala e expõe os usuários a problemas em nível do cluster e 
+fora de seu controle.
+
+A alocação dinâmica de portas traz uma série de complicações para o sistema - toda
+aplicação deve obter suas portas através de flags de configuração, os servidores de API 
+devem saber como inserir números dinämicos de portas nos blocos de configuração, serviços
+precisam saber como buscar um ao outro, etc. Ao invés de lidar com isso, o Kubernetes 
+faz de uma maneira diferente.
+
+## O modelo de conectividade e rede do Kubernetes
+
+Todo `Pod` obtém seu próprio endereço IP. Isso significa que vocë não precisa 
+criar links explícitos entre os `Pods` e vocë quase nunca terá que lidar com o
+mapeamento de portas de contêineres para portas do host. Isso cria um modelo simples, 
+retro-compatível onde os `Pods` podem ser tratados muito mais como VMs ou hosts 
+físicos da perspectiva de alocação de portas, nomes, descobrimento de serviços 
+(_service discovery_), balanceamento de carga, configuração de aplicações e migrações.
+
+O Kubernetes impõe os seguintes requisitos fundamentais para qualquer implementação de 
+rede (exceto qualquer política de segmentação intencional):
+   * pods em um nó podem se comunicar com todos os pods em todos os nós sem usar _NAT_.
+   * agentes em um nó (por exemplo o kubelet ou um serviço local) podem se comunicar com 
+     todos os Pods naquele nó.
+
+Nota: Para as plataformas que suportam `Pods` executando na rede do host (como o Linux):
+
+   * pods alocados na rede do host de um nó podem se comunicar com todos os pods
+     em todos os nós sem _NAT_.
+
+Esse modelo não só é menos complexo, mas é principalmente compatível com o 
+desejo do Kubernetes de permitir a portabilidade com baixo esforço de aplicações 
+de VMs para contêineres. Se a sua aplicação executava anteriormente em uma VM, sua VM
+possuía um IP e podia se comunicar com outras VMs no seu projeto. Esse é o mesmo 
+modelo básico.
+
+Os endereços de IP no Kubernetes existem no escopo do `Pod` - contêineres em um `Pod`
+compartilham o mesmo _network namespace_ - incluíndo seu endereço de IP e MAC.
+Isso significa que contêineres que compõem um `Pod` podem se comunicar entre eles 
+através do endereço `localhost` e respectivas portas. Isso também significa que
+contêineres em um mesmo `Pod` devem coordenar a alocação e uso de portas, o que não 
+difere do modelo de processos rodando dentro de uma mesma VM. Isso é chamado de 
+modelo "IP-por-pod".
+
+Como isso é implementado é um detalhe do agente de execução de contêiner em uso.
+
+É possível solicitar uma porta no nó que será encaminhada para seu `Pod` (chamado 
+de _portas do host_), mas isso é uma operação muito específica. Como esse encaminhamento
+é implementado é um detalhe do agente de execução do contêiner. O `Pod` mesmo 
+desconhece a existência ou não de portas do host.
+
+## Como implementar o modelo de conectividade do Kubernetes
+
+Existe um número de formas de implementar esse modelo de conectividade. Esse 
+documento não é um estudo exaustivo desses vários métodos, mas pode servir como 
+uma introdução de várias tecnologias e serve como um ponto de início.
+
+A conectividade no Kubernetes é fornecida através de plugins de 
+{{< glossary_tooltip text="CNIs" term_id="cni" >}}
+
+As seguintes opções estão organizadas alfabeticamente e não implicam preferência por
+qualquer solução.
+
+{{% thirdparty-content %}}
+
+### Antrea
+
+O projeto [Antrea](https://github.com/vmware-tanzu/antrea) é uma solução de 
+conectividade para Kubernetes que pretende ser nativa. Ela utiliza o Open vSwitch 
+na camada de conectividade de dados. O Open vSwitch é um switch virtual de alta 
+performance e programável que suporta Linux e Windows. O Open vSwitch permite 
+ao Antrea implementar políticas de rede do Kubernetes (_NetworkPolicies_) de 
+uma forma muito performática e eficiente.
+
+Graças à característica programável do Open vSwitch, o Antrea consegue implementar 
+uma série de funcionalidades de rede e segurança.
+
+### AWS VPC CNI para Kubernetes
+
+O [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) oferece conectividade 
+com o AWS Virtual Private Cloud (VPC) para clusters Kubernetes. Esse plugin oferece
+alta performance e disponibilidade e baixa latência. Adicionalmente, usuários podem 
+aplicar as melhores práticas de conectividade e segurança existentes no AWS VPC
+para a construção de clusters Kubernetes. Isso inclui possibilidade de usar o 
+_VPC flow logs_, políticas de roteamento da VPC e grupos de segurança para isolamento
+de tráfego.
+
+O uso desse plugin permite aos Pods no Kubernetes ter o mesmo endereço de IP dentro do 
+pod como se eles estivessem dentro da rede do VPC. O CNI (Container Network Interface) 
+aloca um _Elastic Networking Interface_ (ENI) para cada nó do Kubernetes e usa uma 
+faixa de endereços IP secundário de cada ENI para os Pods no nó. O CNI inclui 
+controles para pré alocação dos ENIs e endereços IP para um início mais rápido dos 
+pods e permite clusters com até 2,000 nós.
+
+Adicionalmente, esse CNI pode ser utilizado junto com o [Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)
+para a criação de políticas de rede (_NetworkPolicies_). O projeto AWS VPC CNI
+tem código fonte aberto com a [documentação no Github](https://github.com/aws/amazon-vpc-cni-k8s).
+
+### Azure CNI para o Kubernetes
+[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) é um
+plugin de [código fonte aberto](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) 
+que integra os Pods do Kubernetes com uma rede virtual da Azure (também conhecida como VNet) 
+provendo performance de rede similar à de máquinas virtuais no ambiente. Os Pods 
+podem se comunicar com outras VNets e com ambientes _on-premises_ com o uso de 
+funcionalidades da Azure, e também podem ter clientes com origem dessas redes. 
+Os Pods podem acessar serviços da Azure, como armazenamento e SQL, que são 
+protegidos por _Service Endpoints_ e _Private Link_. Você pode utilizar as políticas 
+de segurança e roteamento para filtrar o tráfico do Pod. O plugin associa IPs da VNet 
+para os Pods utilizando um pool de IPs secundário pré-configurado na interface de rede
+do nó Kubernetes.
+
+O Azure CNI está disponível nativamente no [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
+
+### Calico
+
+[Calico](https://docs.projectcalico.org/) é uma solução de conectividade e 
+segurança para contêineres, máquinas virtuais e serviços nativos em hosts. O 
+Calico suporta múltiplas camadas de conectividade/dados, como por exemplo: 
+uma camada Linux eBPF nativa, uma camada de conectividade baseada em conceitos 
+padrão do Linux e uma camada baseada no HNS do Windows. O calico provê uma 
+camada completa de conectividade e rede, mas também pode ser usado em conjunto com
+[CNIs de provedores de nuvem](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) 
+para permitir a criação de políticas de rede.
+
+### Cilium
+
+[Cilium](https://github.com/cilium/cilium) é um software de código fonte aberto 
+para prover conectividade e segurança entre contêineres de aplicação. O Cilium 
+pode lidar com tráfego na camada de aplicação (ex. HTTP) e pode forçar políticas 
+de rede nas camadas L3-L7 usando um modelo de segurança baseado em identidade e 
+desacoplado do endereçamento de redes, podendo inclusive ser utilizado com outros
+plugins CNI.
+
+### Flannel
+
+[Flannel](https://github.com/coreos/flannel#flannel) é uma camada muito simples 
+de conectividade que satisfaz os requisitos do Kubernetes. Muitas pessoas 
+reportaram sucesso em utilizar o Flannel com o Kubernetes.
+
+### Google Compute Engine (GCE)
+
+Para os scripts de configuração do Google Compute Engine, [roteamento
+avançado](https://cloud.google.com/vpc/docs/routes) é usado para associar
+para cada VM uma sub-rede (o padrão é `/24` - 254 IPs). Qualquer tráfico direcionado
+para aquela sub-rede será roteado diretamente para a VM pela rede do GCE. Isso é 
+adicional ao IP principal associado à VM, que é mascarado para o acesso à Internet.
+Uma _brige_ Linux (chamada `cbr0`) é configurada para existir naquela sub-rede, e é
+configurada no docker através da opção `--bridge`.
+
+O Docker é iniciado com:
+
+
+```shell
+DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
+```
+
+Essa _bridge_ é criada pelo Kubelet (controlada pela opção `--network-plugin=kubenet`)
+de acordo com a informação `.spec.podCIDR` do Nó.
+
+O Docker irá agora alocar IPs do bloco `cbr-cidr`. Contêineres podem alcançar
+outros contêineres e nós através da interface `cbr0`. Esses IPs são todos roteáveis
+dentro da rede do projeto do GCE.
+
+O GCE mesmo não sabe nada sobre esses IPs, então não irá mascará-los quando tentarem 
+se comunicar com a internet. Para permitir isso uma regra de IPTables é utilizada para
+mascarar o tráfego para IPs fora da rede do projeto do GCE (no exemplo abaixo, 10.0.0.0/8):
+
+```shell
+iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
+```
+
+Por fim, o encaminhamento de IP deve ser habilitado no Kernel de forma a processar
+os pacotes vindos dos contêineres:
+
+```shell
+sysctl net.ipv4.ip_forward=1
+```
+
+O resultado disso tudo é que `Pods` agora podem alcançar outros `Pods` e podem também
+se comunicar com a Internet.
+
+### Kube-router
+
+[Kube-router](https://github.com/cloudnativelabs/kube-router) é uma solução construída 
+que visa prover alta performance e simplicidade operacional. Kube-router provê um 
+proxy de serviços baseado no [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html),
+uma solução de comunicação pod-para-pod baseada em encaminhamento de pacotes Linux e sem camadas
+adicionais, e funcionalidade de políticas de redes baseadas no IPTables/IPSet.
+
+### Redes L2 e bridges Linux
+
+Se você tem uma rede L2 "burra", como um switch em um ambiente "bare-metal",
+você deve conseguir fazer algo similar ao ambiente GCE explicado acima.
+Note que essas instruções foram testadas casualmente - parece funcionar, mas
+não foi propriamente testado. Se você conseguir usar essa técnica e aperfeiçoar
+o processo, por favor nos avise!!
+
+Siga a parte _"With Linux Bridge devices"_ desse
+[tutorial super bacana](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) do
+Lars Kellogg-Stedman.
+
+### Multus (Plugin multi redes) {#multus}
+
+[Multus](https://github.com/Intel-Corp/multus-cni) é um plugin Multi CNI para
+suportar a funcionalidade multi redes do Kubernetes usando objetos baseados em {{< glossary_tooltip text="CRDs" term_id="CustomResourceDefinition" >}}. 
+
+Multus suporta todos os  [plugins referência](https://github.com/containernetworking/plugins) (ex. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), 
+[DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), 
+[Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 
+que implementam a especificação de CNI e plugins de terceiros
+(ex. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), 
+[Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). 
+Adicionalmente, Multus suporta cargas de trabalho no Kubernetes que necessitem de funcionalidades como 
+[SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), 
+[OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin). 
+
+### OVN (Open Virtual Networking)
+
+OVN é uma solução de virtualização de redes de código aberto desenvolvido pela 
+comunidade Open vSwitch. Permite a criação de switches lógicos, roteadores lógicos, 
+listas de acesso, balanceadores de carga e mais, para construir diferences topologias
+de redes virtuais. Esse projeto possui um plugin específico para o Kubernetes e a 
+documentação em [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
+
+## {{% heading "whatsnext" %}}
+
+Design inicial do modelo de conectividade do Kubernetes e alguns planos futuros 
+estão descritos com maiores detalhes no 
+[documento de design de redes](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).

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

@@ -0,0 +1,18 @@
+---
+title: Container network interface (CNI)
+id: cni
+date: 2018-05-25
+full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
+short_description: >
+    Plugins Container network interface (CNI) são um tipo de plugin de Rede em conformidade com a especificação appc/CNI.
+
+
+aka: 
+tags:
+- networking 
+---
+ Plugins Container network interface (CNI) são um tipo de plugin de Rede em conformidade com a especificação appc/CNI.
+<!--more--> 
+
+* Para informações sobre Kubernetes e CNI, veja [aqui](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni).
+* 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

@@ -0,0 +1,19 @@
+---
+title: CustomResourceDefinition
+id: CustomResourceDefinition
+date: 2018-04-12
+full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
+short_description: >
+  Código customizado que define um recurso a ser adicionado ao seu servidor de API Kubernetes sem a necessidade de construir um servidor customizado.
+
+aka: 
+tags:
+- fundamental
+- operation
+- extension
+---
+ Código customizado que define um recurso a ser adicionado ao seu servidor de API Kubernetes sem a necessidade de construir um servidor customizado.
+
+<!--more-->
+
+CustomResourceDefinitions permitem você extender a API do Kubernetes para seu ambiente caso as APIs atuais não cumpram com seus requisitos.