Merge pull request #51721 from jhonmike/issue-51720

[pt-br] Update /content/pt-br/docs/concepts/architecture/controller.md

Author: k8s-ci-robot

content/pt-br/docs/concepts/architecture/controller.md

@@ -9,149 +9,158 @@ weight: 30
 Em robótica e automação um _control loop_, ou em português _ciclo de controle_, é
 um ciclo não terminado que regula o estado de um sistema.
 
-Um exemplo de ciclo de controle é um termostato de uma sala.
+Aqui está um exemplo de um ciclo de controle: um termostato em uma sala.
 
 Quando você define a temperatura, isso indica ao termostato
-sobre o seu *estado desejado*. A temperatura ambiente real é o
-*estado atual*. O termostato atua de forma a trazer o estado atual
+sobre o seu _estado desejado_. A temperatura ambiente real é o
+_estado atual_. O termostato atua para trazer o estado atual
 mais perto do estado desejado, ligando ou desligando o equipamento.
 
 {{< glossary_definition term_id="controller" length="short">}}
 
-
-
-
 <!-- body -->
 
-## Padrão Controlador (Controller pattern)
+## Padrão Controlador
 
 Um controlador rastreia pelo menos um tipo de recurso Kubernetes.
-Estes [objetos](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
-têm um campo *spec* que representa o *estado desejado*.
-O(s) controlador(es) para aquele recurso são responsáveis por trazer o *estado atual*
-mais perto do *estado desejado*.
+Estes {{< glossary_tooltip text="objetos" term_id="object" >}}
+têm um campo spec que representa o estado desejado. O(s)
+controlador(es) para aquele recurso são responsáveis por fazer o estado atual
+se aproximar daquele estado desejado.
 
-O controlador pode executar uma ação ele próprio, ou,
-o que é mais comum, no Kubernetes, o controlador envia uma mensagem para o
-{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} (servidor de API) que tem
-efeitos colaterais úteis. Você vai ver exemplos disto abaixo.
+O controlador pode executar a ação ele próprio; mais comumente, no Kubernetes,
+um controlador enviará mensagens para o
+{{< glossary_tooltip text="servidor de API" term_id="kube-apiserver" >}} que têm
+efeitos colaterais úteis. Você verá exemplos disso abaixo.
 
-### Controlador via API server
+{{< comment >}}
+Alguns controladores embutidos, como o controlador de namespace, atuam em objetos
+que não têm um spec. Para simplicidade, esta página omite explicar esse
+detalhe.
+{{< /comment >}}
+
+### Controle via servidor de API
 
 O controlador {{< glossary_tooltip term_id="job" >}} é um exemplo de um
-controlador Kubernetes embutido. Controladores embutidos gerem estados através da
-interação com o *cluster API server*.
-
-*Job* é um recurso do Kubernetes que é executado em um
-*{{< glossary_tooltip term_id="pod" >}}*, ou talvez vários *Pods*, com o objetivo de
-executar uma tarefa e depois parar.
-
-(Uma vez [agendado](/docs/concepts/scheduling/), objetos *Pod* passam a fazer parte
-do *estado desejado* para um kubelet.
-
-Quando o controlador *Job* observa uma nova tarefa ele garante que,
-algures no seu *cluster*, os kubelets num conjunto de nós (*Nodes*) estão correndo o número
-correto de *Pods* para completar o trabalho.
-O controlador *Job* não corre *Pods* ou *containers* ele próprio.
-Em vez disso, o controlador *Job* informa o *API server* para criar ou remover *Pods*.
-Outros componentes do plano de controle
-({{< glossary_tooltip text="control plane" term_id="control-plane" >}})
-atuam na nova informação (existem novos *Pods* para serem agendados e executados),
+controlador embutido do Kubernetes. Controladores embutidos gerenciam estado através da
+interação com o servidor de API do cluster.
+
+Job é um recurso do Kubernetes que executa um
+{{< glossary_tooltip term_id="pod" >}}, ou talvez vários Pods, para realizar
+uma tarefa e depois parar.
+
+(Uma vez [agendado](/docs/concepts/scheduling-eviction/), objetos Pod se tornam parte do
+estado desejado para um kubelet).
+
+Quando o controlador Job vê uma nova tarefa, ele garante que, em algum lugar
+no seu cluster, os kubelets em um conjunto de Nodes estão executando o número
+correto de Pods para realizar o trabalho.
+O controlador Job não executa nenhum Pod ou container
+ele próprio. Em vez disso, o controlador Job informa o servidor de API para criar ou remover
+Pods.
+Outros componentes no
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}
+atuam na nova informação (existem novos Pods para serem agendados e executados),
 e eventualmente o trabalho é feito.
 
-Após ter criado um novo *Job*, o *estado desejado* é que esse Job seja completado.
-O controlador *Job* faz com que o *estado atual* para esse *Job* esteja mais perto do seu
-*estado desejado*: criando *Pods* que fazem o trabalho desejado para esse *Job* para que
-o *Job* fique mais perto de ser completado.
+Após criar um novo Job, o estado desejado é que esse Job seja completado.
+O controlador Job faz com que o estado atual para esse Job esteja mais próximo do seu
+estado desejado: criando Pods que fazem o trabalho que você queria para esse Job, para que
+o Job esteja mais próximo da conclusão.
 
 Controladores também atualizam os objetos que os configuram.
-Por exemplo: assim que o trabalho de um *Job* está completo,
-o controlador *Job* atualiza esse objeto *Job* para o marcar como `Finished` (terminado).
+Por exemplo: uma vez que o trabalho de um Job está completo,
+o controlador Job atualiza esse objeto Job para marcá-lo como `Finished`.
 
-(Isto é um pouco como alguns termostatos desligam uma luz para
-indicar que a temperatura da sala está agora na temperatura que foi introduzida).
+(Isso é um pouco como alguns termostatos desligam uma luz para
+indicar que a sala está agora na temperatura que você definiu).
 
 ### Controle direto
 
-Em contraste com *Job*, alguns controladores necessitam de efetuar
-mudanças fora do *cluster*.
+Em contraste com Job, alguns controladores precisam fazer mudanças em
+coisas fora do seu cluster.
+
+Por exemplo, se você usar um ciclo de controle para garantir que existem
+{{< glossary_tooltip text="Nodes" term_id="node" >}} suficientes
+no seu cluster, então esse controlador precisa de algo fora do
+cluster atual para configurar novos Nodes quando necessário.
 
-Por exemplo, se usar um ciclo de controle para garantir que existem
-*{{< glossary_tooltip text="Nodes" term_id="node" >}}* suficientes
-no seu *cluster*, então esse controlador necessita de algo exterior ao
-*cluster* atual para configurar novos *Nodes* quando necessário.
+Controladores que interagem com estado externo encontram seu estado desejado a partir do
+servidor de API, então comunicam diretamente com um sistema externo para trazer
+o estado atual mais próximo da linha.
 
-Controladores que interagem com estados externos encontram o seu estado desejado
-a partir do *API server*, e então comunicam diretamente com o sistema externo para
-trazer o *estado atual* mais próximo do desejado.
+(Existe na verdade um [controlador](https://github.com/kubernetes/autoscaler/)
+que escala horizontalmente os nodes no seu cluster.)
 
-(Existe um controlador que escala horizontalmente nós no seu *cluster*.
-Veja [Escalamento automático do cluster](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling))
+O ponto importante aqui é que o controlador faz algumas mudanças para trazer
+seu estado desejado, e então relata o estado atual de volta ao servidor de API do seu cluster.
+Outros ciclos de controle podem observar esses dados relatados e tomar suas próprias ações.
+
+No exemplo do termostato, se a sala estiver muito fria, então um controlador diferente
+pode também ligar um aquecedor de proteção contra geada. Com clusters Kubernetes, o control plane
+indiretamente trabalha com ferramentas de gerenciamento de endereços IP, serviços de armazenamento,
+APIs de provedores de nuvem, e outros serviços através de
+[estender o Kubernetes](/docs/concepts/extend-kubernetes/) para implementar isso.
 
 ## Estado desejado versus atual {#desired-vs-current}
 
-Kubernetes tem uma visão *cloud-native* de sistemas e é capaz de manipular
+O Kubernetes tem uma visão cloud-native de sistemas, e é capaz de lidar com
 mudanças constantes.
 
-O seu *cluster* pode mudar em qualquer momento à medida que as ações acontecem e
-os ciclos de controle corrigem falhas automaticamente. Isto significa que,
-potencialmente, o seu *cluster* nunca atinge um estado estável.
+Seu cluster pode estar mudando a qualquer momento conforme o trabalho acontece e
+ciclos de controle corrigem falhas automaticamente. Isso significa que,
+potencialmente, seu cluster nunca atinge um estado estável.
 
-Enquanto os controladores no seu *cluster* estiverem rodando e forem capazes de
-fazer alterações úteis, não importa se o estado é estável ou se é instável.
+Enquanto os controladores do seu cluster estiverem executando e forem capazes de fazer
+mudanças úteis, não importa se o estado geral é estável ou não.
 
 ## Design
 
-Como um princípio do seu desenho, o Kubernetes usa muitos controladores onde cada
-um gerencia um aspecto particular do estado do *cluster*. Comumente, um particular
-ciclo de controle (controlador) usa uma espécie de recurso como o seu *estado desejado*,
-e tem uma espécie diferente de recurso que o mesmo gere para garantir que esse *estado desejado*
-é cumprido.
+Como um princípio do seu design, o Kubernetes usa muitos controladores que cada um gerencia
+um aspecto particular do estado do cluster. Mais comumente, um ciclo de controle particular
+(controlador) usa um tipo de recurso como seu estado desejado, e tem um tipo diferente
+de recurso que ele gerencia para fazer esse estado desejado acontecer. Por exemplo,
+um controlador para Jobs rastreia objetos Job (para descobrir novo trabalho) e objetos Pod
+(para executar os Jobs, e então ver quando o trabalho termina). Neste caso
+algo mais cria os Jobs, enquanto o controlador Job cria Pods.
 
-É útil que haja controladores simples em vez de um conjunto monolítico de ciclos de controle
-que estão interligados. Controladores podem falhar, então o Kubernetes foi desenhado para
+É útil ter controladores simples em vez de um conjunto monolítico de ciclos de controle
+que estão interligados. Controladores podem falhar, então o Kubernetes foi projetado para
 permitir isso.
 
-Por exemplo: um controlador de *Jobs* rastreia objetos *Job* (para
-descobrir novos trabalhos) e objetos *Pod* (para correr o *Jobs*, e então
-ver quando o trabalho termina). Neste caso outra coisa cria os *Jobs*,
-enquanto o controlador *Job* cria *Pods*.
-
 {{< note >}}
-Podem existir vários controladores que criam ou atualizam a mesma espécie (kind) de objeto.
-Atrás das cortinas, os controladores do Kubernetes garantem que eles apenas tomam
-atenção aos recursos ligados aos seus recursos controladores.
+Pode haver vários controladores que criam ou atualizam o mesmo tipo de objeto.
+Nos bastidores, os controladores do Kubernetes garantem que eles apenas prestam atenção
+aos recursos ligados ao seu recurso controlador.
 
-Por exemplo, você pode ter *Deployments* e *Jobs*; ambos criam *Pods*.
-O controlador de *Job* não apaga os *Pods* que o seu *Deployment* criou,
+Por exemplo, você pode ter Deployments e Jobs; ambos criam Pods.
+O controlador Job não exclui os Pods que seu Deployment criou,
 porque existe informação ({{< glossary_tooltip term_id="label" text="labels" >}})
-que os controladores podem usar para diferenciar esses *Pods*.
+que os controladores podem usar para diferenciar esses Pods.
 {{< /note >}}
 
-## Formas de rodar controladores {#running-controllers}
+## Formas de executar controladores {#running-controllers}
 
-O Kubernetes vem com um conjunto de controladores embutidos que correm
-dentro do {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-Estes controladores embutidos providenciam comportamentos centrais importantes.
+O Kubernetes vem com um conjunto de controladores embutidos que executam dentro do
+{{< glossary_tooltip term_id="kube-controller-manager" >}}. Estes
+controladores embutidos fornecem comportamentos centrais importantes.
 
-O controlador *Deployment* e o controlador *Job* são exemplos de controladores
-que veem como parte do próprio Kubernetes (controladores "embutidos").
-O Kubernetes deixa você correr o plano de controle resiliente, para que se qualquer
-um dos controladores embutidos falhar, outra parte do plano de controle assume
-o trabalho.
+O controlador Deployment e o controlador Job são exemplos de controladores que
+vêm como parte do próprio Kubernetes (controladores "embutidos").
+O Kubernetes permite que você execute um control plane resiliente, para que se qualquer
+um dos controladores embutidos falhar, outra parte do control plane assumirá o trabalho.
 
-Pode encontrar controladores fora do plano de controle, para extender o Kubernetes.
+Você pode encontrar controladores que executam fora do control plane, para estender o Kubernetes.
 Ou, se quiser, pode escrever um novo controlador você mesmo.
-Pode correr o seu próprio controlador como um conjunto de *Pods*,
-ou externo ao Kubernetes. O que encaixa melhor vai depender no que esse
-controlador faz em particular.
-
-
+Você pode executar seu próprio controlador como um conjunto de Pods,
+ou externamente ao Kubernetes. O que se encaixa melhor dependerá do que esse
+controlador particular faz.
 
 ## {{% heading "whatsnext" %}}
 
-* Leia mais sobre o [plano de controle do Kubernetes](/docs/concepts/#kubernetes-control-plane)
-* Descubra alguns dos [objetos Kubernetes](/docs/concepts/#kubernetes-objects) básicos.
-* Aprenda mais sobre [API do Kubernetes](/docs/concepts/overview/kubernetes-api/)
-* Se pretender escrever o seu próprio controlador, veja [Padrões de Extensão](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)
-
+- Leia sobre o [control plane do Kubernetes](/docs/concepts/architecture/#control-plane-components)
+- Descubra alguns dos [objetos Kubernetes](/docs/concepts/overview/working-with-objects/) básicos
+- Saiba mais sobre a [API do Kubernetes](/docs/concepts/overview/kubernetes-api/)
+- Se quiser escrever seu próprio controlador, veja
+  [padrões de extensão do Kubernetes](/docs/concepts/extend-kubernetes/#extension-patterns)
+  e o repositório [sample-controller](https://github.com/kubernetes/sample-controller)