whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Move portuguese content to pt-br to correct shortcode problems and add redirection (#27413)

Browse Source 
* 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:
Ricardo Katz
2021-04-19 21:10:33 -03:00
committed by GitHub
parent d342d4d9fe
commit ae197690de
124 changed files with 126 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/pt-br/docs/concepts/extend-kubernetes/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: Extendendo o Kubernetes
weight: 110
---
content/pt-br/docs/concepts/extend-kubernetes/api-extension/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: Extendendo a API do Kubernetes
weight: 20
---
content/pt-br/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+66
View File
@@ -0,0 +1,66 @@
---
title: Extendendo a API do Kubernetes com a camada de agregação
reviewers:
- lavalamp
- cheftako
- chenopis
content_type: concept
weight: 20
---
<!-- overview -->
A camada de agregação permite ao Kubernetes ser estendido com APIs adicionais,
para além do que é oferecido pelas APIs centrais do Kubernetes.
As APIs adicionais podem ser soluções prontas tal como o
[catálogo de serviços](/docs/concepts/extend-kubernetes/service-catalog/),
ou APIs que você mesmo desenvolva.
A camada de agregação é diferente dos [Recursos Personalizados](/docs/concepts/extend-kubernetes/api-extension/custom-resources/),
que são uma forma de fazer o {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
reconhecer novas espécies de objetos.
<!-- body -->
## Camada de agregação
A camada de agregação executa em processo com o kube-apiserver.
Até que um recurso de extensão seja registado, a camada de agregação
não fará nada. Para registar uma API, terá de adicionar um objeto *APIService*
que irá "reclamar" o caminho URL na API do Kubernetes. Nesta altura, a camada
de agregação procurará qualquer coisa enviada para esse caminho da API
(e.g. `/apis/myextension.mycompany.io/v1/…`) para o *APIService* registado.
A maneira mais comum de implementar o *APIService* é executar uma
*extensão do servidor API* em *Pods* que executam no seu cluster.
Se estiver a usar o servidor de extensão da API para gerir recursos
no seu cluster, o servidor de extensão da API (também escrito como "extension-apiserver")
é tipicamente emparelhado com um ou mais {{< glossary_tooltip text="controladores" term_id="controller" >}}.
A biblioteca apiserver-builder providencia um esqueleto para ambos
os servidores de extensão da API e controladores associados.
### Latência da resposta
Servidores de extensão de APIs devem ter baixa latência de rede de e para o kube-apiserver.
Pedidos de descoberta são necessários que façam a ida e volta do kube-apiserver em 5
segundos ou menos.
Se o seu servidor de extensão da API não puder cumprir com o requisito de latência,
considere fazer alterações que permitam atingi-lo. Pode também definir
[portal de funcionalidade](/docs/reference/command-line-tools-reference/feature-gates/) `EnableAggregatedDiscoveryTimeout=false` no kube-apiserver para desativar
a restrição de intervalo. Esta portal de funcionalidade deprecado será removido
num lançamento futuro.
## {{% heading "whatsnext" %}}
* Para pôr o agregador a funcionar no seu ambiente, [configure a camada de agregação](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
* De seguida, [configura um api-server de extensão](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) para funcionar com a camada de agregação.
* Também, aprenda como pode [estender a API do Kubernetes através do use de Definições de Recursos Personalizados](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
* Leia a especificação do [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)
content/pt-br/docs/concepts/extend-kubernetes/compute-storage-net/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: Extensões de Computação, armazenamento e redes
weight: 30
---
content/pt-br/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+209
View File
@@ -0,0 +1,209 @@
---
title: Plugins de rede
content_type: concept
weight: 10
---
<!-- overview -->
Plugins de redes no Kubernetes podem ser dos seguintes tipos:
* Plugins CNI: Aderentes à especificação [Container Network Interface](https://github.com/containernetworking/cni) (CNI), desenhados para interoperabilidade.
* Kubernetes usa a versão [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) da especificação CNI.
* Plugin kubenet: Implementa o `cbr0` básico usando os plugins CNI `bridge` e `host-local`
<!-- body -->
## Instalação
O kubelet possui um plugin único padrão, e um plugin padrão comum para todo o cluster.
Ele verifica o plugin quando inicia, se lembra o que encontrou, e executa o plugin selecionado
em momentos oportunos dentro do ciclo de vida de um Pod (isso é verdadeiro apenas com o Docker,
uma vez que o CRI gerencia seus próprios plugins de CNI). Existem dois parâmetros de linha de comando
no Kubelet para se ter em mente quando usando plugins:
* `cni-bin-dir`: O Kubelet verifica esse diretório por plugins na inicialização
* `network-plugin`: O plugin de rede que deve ser utilizado do diretório configurado em
`cni-bin-dir`. Deve ser igual ao nome configurado por um plugin no diretório de plugins.
Para plugins de CNI, isso equivale ao valor `cni`.
## Requisitos de plugins de Rede
Além de prover a [interface `NetworkPlugin`](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)
para configuração da rede do pod, o plugin pode necessitar de suporte específico ao
kube-proxy.
O proxy iptables obviamente depende do iptables, e o plugin deve garantir que o
tráfego do contêiner esteja disponível para o iptables. Por exemplo, se o plugin
conecta os contêineres à _Linux bridge_, o plugin deve configurar a diretiva de
_sysctl_ `net/bridge/bridge-nf-call-iptables` com o valor `1` para garantir que o
proxy iptables opere normalmente. Se o plugin não faz uso da _Linux Bridge_ (mas outro
mecanismo, como Open vSwitch) ele deve garantir que o tráfego do contêiner é roteado
apropriadamente para o proxy.
Por padrão, se nenhum plugin de rede é configurado no kubelet, o plugin `noop` é utilizado,
que configura `net/bridge/bridge-nf-call-iptables=1` para garantir que configurações simples
(como Docker com _bridge Linux_) operem corretamente com o proxy iptables.
### CNI
O plugin de CNI é selecionado utilizando-se da opção `--network-plugin=cni` no início do Kubeket.
O Kubelet lê um arquivo do diretório especificado em `--cni-conf-dir` (padrão `/etc/cni/net.d`)
e usa a configuração de CNI desse arquivo para configurar a rede de cada Pod. O arquivo de
configuração do CNI deve usar a [especificação de CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration),
e qualquer plugin referenciado nesse arquivo deve estar presente no diretório
`--cni-bin-dir` (padrão `/opt/cni/bin`).
Se existirem múltiplos arquivos de configuração no diretório, o kubelet usa o arquivo de
configuração que vier primeiro pelo nome, em ordem alfabética.
Adicionalmente ao plugin de CNI especificado no arquivo de configuração, o Kubernetes requer
o plugin CNI padrão [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) ao menos na versão 0.2.0.
#### Suporte a hostPort
O plugin de redes CNI suporta `hostPort`. Você pode utilizar o plugin oficial
[portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
ou usar seu próprio plugin com a funcionalidade de _portMapping_.
Caso você deseje habilitar o suporte a `hostPort`, você deve especificar
`portMappings capability` no seu `cni-conf-dir`.
Por exemplo:
```json
{
"name": "k8s-pod-network",
"cniVersion": "0.3.0",
"plugins": [
{
"type": "calico",
"log_level": "info",
"datastore_type": "kubernetes",
"nodename": "127.0.0.1",
"ipam": {
"type": "host-local",
"subnet": "usePodCidr"
},
"policy": {
"type": "k8s"
},
"kubernetes": {
"kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
}
},
{
"type": "portmap",
"capabilities": {"portMappings": true}
}
]
}
```
#### Suporte a controle de banda
**Funcionalidade experimental**
O plugin de rede CNI também suporta o controle de banda de entrada e saída.
Você pode utilizar o plugin oficial [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
desenvolvido ou usar seu próprio plugin de controle de banda.
Se você habilitar o suporte ao controle de banda, você deve adicionar o plugin `bandwidth`
no seu arquivo de configuração de CNI (padrão `/etc/cni/net.d`) e garantir que o programa
exista no diretório de binários do CNI (padrão `/opt/cni/bin`).
```json
{
"name": "k8s-pod-network",
"cniVersion": "0.3.0",
"plugins": [
{
"type": "calico",
"log_level": "info",
"datastore_type": "kubernetes",
"nodename": "127.0.0.1",
"ipam": {
"type": "host-local",
"subnet": "usePodCidr"
},
"policy": {
"type": "k8s"
},
"kubernetes": {
"kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
}
},
{
"type": "bandwidth",
"capabilities": {"bandwidth": true}
}
]
}
```
Agora você pode adicionar as anotações `kubernetes.io/ingress-bandwidth` e
`kubernetes.io/egress-bandwidth` em seu pod.
Por exemplo:
```yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubernetes.io/ingress-bandwidth: 1M
kubernetes.io/egress-bandwidth: 1M
...
```
### kubenet
Kubenet é um plugin de rede muito simples, existente apenas no Linux. Ele não
implementa funcionalidades mais avançadas, como rede entre nós ou políticas de rede.
Ele é geralmente utilizado junto a um provedor de nuvem que configura as regras de
roteamento para comunicação entre os nós, ou em ambientes com apenas um nó.
O Kubenet cria uma _interface bridge_ no Linux chamada `cbr0` e cria um par _veth_
para cada um dos pods com o host como a outra ponta desse par, conectado à `cbr0`.
Na interface no lado do Pod um endereço IP é alocado de uma faixa associada ao nó,
sendo parte de alguma configuração no nó ou pelo controller-manager. Na interface `cbr0`
é associado o MTU equivalente ao menor MTU de uma interface de rede do host.
Esse plugin possui alguns requisitos:
* Os plugins CNI padrão `bridge`, `lo` e `host-local` são obrigatórios, ao menos na
versão 0.2.0. O Kubenet buscará inicialmente esses plugins no diretório `/opt/cni/bin`.
Especifique a opção `cni-bin-dir` no kubelet para fornecer um diretório adicional
de busca. O primeiro local equivalente será o utilizado.
* O kubelet deve ser executado com a opção `--network-plugin=kubenet` para habilitar esse plugin.
* O Kubelet deve ainda ser executado com a opção `--non-masquerade-cidr=<clusterCidr>` para
garantir que o tráfego de IPs para fora dessa faixa seja mascarado.
* O nó deve possuir uma subrede associada, através da opção `--pod-cidr` configurada
na inicialização do kubelet, ou as opções `--allocate-node-cidrs=true --cluster-cidr=<cidr>`
utilizadas na inicialização do _controller-manager_.
### Customizando o MTU (com kubenet)
O MTU deve sempre ser configurado corretamente para obter-se a melhor performance de
rede. Os plugins de rede geralmente tentam detectar uma configuração correta de MTU,
porém algumas vezes a lógica não irá resultar em uma configuração adequada. Por exemplo,
se a _Docker bridge_ ou alguma outra interface possuir um MTU pequeno, o kubenet irá
selecionar aquela MTU. Ou caso você esteja utilizando encapsulamento IPSEC, o MTU deve
ser reduzido, e esse cálculo não faz parte do escopo da maioria dos plugins de rede.
Sempre que necessário, você pode configurar explicitamente o MTU com a opção `network-plugin-mtu`
no kubelet. Por exemplo, na AWS o MTU da `eth0` geralmente é 9001 então você deve
especificar `--network-plugin-mtu=9001`. Se você estiver usando IPSEC você deve reduzir
o MTU para permitir o encapsulamento excedente; por exemplo: `--network-plugin-mtu=8773`.
Essa opção faz parte do plugin de rede. Atualmente **apenas o kubenet suporta a configuração
`network-plugin-mtu`**.
## Resumo de uso
* `--network-plugin=cni` especifica que devemos usar o plugin de redes `cni` com os
binários do plugin localizados em `--cni-bin-dir` (padrão `/opt/cni/bin`) e as
configurações do plugin localizadas em `--cni-conf-dir` (default `/etc/cni/net.d`).
* `--network-plugin=kubenet` especifica que iremos usar o plugin de rede `kubenet`
com os plugins CNI `bridge`, `lo` e `host-local` localizados em `/opt/cni/bin` ou `cni-bin-dir`.
* `--network-plugin-mtu=9001` especifica o MTU a ser utilizado, atualmente apenas em uso
pelo plugin de rede `kubenet`
## {{% heading "whatsnext" %}}
content/pt-br/docs/concepts/extend-kubernetes/operator.md
+138
View File
@@ -0,0 +1,138 @@
---
title: Padrão Operador
content_type: concept
weight: 30
---
<!-- overview -->
Operadores são extensões de software para o Kubernetes que
fazem uso de [*recursos personalizados*](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
para gerir aplicações e os seus componentes. Operadores seguem os
princípios do Kubernetes, notavelmente o [ciclo de controle](/docs/concepts/#kubernetes-control-plane).
<!-- body -->
## Motivação
O padrão Operador tem como objetivo capturar o principal objetivo de um operador
humano que gere um serviço ou um conjunto de serviços. Operadores humanos
responsáveis por aplicações e serviços específicos têm um conhecimento
profundo da forma como o sistema é suposto se comportar, como é instalado
e como deve reagir na ocorrência de problemas.
As pessoas que executam cargas de trabalho no Kubernetes habitualmente gostam
de usar automação para cuidar de tarefas repetitivas. O padrão Operador captura
a forma como pode escrever código para automatizar uma tarefa para além do que
o Kubernetes fornece.
## Operadores no Kubernetes
O Kubernetes é desenhado para automação. *Out of the box*, você tem bastante
automação embutida no núcleo do Kubernetes. Pode usar
o Kubernetes para automatizar instalações e executar cargas de trabalho,
e pode ainda automatizar a forma como o Kubernetes faz isso.
O conceito de {{< glossary_tooltip text="controlador" term_id="controller" >}} no
Kubernetes permite a extensão do comportamento sem modificar o código do próprio
Kubernetes.
Operadores são clientes da API do Kubernetes que atuam como controladores para
um dado [*Custom Resource*](/docs/concepts/api-extension/custom-resources/)
## Exemplo de um Operador {#exemplo}
Algumas das coisas que um operador pode ser usado para automatizar incluem:
* instalar uma aplicação a pedido
* obter e restaurar backups do estado dessa aplicação
* manipular atualizações do código da aplicação juntamente com alterações
como esquemas de base de dados ou definições de configuração extra
* publicar um *Service* para aplicações que não suportam a APIs do Kubernetes
para as descobrir
* simular una falha em todo ou parte do cluster de forma a testar a resiliência
* escolher um lider para uma aplicação distribuída sem um processo
de eleição de membro interno
Como deve um Operador parecer em mais detalhe? Aqui está um exemplo em mais
detalhe:
1. Um recurso personalizado (*custom resource*) chamado SampleDB, que você pode
configurar para dentro do *cluster*.
2. Um *Deployment* que garante que um *Pod* está a executar que contém a
parte controlador do operador.
3. Uma imagem do *container* do código do operador.
4. Código do controlador que consulta o plano de controle para descobrir quais
recursos *SampleDB* estão configurados.
5. O núcleo do Operador é o código para informar ao servidor da API (*API server*) como fazer
a realidade coincidir com os recursos configurados.
* Se você adicionar um novo *SampleDB*, o operador configurará *PersistentVolumeClaims*
para fornecer armazenamento de base de dados durável, um *StatefulSet* para executar *SampleDB* e
um *Job* para lidar com a configuração inicial.
* Se você apagá-lo, o Operador tira um *snapshot* e então garante que
o *StatefulSet* e *Volumes* também são removidos.
6. O operador também gere backups regulares da base de dados. Para cada recurso *SampleDB*,
o operador determina quando deve criar um *Pod* que possa se conectar
à base de dados e faça backups. Esses *Pods* dependeriam de um *ConfigMap*
e / ou um *Secret* que possui detalhes e credenciais de conexão com à base de dados.
7. Como o Operador tem como objetivo fornecer automação robusta para o recurso
que gere, haveria código de suporte adicional. Para este exemplo,
O código verifica se a base de dados está a executar uma versão antiga e, se estiver,
cria objetos *Job* que o atualizam para si.
## Instalar Operadores
A forma mais comum de instalar um Operador é a de adicionar a
definição personalizada de recurso (*Custom Resource Definition*) e
o seu Controlador associado ao seu cluster.
O Controlador vai normalmente executar fora do
{{< glossary_tooltip text="plano de controle" term_id="control-plane" >}},
como você faria com qualquer aplicação containerizada.
Por exemplo, você pode executar o controlador no seu cluster como um *Deployment*.
## Usando um Operador
Uma vez que você tenha um Operador instalado, usaria-o adicionando, modificando
ou apagando a espécie de recurso que o Operador usa. Seguindo o exemplo acima,
você configuraria um *Deployment* para o próprio Operador, e depois:
```shell
kubectl get SampleDB # encontra a base de dados configurada
kubectl edit SampleDB/example-database # mudar manualmente algumas definições
```
&hellip;e é isso! O Operador vai tomar conta de aplicar
as mudanças assim como manter o serviço existente em boa forma.
## Escrevendo o seu próprio Operador {#escrevendo-operador}
Se não existir no ecosistema um Operador que implementa
o comportamento que pretende, pode codificar o seu próprio.
[Qual é o próximo](#qual-é-o-próximo) você vai encontrar
alguns *links* para bibliotecas e ferramentas que pode usar
para escrever o seu próprio Operador *cloud native*.
Pode também implementar um Operador (isto é, um Controlador) usando qualquer linguagem / *runtime*
que pode atuar como um [cliente da API do Kubernetes](/docs/reference/using-api/client-libraries/).
## {{% heading "whatsnext" %}}
* Aprenda mais sobre [Recursos Personalizados](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Encontre operadores prontos em [OperatorHub.io](https://operatorhub.io/) para o seu caso de uso
* Use ferramentes existentes para escrever os seus Operadores:
* usando [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
* usando [kubebuilder](https://book.kubebuilder.io/)
* usando [Metacontroller](https://metacontroller.app/) juntamente com WebHooks que
implementa você mesmo
* usando o [Operator Framework](https://github.com/operator-framework/getting-started)
* [Publique](https://operatorhub.io/) o seu operador para que outras pessoas o possam usar
* Leia o [artigo original da CoreOS](https://coreos.com/blog/introducing-operators.html) que introduz o padrão Operador
* Leia um [artigo](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) da Google Cloud sobre as melhores práticas para contruir Operadores