Add docs/concepts/architecture/controller.md in portuguese

Author: cloud-j-luna

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

@@ -0,0 +1,162 @@
+---
+title: Controladores
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+Em robótica e automação, um _control loop_ ou em português _ciclo de controlo_ é
+um ciclo não terminado que regula o estado de um sistema.
+
+Um exemplo de um ciclo de controlo é um termostato de 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
+mais perto do estado desejado, ligando ou desligando o equipamento.
+
+{{< glossary_definition term_id="controller" length="short">}}
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Padrão de controlo (Controller pattern)
+
+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* (especificação) que representa o *estado desejado*.
+Os controladores para esse recurso são responsáveis por trazer o *estado atual*
+mais perto do *estado desejado*.
+
+O controlador pode levar ele proprio a cabo a ação; é mais comum, no Kubernetes,
+um controlador enviar uma mensagem para o
+{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} que tem
+efeitos colaterais uteis. Você vai ver exemplos disto abaixo.
+
+{{< comment >}}
+Alguns controladores embutidos, como é o caso do controlador *namespace*, atuam em objetos
+que não têm uma especificação (*spec*). Por questões de simplicidade, esta página omite explicar
+esse detalhe.
+{{< /comment >}}
+
+### Controlador via API server
+
+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 corre 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 objects become part of the
+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 numero
+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" >}})
+atuem 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*: creando *Pods* que fazem o trabalho desejado para esse *Job* para que
+o *Job* fique mais perto de ser completado.
+
+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).
+
+(Isto é um pouco como alguns termostatos desligam uma luz para
+indicar que a temperatura da sala está agora na temperatura que foi introduzida).
+
+### Controlo direto
+
+Em contraste com *Job*, alguns controladores necessitam de efetuar
+mudanças a coisas fora do *cluster*.
+
+Por exemplo, se usar um ciclo de controlo 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 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 um controlador que escala horizontalmente nós no seu *cluster*.
+Veja [Escalamento automático do cluster](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling))
+
+## Estado desejado versus atual {#desired-vs-current}
+
+Kubernetes leva uma visão *cloud-native* de sistemas, e é capaz de manipular
+mudanças constantes.
+
+O seu *cluster* pode mudar em qualquer altura à medida que o trabalho acontece e
+os ciclos de controlo corrigem falhas automaticamente. Isto significa que,
+potencialmente, o seu *cluster* nunca atinge um estado estável.
+
+Enquanto os controladores no seu *cluster* estiverem a correr e forem capazes de
+fazer alterações uteis, não importa se o estado é estável ou se é instável.
+
+## Desenho
+
+Como um principio do seu desenho, o Kubernetes usa muitos controladores onde cada
+um gere um aspeto particular do estado do *cluster*. Maioritariamente, um particular
+ciclo de controlo (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.
+
+É util que haja controladores simples em vez de um conjunto monolítico de ciclos de controlo
+que estão interligados. Controladores podem falhar, então o Kubernetes foi desenhado 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.
+
+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,
+porque existe informação ({{< glossary_tooltip term_id="label" text="labels" >}})
+que os controladores podem usar para diferenciar esses *Pods*.
+{{< /note >}}
+
+## Formas de correr 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 controlador *Deployment* e o controlador *Job* são exemplods de controladores
+que veem como parte do próprio Kubernetes (controladores "embutidos").
+O Kubernetes deixa voce correr o plano de controlo resiliente, para que se qualquer
+um dos controladores embutidos falhar, outra parte do plano de controlo assume
+o trabalho.
+
+Pode encontrar controladores fora do plano de controlo, para extender 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.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+* Leia mais sobre o [plano de controlo 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)
+{{% /capture %}}