[pt-br] revision concepts/workloads/controllers/replicaset.md

jccpo · jccpo · commit 442e5582c95e · 2022-10-24T22:45:45.000+02:00
diff --git a/content/pt-br/docs/concepts/workloads/controllers/replicaset.md b/content/pt-br/docs/concepts/workloads/controllers/replicaset.md
@@ -15,13 +15,13 @@ O propósito de um ReplicaSet é gerenciar um conjunto de réplicas de Pods em e
 
 Um ReplicaSet é definido por campos, incluindo um seletor que identifica quais Pods podem ser adquiridos, um número de réplicas indicando quantos Pods devem ser mantidos, e um pod template especificando as definições para novos Pods que devem ser criados para atender ao número de réplicas estipuladas. Um ReplicaSet cumpre seu propósito criando e deletando Pods conforme for preciso para atingir o número desejado. Quando um ReplicaSet precisa criar novos Pods, ele usa o seu Pod template.
 
-Um ReplicaSet é conectado ao seus Pods pelo campo do Pod [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents), que especifíca qual recurso é dono do objeto atual. Todos os Pods adquiridos por um ReplicaSet possuem as informações de indetificação do ReplicaSet pai no campo ownerReferences. É por esse elo que o ReplicaSet tem conhecimento do estado dos Pods que está mantendo e assim planeja de acordo.
+Um ReplicaSet é conectado ao seus Pods pelo campo do Pod [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents), que especifíca qual recurso é dono do objeto atual. Todos os Pods adquiridos por um ReplicaSet possuem as informações de identificação do ReplicaSet vinculado no campo ownerReferences. É por esse elo que o ReplicaSet tem conhecimento do estado dos Pods que está mantendo e assim faz seu planejamento.
 
 Um ReplicaSet identifica novos Pods a serem adquiridos utilizando o seu seletor. Caso exista um Pod que não tenha OwnerReference ou se o OwnerReference não for um {{< glossary_tooltip term_id="controller" >}} e o seu seletor corresponde com o do ReplicaSet, o Pod é adquirido imediatamente por esse ReplicaSet.
 
 ## Quando usar um ReplicaSet
 
-Um ReplicaSet garante que um número de pod réplicas estão executando em qualquer momento. Entretanto, um Deployment é um conceito de nível superior que gerencia ReplicaSets e fornece atualizações declarativas aos Pods assim como várias outras funções úteis. Portanto, nós recomendamos a utilização de Deployments em oposição ao uso direto de ReplicaSets, exceto se for preciso uma orquestração de atualização customizada ou que nenhuma atualização seja necessária.
+Um ReplicaSet garante que um número de réplicas de um Pod estão executando em qualquer momento. Entretanto, um Deployment é um conceito de nível superior que gerencia ReplicaSets e fornece atualizações declarativas aos Pods assim como várias outras funções úteis. Portanto, nós recomendamos a utilização de Deployments ao invés do uso direto de ReplicaSets, exceto se for preciso uma orquestração de atualização customizada ou que nenhuma atualização seja necessária.
 
 Isso na realidade significa que você pode nunca precisar manipular objetos ReplicaSet:
 prefira usar um Deployment, e defina sua aplicação na seção spec.
@@ -30,32 +30,32 @@ prefira usar um Deployment, e defina sua aplicação na seção spec.
 
 {{< codenew file="controllers/frontend.yaml" >}}
 
-Salvando esse manifesto como `frontend.yaml` e submetendo no cluster Kubernetes irá criar a ReplicaSet definida e os Pods mantidos pela mesma.
+Salvando esse manifesto como `frontend.yaml` e submetendo no cluster Kubernetes irá criar o ReplicaSet definida e os Pods mantidos pela mesma.
 
 ```shell
 kubectl apply -f https://kubernetes.io/pt-br/examples/controllers/frontend.yaml
 ```
 
-Você pode então retornar as ReplicaSets implementadas atualmente no cluster:
+Você pode então retornar os ReplicaSets implementados atualmente no cluster:
 
 ```shell
 kubectl get rs
 ```
 
-E observar a frontend que você criou:
+E observar o ReplicaSet com o nome de frontend que você criou:
 
 ```shell
 NAME       DESIRED   CURRENT   READY   AGE
 frontend   3         3         3       6s
 ```
 
-Você também pode checar o estado da ReplicaSet:
+Você também pode checar o estado do ReplicaSet:
 
 ```shell
 kubectl describe rs/frontend
 ```
 
-E você deve ver um output similar a este:
+E você deve ver um saída similar a este:
 
 ```shell
 Name:         frontend
@@ -85,13 +85,13 @@ Events:
   Normal  SuccessfulCreate  116s  replicaset-controller  Created pod: frontend-vcmts
 ```
 
-E por fim você consegue verificar os Pods que foram levantados:
+E por fim você consegue verificar os Pods que foram criados:
 
 ```shell
 kubectl get pods
 ```
 
-Você deve receber uma informação do Pod similar à esta:
+Você deve ver uma informação do Pod similar à esta:
 
 ```shell
 NAME             READY   STATUS    RESTARTS   AGE
@@ -100,14 +100,14 @@ frontend-vcmts   1/1     Running   0          6m36s
 frontend-wtsmm   1/1     Running   0          6m36s
 ```
 
-Você consegue também validar que a referência de dono desses pods está definida para a ReplicaSet frontend.
+Você consegue também validar que a referência de dono desses pods está definida para o ReplicaSet frontend.
 Para fazer isso, retorne o yaml de um dos Pods que estão executando:
 
 ```shell
 kubectl get pods frontend-b2zdv -o yaml
 ```
 
-O output será parecido com algo assim, com as informações do ReplicaSet frontend definidas no campo ownerReferences dentro da metadata do Pod:
+O output será semelhante ao exibido abaixo, com as informações do ReplicaSet frontend definidas no campo ownerReferences dentro da metadata do Pod:
 
 ```shell
 apiVersion: v1
@@ -131,29 +131,29 @@ metadata:
 
 ## Aquisições de Pod sem Template
 
-Enquanto você pode criar Pods diretamente sem problemas, é fortemente recomendado que você se certifique que esses Pods não tenham labels que combinem com o seletor de um dos seus ReplicaSets. O motivo para isso é que um ReplicaSet não é limitado a possuir apenas Pods estipulados por seu template-- Ele pode adquirir outros Pods na maneira discriminada nas seções anteriores.
+Enquanto você pode criar Pods diretamente sem problemas, é fortemente recomendado que você se certifique que esses Pods não tenham labels que combinem com o seletor de um dos seus ReplicaSets. O motivo para isso é que um ReplicaSet não é limitado a possuir apenas Pods estipulados por seu template -- ele pode adquirir outros Pods na maneira descrita nas seções anteriores.
 
-Observe o último exemplo do ReplicaSet frontend, e seus Pods especificados no seguinte manifesto:
+Observe o exemplo anterior do ReplicaSet frontend, e seus Pods especificados no seguinte manifesto:
 
 {{< codenew file="pods/pod-rs.yaml" >}}
 
-Como esses Pods não possuem um Controller (ou qualquer objeto) referenciados como seu dono e possuem labels que casam com o seletor do ReplicaSet frontend, eles serão imediatamente adquiridos pelo ReplicaSet.
+Como esses Pods não possuem um Controller (ou qualquer objeto) referenciados como seu dono e possuem labels que combinam com o seletor do ReplicaSet frontend, eles serão imediatamente adquiridos pelo ReplicaSet.
 
-Imagine que você crie os Pods depois que o ReplicaSet frontend foi implantado e criou as réplicas de Pod inicial definida para cumprir o número de réplicas requiridas:
+Imagine que você crie os Pods depois que o ReplicaSet frontend foi implementado e criou as réplicas de Pod inicial definida para cumprir o número de réplicas requiridas:
 
 ```shell
 kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
 ```
 
-Os novos Pods serão adquiridos pela ReplicaSet, e logo depois terminados já que a ReplicaSet estará acima do número desejado.
+Os novos Pods serão adquiridos pelo ReplicaSet, e logo depois terminados já que a ReplicaSet estará acima do número desejado.
 
-Trazendo os Pods:
+Buscando os Pods:
 
 ```shell
 kubectl get pods
 ```
 
-O output mostra que os novos Pods ou já estão terminados, ou no processo de ser terminados.
+O output mostra que os novos Pods ou já estão terminados, ou estão no processo de ser terminados.
 
 ```shell
 NAME             READY   STATUS        RESTARTS   AGE
@@ -176,13 +176,13 @@ mas em seguida criar o ReplicaSet:
 kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```
 
-Você vai perceber que o ReplicaSet adquiriu os Pods e criou apenas novos de acordo com o seu spec até que o número de novo Pods e os Pods iniciais igualem ao número desejado. Trazendo os Pods:
+Você vai perceber que o ReplicaSet adquiriu os Pods e criou apenas novos de acordo com o seu spec até que o número de novo Pods e os Pods iniciais seja igual a ao número desejado. Listando os Pods:
 
 ```shell
 kubectl get pods
 ```
 
-Will reveal in its output:
+Irá retornar a seguinte saída:
 ```shell
 NAME             READY   STATUS    RESTARTS   AGE
 frontend-hmmj2   1/1     Running   0          9s
@@ -202,7 +202,7 @@ Um ReplicaSet também precisa de uma [seção `.spec`](https://git.k8s.io/commun
 
 ### Template de Pod
 
-O `.spec.template` é um [template de pod](/docs/concepts/workloads/pods/#pod-templates) que também necessita de labels configurados. No nosso exemplo `frontend.yaml` nós temos uma label: `tie: frontend`.
+O `.spec.template` é um [template de pod](/docs/concepts/workloads/pods/#pod-templates) que também necessita de labels configurados. No nosso exemplo `frontend.yaml` nós temos uma label: `tier: frontend`.
 Fique atento para não sobrepor com seletores de outros controllers, para que eles não tentem adquirir esse Pod.
 
 Para o campo de [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) do template, `.spec.template.spec.restartPolicy`, o único valor permitido é `Always`, que é o padrão.
@@ -216,7 +216,7 @@ matchLabels:
   tier: frontend
 ```
 
-No ReplicaSet, `.spec.template.metadata.labels` precisa casar com `spec.selector`, ou irá ser rejeitado pela API.
+No ReplicaSet, `.spec.template.metadata.labels` precisa combinar com `spec.selector`, ou será rejeitado pela API.
 
 {{< note >}}
 Para 2 ReplicaSets definindo o mesmo `.spec.selector` mas diferentes campos de `.spec.template.metadata.labels` e `.spec.template.spec`, cada ReplicaSet ignorará os Pods criados pelo outro ReplicaSet.
@@ -255,30 +255,30 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 > -H "Content-Type: application/json"
 ```
 
-Quando o original for deletado, você pode criar um novo ReplicaSet para substituí-lo. Contanto que o `.spec.selector` do velho e do novo sejam o mesmo, o novo irá adquirir os Pods antigos. Porém, o ReplicaSet não fará nenhum esforço nos Pods existentes para ajustá-los caso surja um novo e diferente template de pod.
-Para atualizar esses Pods para um novo spec de um modo controlado, use um [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), já que ReplicaSets não suportam um rolling update diretamente.
+Quando o ReplicaSet original for deletado, você pode criar um novo ReplicaSet para substituí-lo. Contanto que o `.spec.selector` do antigo e do atual sejam o mesmo, o novo irá adquirir os Pods antigos. Porém, o ReplicaSet não atualizará as definições dos Pods existentes caso surja um novo e diferente template de pod.
+Para atualizar esses Pods para um novo spec de um modo controlado, use um [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), já que ReplicaSets não suportam um atualização gradual diretamente.
 
 ### Isolando Pods de um ReplicaSet
 
-Você pode remover Pods de um Replicaset trocando suas labels. Essa técnica pode ser usada para remover Pods de um service para depuramento, recuperação de dados, etc. Pods que forem removidos por esse método serão substituídos imediatamente (assumindo que o número de replicas não tenha sido alterado).
+Você pode remover Pods de um Replicaset trocando suas labels. Essa técnica pode ser usada para remover Pods de um serviço para depuração, recuperação de dados, etc. Pods que forem removidos por esse método serão substituídos imediatamente (assumindo que o número de replicas não tenha sido alterado).
 
-### Escalando um ReplicaSet
+### Escalonando um ReplicaSet
 
-Um ReplicaSet pode ser facilmente escalado ou decaído simplismente atualizando o campo de `.spec.replicas`. O Replicaset controller garante que o número desejado de Pods com um seletor de label correspondente estejam disponíveis e operando.
+Um ReplicaSet pode ser facilmente escalonado para cima ou para baixo simplesmente atualizando o campo de `.spec.replicas`. O Replicaset controller garante que o número desejado de Pods com um seletor de label correspondente estejam disponíveis e operando.
 
-Ao escalar para baixo, o ReplicaSet controller escolhe quais pods irá deletar ordenando os pods disponíveis para priorizar quais pods seram decaídos seguindo o seguinte algoritmo geral:
- 1. Pods pending (e unschedulable) são decaídos primeiro
+Ao escalonar para baixo, o Replicaset controller escolhe quais pods irá deletar ordenando os pods disponíveis para priorizar quais pods seram escalonados para baixo seguindo o seguinte algoritmo geral:
+ 1. Pods pendentes (e não agendáveis) são decaídos primeiro
  2. Se a anotação `controller.kubernetes.io/pod-deletion-cost` estiver definida, então o pod com o menor valor será priorizado primeiro.
- 3. Pods em nodes com mais réplicas são decaídos primeiro que pods em nodes com menos réplicas.
- 4. Se a data de criação dos pods for diferente, o pod que foi criado mais recentemente vem antes que o pod mais antigo (as datas de criação são guardados em uma escala logaritmica caso o [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `LogarithmicScaleDown` esteja habilitado)
+ 3. Pods em nós com mais réplicas são decaídos primeiro que pods em nodes com menos réplicas.
+ 4. Se a data de criação dos pods for diferente, o pod que foi criado mais recentemente vem antes que o pod mais antigo (as datas de criação são guardados em uma escala logarítmica caso o [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `LogarithmicScaleDown` esteja habilitado)
 
-Se o Pod obdecer todos os items acima simultaneamente, a seleção é aleatória.
+Se o Pod obedecer todos os items acima simultaneamente, a seleção é aleatória.
 
 ### Custo de deleção de Pods
 {{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 Utilizando a anotação [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost),
-usuários podem definir uma preferência em relação à quais pods seram removidos primeiro caso o ReplicaSet precisa escalar para baixo.
+usuários podem definir uma preferência em relação à quais pods serão removidos primeiro caso o ReplicaSet precise escalar para baixo.
 
 A anotação deve ser definida no pod, com uma variação de [-2147483647, 2147483647]. Isso representa o custo de deletar um pod comparado com outros pods que pertencem à esse mesmo ReplicaSet. Pods com um custo de deleção menor são eleitos para deleção antes de pods com um custo maior.
 
@@ -295,7 +295,7 @@ Esse recurso está em beta e é habilitado por padrão. Você consegue desabilit
 {{< /note >}}
 
 #### Exemplo de caso de uso
-Os diferentes pods de uma aplicação podem ter níves de utilização divergentes. Ao escalar para baixo, a aplicação pode prefirir remover os pods com a menor utilização. Para evitar atualizações frequentes nos pods, a aplicação deve atualizar `controller.kubernetes.io/pod-deletion-cost` uma vez antes de expedir o decaimento das réplicas (configurando a anotação para um valor proporcional ao nível de utilização do pod). Isso funciona se a própria aplicação controlar a escala para baixo; por exemplo, o pod condutor de um deployment de Spark.
+Os diferentes pods de uma aplicação podem ter níves de utilização divergentes. Ao escalar para baixo, a aplicação pode preferir remover os pods com a menor utilização. Para evitar atualizações frequentes nos pods, a aplicação deve atualizar `controller.kubernetes.io/pod-deletion-cost` uma vez antes de expedir o decaimento das réplicas (configurando a anotação para um valor proporcional ao nível de utilização do pod). Isso funciona se a própria aplicação controlar a escala para baixo; por exemplo, o pod condutor de um deployment de Spark.
 
 ### ReplicaSet como um Horizontal Pod Autoscaler Target
 
@@ -306,7 +306,7 @@ um ReplicaSet pode ser automaticamente escalado por um HPA. Aqui está um exempl
 {{< codenew file="controllers/hpa-rs.yaml" >}}
 
 Salvando esse manifesto como `hpa-rs.yaml` e enviando para o cluster Kubernetes deve 
-criar um HPA definido que autoescala o ReplicaSet controlado dependendo no uso de CPU 
+criar um HPA definido que autoescala o ReplicaSet controlado dependendo do uso de CPU 
 dos Pods replicados.
 
 ```shell
@@ -331,7 +331,7 @@ Por isso, é recomendado o uso de Deployments quando você deseja ReplicaSets.
 
 ### Bare Pods
 
-Diferente do caso onde um usuário cria Pods diretamente, um ReplicaSet substitui Pods que forem deletados ou terminados por qualquer motivo, como em caso de falha de node ou manutenção disruptivo de node, como uma atualização de kernel. Por esse motivo, nós recomendamos que você use um ReplicaSet mesmo que sua aplicação necessite apenas de um único Pod. Pense na semelhança com um supervisor de processos, apenas que ele supervise vários Pods em múltiplos nodes ao invés de apenas um Pod. Um ReplicaSet delega reinicializações de um container local para algum agente do node (Kubelet ou Docker, por exemplo).
+Diferente do caso onde um usuário cria Pods diretamente, um ReplicaSet substitui Pods que forem deletados ou terminados por qualquer motivo, como em caso de falha de nó ou manutenção disruptivo de nó, como uma atualização de kernel. Por esse motivo, nós recomendamos que você use um ReplicaSet mesmo que sua aplicação necessite apenas de um único Pod. Pense na semelhança com um supervisor de processos, apenas que ele supervisione vários Pods em múltiplos nós ao invés de apenas um Pod. Um ReplicaSet delega reinicializações de um container local para algum agente do nó (Kubelet ou Docker, por exemplo).
 
 ### Job
 
@@ -345,7 +345,7 @@ os Pods precisam estar executando na máquina antes de outros Pods inicializarem
 ### ReplicationController
 ReplicaSets são sucessores ao [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/).
 Os dois servem para o mesmo propósito, e tem comportamentos semelhantes, exceto que um ReplicationController não suporta os requerimentos de um seletor baseado em definição como descrito no [guia de usuário de label](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
-Portantom, ReplicaSets são preferíveis à ReplicationControllers
+Portanto, ReplicaSets são preferíveis à ReplicationControllers
 
 
 ## {{% heading "whatsnext" %}}
