Changes from code review.

Author: MrErlison

content/pt-br/blog/_posts/2022-11-28-registry-k8s-io-change.md

@@ -1,6 +1,6 @@
 ---
 layout: blog
-title: "registry.k8s.io: rápido, barato e disponibilidade geral (GA)"
+title: "registry.k8s.io: rápido, barato e em disponibilidade geral (GA)"
 date: 2022-11-28
 slug: registry-k8s-io-faster-cheaper-ga
 ---
@@ -11,37 +11,37 @@ A partir do Kubernetes 1.25, o nosso repositório de imagens de contêiner mudou
 Este novo repositório distribui a carga por várias regiões e Provedores de Nuvem, funcionando como uma espécie de rede de entrega de conteúdo (CDN) para imagens de contêiner do Kubernetes. 
 Essa mudança reduz a dependência do projeto de uma única entidade e fornece uma experiência mais rápida de download para um grande número de usuários.
 
-## TL;DR: O que você precisa saber sobre essa mudança
+## Sumário: O que você precisa saber sobre essa mudança
 
 * As imagens de contêiner para versões do Kubernetes a partir de 1.25 não serão mais publicadas no k8s.gcr.io, apenas no registry.k8s.io
-* Em dezembro, nas próximas versões de patch, o novo padrão de domínio do registro será backported para todas as branches ainda com suporte (1.22, 1.23, 1.24).
-* Em um ambiente restrito, se você executar e aplicar as políticas de acesso aos endereços de domínio/IP limitados ao k8s.gcr.io, os _pulls de imagem não funcionarão_ após a migração para este novo repositório. Para esses usuários, o método recomendado é espelhar o lançamento das imagens em um repositório privado.
+* Em dezembro, nas próximas versões de patch, o novo padrão de domínio do registro será portado retroativamente para todas as branches ainda com suporte (1.22, 1.23, 1.24).
+* Em um ambiente restrito, se você aplicar rígidas políticas de acesso aos endereços de domínio/IP limitados ao k8s.gcr.io, os __as imagem não serão baixadas__ após a migração para este novo repositório. Para esses usuários, o método recomendado é espelhar o lançamento das imagens em um repositório privado.
 
 Se você quiser saber mais sobre o motivo que fizemos essa mudança, ou alguns dos possíveis problemas que você pode encontrar, continue lendo.
 
 ## Por que o Kubernetes mudou para um registro de imagens diferente?
 
-O K8s.gcr.io está hospedado em um domínio personalizado do [Google Container Registry](https://cloud.google.com/container-registry) (GCR) que foi configurado exclusivamente para o projeto Kubernetes. 
+O k8s.gcr.io está hospedado em um domínio personalizado do [Google Container Registry](https://cloud.google.com/container-registry) (GCR) que foi configurado exclusivamente para o projeto Kubernetes. 
 Isso funcionou bem desde o início do projeto, e agradecemos ao Google por fornecer esses recursos, mas hoje existem outros fornecedores e provedores de nuvem que gostariam de hospedar as imagens para fornecer uma melhor experiência para as pessoas em suas plataformas. 
 Além do compromisso renovado do Google de [doar US$ 3 milhões para apoiar](https://www.cncf.io/google-cloud-recommits-3m-to-kubernetes/) a infraestrutura do projeto, a Amazon anunciou uma doação correspondente durante sua palestra na Kubecon NA 2022 em Detroit. 
-Isso fornecerá uma melhor experiência para os usuários (servidores mais próximos = downloads mais rápidos) e reduzirá a largura de banda de saída e os custos do GCR ao mesmo tempo. O registry.k8s.io espalhará a carga entre o Google e a Amazon, e com outros provedores no futuro.
+Isso fornecerá uma melhor experiência para os usuários (servidores mais próximos = downloads mais rápidos) e reduzirá a largura de banda de saída e os custos do GCR ao mesmo tempo. O registry.k8s.io distribuirá a carga entre o Google e a Amazon, com outros provedores no futuro.
 
 ## Por que não há uma lista estável de domínios/IPs? Por que não posso restringir o pull de imagens?
 
 O registry.k8s.io é um [redirecionador seguro de blob](https://github.com/kubernetes/registry.k8s.io/blob/main/cmd/archeio/docs/request-handling.md) que conecta os clientes ao provedor de nuvem mais próximo. 
 A natureza dessa mudança significa que o pull de uma imagem cliente pode ser redirecionado para qualquer um dos vários backends. 
 Esperamos que o conjunto de backends continue mudando e aumente à medida que mais e mais provedores de nuvem e fornecedores se juntem para ajudar a espelhar as atualizações das imagens.
 
-Os mecanismos de controle mais restritos como proxies de main-in-the-middle ou as políticas de rede que restringem o acesso a uma lista específica de domínios/IPs, quebrarão com essa mudança. 
-Para esses cenários, encorajamos você a espelhar as atualizações das imagens em um repositório local sobre o qual você tem um controle rigoroso.
+Os mecanismos de controle mais restritos como proxies de man-in-the-middle ou  políticas de rede que restringem o acesso a uma lista específica de domínios/IPs quebrarão com essa mudança. 
+Para esses cenários, encorajamos você a espelhar as atualizações das imagens em um repositório local sobre o qual você tenha um controle rigoroso.
 
-Para mais informações sobre esta política, consulte a seção [estabilidade registry.k8s.io](https://github.com/kubernetes/registry.k8s.io#stability) na documentação.
+Para mais informações sobre esta política, consulte a [seção de estabilidade da documentação do registry.k8s.io](https://github.com/kubernetes/registry.k8s.io#stability).
 
 ## Que tipo de erros eu verei? Como saberei se ainda estou usando o endereço antigo?
 
-Os erros dependem do tipo de tempo da execução do contêiner que você está usando e para qual o endpoint você está roteado, mas ele deve se apresentar como um contêiner que não pode ser criado com o aviso `FailedCreatePodSandBox`.
+Os erros dependem do tipo do agente de execução de contêiner que você está usando e para qual o endpoint você está roteado, mas ele deve se apresentar como um contêiner que não pode ser criado com o aviso `FailedCreatePodSandBox`.
 
-Abaixo temos um exemplo da mensagem de erro mostrando uma falha na implantação do proxy que não pode ser feito o pull devido a um certificado desconhecido:
+Abaixo temos um exemplo de mensagem de erro mostrando uma implantação por proxy que não pode ser feito o pull devido a um certificado desconhecido:
 
 ```
 FailedCreatePodSandBox: Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Head “https://us-west1-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.8”: x509: certificate signed by unknown authority