From e37693785832747bb00f83f06f03d1e17bfa61e9 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Wed, 15 Jun 2022 10:36:48 -0300 Subject: [PATCH] Adjusting context, spelling and grammar --- content/pt-br/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/concepts/architecture/nodes.md b/content/pt-br/docs/concepts/architecture/nodes.md index 266815d8d4..b28544f40b 100644 --- a/content/pt-br/docs/concepts/architecture/nodes.md +++ b/content/pt-br/docs/concepts/architecture/nodes.md @@ -224,7 +224,7 @@ O comportamento de remoção do nó muda quando um nó em uma determinada zona d A razão pela qual essas políticas são implementadas por zona de disponibilidade é porque a camada de gerenciamento pode perder conexão com uma zona de disponibilidade, enquanto as outras permanecem conectadas. Se o seu cluster não abranger várias zonas de disponibilidade de provedores de nuvem, o mecanismo de remoção não levará em conta a indisponibilidade por zona. -Uma das principais razões para espalhar seus nós pelas zonas de disponibilidade é para que a carga de trabalho possa ser transferida para zonas íntegras quando uma zona inteira cair. Portanto, se todos os nós em uma zona não forem íntegros, o controlador do nó remova na taxa normal de `--node-eviction-rate`. O caso especial é quando todas as zonas são completamente insalubres (nenhum dos nós do cluster será íntegro). Nesse caso, o controlador do nó assume que há algum problema com a conectividade entre a camada de gerenciamento e os nós e não realiza nenhuma remoção. (Se houver uma interrupção e alguns nós reaparecerem, o controlador do nó expulsa pods dos nós restantes que são insalubres ou inacessíveis). +Uma das principais razões para espalhar seus nós pelas zonas de disponibilidade é para que a carga de trabalho possa ser transferida para zonas íntegras quando uma zona inteira cair. Portanto, se todos os nós em uma zona não estiverem íntegros, o controlador do nó removerá na taxa normal de `--node-eviction-rate`. O caso especial é quando todas as zonas estiverem completamente insalubres (nenhum dos nós do cluster será íntegro). Nesse caso, o controlador do nó assume que há algum problema com a conectividade entre a camada de gerenciamento e os nós e não realizará nenhuma remoção. (Se houver uma interrupção e alguns nós reaparecerem, o controlador do nó expulsará os pods dos nós restantes que estiverem insalubres ou inacessíveis). O controlador de nós também é responsável por remover pods em execução nos nós com `NoExecute` taints, a menos que esses pods tolerem essa taint. O controlador de nó também adiciona as {{< glossary_tooltip text="taints" term_id="taint" >}} correspondentes aos problemas de nó, como nó inacessível ou não pronto. Isso significa que o escalonador não colocará Pods em nós não íntegros.