--- title: Controladores content_type: concept 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. 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">}} ## Padrão Controlador (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* 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*. 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. ### 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 é 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), 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. 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). ### Controle direto Em contraste com *Job*, alguns controladores necessitam de efetuar mudanças fora do *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. 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 tem uma visão *cloud-native* de sistemas e é capaz de manipular 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. 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. ## 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. É ú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 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 rodar 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 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. Pode encontrar controladores fora do plano de controle, 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. ## {{% 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)