Merge pull request #51721 from jhonmike/issue-51720
[pt-br] Update /content/pt-br/docs/concepts/architecture/controller.mdpull/51364/head^2
Kubernetes Prow Robot
GitHub
commit
4cd3c274fe
|
|
@ -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*.
|
||||
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 é executado em um
|
||||
*{{< glossary_tooltip term_id="pod" >}}*, ou talvez vários *Pods*, com o objetivo de
|
||||
executar uma tarefa e depois parar.
|
||||
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/), objetos *Pod* passam a fazer parte
|
||||
do *estado desejado* para um kubelet.
|
||||
(Uma vez [agendado](/docs/concepts/scheduling-eviction/), objetos Pod se tornam 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),
|
||||
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 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
(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))
|
||||
(Existe na verdade um [controlador](https://github.com/kubernetes/autoscaler/)
|
||||
que escala horizontalmente os nodes no seu cluster.)
|
||||
|
||||
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)
|
||||
|
|
|
|||
Loading…
Reference in New Issue