[pt-br] Standardize translation for container

Use the standardized term "contêiner" as translation for "container" and
its derived terms, and provide fix for the glossary entry for Docker.

Author: stormqueen1990

content/pt-br/README.md

@@ -15,7 +15,7 @@ Para usar este repositório, você precisa instalar:
 - [npm](https://www.npmjs.com/)
 - [Go](https://go.dev/)
 - [Hugo (versão Extended)](https://gohugo.io/)
-- Um container runtime, por exemplo [Docker](https://www.docker.com/).
+- Um agente de execução de contêiner, como por exemplo o [Docker](https://www.docker.com/).
 
 Antes de você iniciar, instale as dependências, clone o repositório e navegue até o diretório:
 
@@ -40,7 +40,7 @@ git submodule update --init --recursive --depth 1
 make module-init
 ```
 
-## Executando o website usando um container
+## Executando o website usando um contêiner
 
 Para executar o build do website em um contêiner, execute o comando abaixo:
 
@@ -93,7 +93,7 @@ curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi
 make api-reference
 ```
 
-Você pode validar o resultado localmente gerando e disponibilizando o site a partir da imagem do container:
+Você pode validar o resultado localmente gerando e disponibilizando o site a partir da imagem do contêiner:
 
 ```
 make container-image

content/pt-br/docs/concepts/architecture/_index.md

@@ -6,7 +6,7 @@ description: >
 ---
 
 Um cluster Kubernetes consiste em um control plane mais um conjunto de máquinas trabalhadoras, chamadas de nodes,
-que executam aplicações containerizadas. Todo cluster precisa de pelo menos um worker node para executar Pods.
+que executam aplicações conteinerizadas. Todo cluster precisa de pelo menos um worker node para executar Pods.
 
 Os worker nodes hospedam os Pods que são os componentes da carga de trabalho da aplicação.
 O control plane gerencia os worker nodes e os Pods no cluster. Em ambientes de produção,
@@ -37,7 +37,7 @@ bem como detectam e respondem a eventos do cluster (por exemplo, iniciar um novo
 `{{< glossary_tooltip text="replicas" term_id="replica" >}}` de um Deployment não está satisfeito).
 
 Os componentes do control plane podem ser executados em qualquer máquina do cluster. No entanto, para simplicidade, scripts de
-configuração normalmente iniciam todos os componentes do control plane na mesma máquina, e não executam containers de usuário nesta máquina.
+configuração normalmente iniciam todos os componentes do control plane na mesma máquina, e não executam contêineres de usuário nesta máquina.
 Consulte [Criando clusters altamente disponíveis com kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
 para um exemplo de configuração do control plane que executa em múltiplas máquinas.
 
@@ -102,7 +102,7 @@ Se você usar um [plugin de rede](#network-plugins) que implementa encaminhament
 por si só, e fornece comportamento equivalente ao kube-proxy, então você não precisa executar
 kube-proxy nos nodes do seu cluster.
 
-### Container runtime {#container-runtime}
+### Agente de execução de contêiner {#container-runtime}
 
 {{< glossary_definition term_id="container-runtime" length="all" >}}
 
@@ -124,28 +124,28 @@ Embora os outros addons não sejam estritamente necessários, todos os clusters
 DNS do cluster é um servidor DNS, além do(s) outro(s) servidor(es) DNS em seu ambiente,
 que serve registros DNS para services do Kubernetes.
 
-Containers iniciados pelo Kubernetes automaticamente incluem este servidor DNS em suas buscas DNS.
+Contêineres iniciados pelo Kubernetes automaticamente incluem este servidor DNS em suas buscas DNS.
 
 ### Web UI (Dashboard) {#web-ui-dashboard}
 
 [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) é uma UI baseada na web de propósito geral
 para clusters Kubernetes. Ela permite aos usuários gerenciar e solucionar problemas de aplicações
 executando no cluster, bem como o próprio cluster.
 
-### Monitoramento de recursos de container {#container-resource-monitoring}
+### Monitoramento de recursos de contêiner {#container-resource-monitoring}
 
-[Monitoramento de Recursos de Container](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
-grava métricas genéricas de séries temporais sobre containers em um banco de dados central, e fornece uma UI para navegar nesses dados.
+[Monitoramento de Recursos de Contêiner](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
+grava métricas genéricas de séries temporais sobre contêineres em um banco de dados central, e fornece uma UI para navegar nesses dados.
 
 ### Logging no nível do cluster {#cluster-level-logging}
 
 Um mecanismo de [logging no nível do cluster](/docs/concepts/cluster-administration/logging/) é responsável
-por salvar logs de containers em um armazenamento central de logs com uma interface de busca/navegação.
+por salvar logs de contêineres em um armazenamento central de logs com uma interface de busca/navegação.
 
 ### Plugins de rede {#network-plugins}
 
 [Plugins de rede](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins)
-são componentes de software que implementam a especificação da interface de rede de containers (CNI).
+são componentes de software que implementam a especificação da interface de rede de contêineres (CNI).
 Eles são responsáveis por alocar endereços IP para pods e permitir que eles se comuniquem
 uns com os outros dentro do cluster.
 
@@ -212,6 +212,6 @@ Saiba mais sobre o seguinte:
 - [Controllers](/docs/concepts/architecture/controller/) do Kubernetes.
 - [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) que é o scheduler padrão para o Kubernetes.
 - [Documentação](https://etcd.io/docs/) oficial do Etcd.
-- Vários [container runtimes](/docs/setup/production-environment/container-runtimes/) no Kubernetes.
+- Vários [agentes de execução de contêiner](/docs/setup/production-environment/container-runtimes/) no Kubernetes.
 - Integrando com provedores de nuvem usando [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/).
 - Comandos [kubectl](/docs/reference/generated/kubectl/kubectl-commands).

content/pt-br/docs/concepts/architecture/controller.md

@@ -55,7 +55,7 @@ estado desejado para um kubelet).
 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
+O controlador Job não executa nenhum Pod ou contêiner
 ele próprio. Em vez disso, o controlador Job informa o servidor de API para criar ou remover
 Pods.
 Outros componentes no

content/pt-br/docs/concepts/architecture/garbage-collection.md

@@ -12,7 +12,7 @@ permite a limpeza de recursos como os seguintes:
 - [Pods terminados](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
 - [Jobs completados](/docs/concepts/workloads/controllers/ttlafterfinished/)
 - [Objetos sem referências de proprietário](#owners-dependents)
-- [Containers e imagens de container não utilizados](#containers-images)
+- [Contêineres e imagens de contêiner não utilizados](#containers-images)
 - [PersistentVolumes provisionados dinamicamente com uma política de recuperação de StorageClass de Delete](/docs/concepts/storage/persistent-volumes/#delete)
 - [CertificateSigningRequests (CSRs) obsoletos ou expirados](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
 - {{<glossary_tooltip text="Nodes" term_id="node">}} excluídos nos seguintes cenários:
@@ -114,19 +114,19 @@ Quando o Kubernetes exclui um objeto proprietário, os dependentes deixados para
 de objetos _órfãos_. Por padrão, o Kubernetes exclui objetos dependentes. Para aprender como
 sobrescrever este comportamento, veja [Excluir objetos proprietários e tornar órfãos os dependentes](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
 
-## Coleta de lixo de containers e imagens não utilizados {#containers-images}
+## Coleta de lixo de contêineres e imagens não utilizados {#containers-images}
 
 O {{<glossary_tooltip text="kubelet" term_id="kubelet">}} executa coleta de lixo
-em imagens não utilizadas a cada cinco minutos e em containers não utilizados a cada
+em imagens não utilizadas a cada cinco minutos e em contêineres não utilizados a cada
 minuto. Você deve evitar usar ferramentas externas de coleta de lixo, pois estas podem
-quebrar o comportamento do kubelet e remover containers que deveriam existir.
+quebrar o comportamento do kubelet e remover contêineres que deveriam existir.
 
-Para configurar opções para coleta de lixo de containers e imagens não utilizados, ajuste o
+Para configurar opções para coleta de lixo de contêineres e imagens não utilizados, ajuste o
 kubelet usando um [arquivo de configuração](/docs/tasks/administer-cluster/kubelet-config-file/)
 e altere os parâmetros relacionados à coleta de lixo usando o
 tipo de recurso [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/).
 
-### Ciclo de vida da imagem de container
+### Ciclo de vida da imagem de contêiner
 
 O Kubernetes gerencia o ciclo de vida de todas as imagens através do seu _gerenciador de imagens_,
 que é parte do kubelet, com a cooperação do
@@ -141,7 +141,7 @@ que exclui imagens em ordem baseada na última vez que foram usadas,
 começando com a mais antiga primeiro. O kubelet exclui imagens
 até que o uso de disco atinja o valor `LowThresholdPercent`.
 
-#### Coleta de lixo para imagens de container não utilizadas {#image-maximum-age-gc}
+#### Coleta de lixo para imagens de contêiner não utilizadas {#image-maximum-age-gc}
 
 {{< feature-state feature_gate_name="ImageMaximumGCAge" >}}
 
@@ -165,32 +165,32 @@ duração `imageMaximumGCAge` antes de qualificar imagens para coleta de lixo
 baseada na idade da imagem.
 {{< /note>}}
 
-### Coleta de lixo de containers {#container-image-garbage-collection}
+### Coleta de lixo de contêineres {#container-image-garbage-collection}
 
-O kubelet coleta lixo de containers não utilizados baseado nas seguintes variáveis,
+O kubelet coleta lixo de contêineres não utilizados baseado nas seguintes variáveis,
 que você pode definir:
 
 - `MinAge`: a idade mínima na qual o kubelet pode coletar lixo de um
-  container. Desabilite definindo como `0`.
-- `MaxPerPodContainer`: o número máximo de containers mortos que cada Pod
+  contêiner. Desabilite definindo como `0`.
+- `MaxPerPodContainer`: o número máximo de contêineres mortos que cada Pod
   pode ter. Desabilite definindo como menor que `0`.
-- `MaxContainers`: o número máximo de containers mortos que o cluster pode ter.
+- `MaxContainers`: o número máximo de contêineres mortos que o cluster pode ter.
   Desabilite definindo como menor que `0`.
 
 Além dessas variáveis, o kubelet coleta lixo de containers não identificados e
 excluídos, tipicamente começando com o mais antigo primeiro.
 
 `MaxPerPodContainer` e `MaxContainers` podem potencialmente entrar em conflito um com o outro
-em situações onde manter o número máximo de containers por Pod
-(`MaxPerPodContainer`) iria além do total permitido de containers mortos globais
+em situações onde manter o número máximo de contêineres por Pod
+(`MaxPerPodContainer`) iria além do total permitido de contêineres mortos globais
 (`MaxContainers`). Nesta situação, o kubelet ajusta
 `MaxPerPodContainer` para resolver o conflito. Um cenário de pior caso seria
 rebaixar `MaxPerPodContainer` para `1` e despejar os containers mais antigos.
-Adicionalmente, containers pertencentes a Pods que foram excluídos são removidos uma vez
+Adicionalmente, contêineres pertencentes a Pods que foram excluídos são removidos uma vez
 que são mais antigos que `MinAge`.
 
 {{<note>}}
-O coletor de lixo do kubelet só remove containers que gerencia.
+O coletor de lixo do kubelet só remove contêineres que gerencia.
 {{</note>}}
 
 ## Configurando coleta de lixo {#configuring-gc}

content/pt-br/docs/concepts/cluster-administration/cluster-administration-overview.md

@@ -40,7 +40,7 @@ Nota: Nem todas as distros são ativamente mantidas. Escolha as distros que fora
 
 * [Certificados](/docs/concepts/cluster-administration/certificates/) descreve as etapas para gerar certificados usando diferentes ferramentas.
 
-* [Ambiente de Container Kubernetes](/docs/concepts/containers/container-environment-variables/) descreve o ambiente para contêineres gerenciados pelo Kubelet em um nó do Kubernetes.
+* [Ambiente de Contêiner Kubernetes](/docs/concepts/containers/container-environment-variables/) descreve o ambiente para contêineres gerenciados pelo Kubelet em um nó do Kubernetes.
 
 * [Controlando Acesso a API Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) descreve como configurar
 a permissão para usuários e contas de serviço.

content/pt-br/docs/concepts/cluster-administration/kubelet-garbage-collection.md

@@ -21,7 +21,7 @@ O Kubernetes gerencia o ciclo de vida de todas as imagens através do imageManag
 A política para o garbage collection de imagens leva dois fatores em consideração:
 `HighThresholdPercent` e `LowThresholdPercent`. Uso do disco acima do limite acionará o garbage collection. O garbage collection excluirá as imagens que foram menos usadas recentemente até que o nível fique abaixo do limite.
 
-## Coleta de container
+## Coleta de contêiner
 
 A política para o garbage collection de contêineres considera três variáveis definidas pelo usuário. `MinAge` é a idade mínima em que um contêiner pode ser coletado. `MaxPerPodContainer` é o número máximo de contêineres mortos que todo par de pod (UID, container name) pode ter. `MaxContainers` é o número máximo de contêineres mortos totais. Essas variáveis podem ser desabilitadas individualmente, definindo `MinAge` como zero e definindo `MaxPerPodContainer` e `MaxContainers` respectivamente para menor que zero.
 

content/pt-br/docs/concepts/cluster-administration/logging.md

@@ -84,7 +84,7 @@ Existem dois tipos de componentes do sistema: aqueles que são executados em um
 - O scheduler Kubernetes e o kube-proxy são executados em um contêiner.
 - O tempo de execução do kubelet e do contêiner, por exemplo, Docker, não é executado em contêineres.
 
-Nas máquinas com systemd, o tempo de execução do kubelet e do container é gravado no journald. Se systemd não estiver presente, eles gravam em arquivos `.log` no diretório `/var/log`.
+Nas máquinas com systemd, o tempo de execução do kubelet e do contêiner é gravado no journald. Se systemd não estiver presente, eles gravam em arquivos `.log` no diretório `/var/log`.
 Os componentes do sistema dentro dos contêineres sempre gravam no diretório `/var/log`, ignorando o mecanismo de log padrão. Eles usam a biblioteca de logs [klog][klog]. Você pode encontrar as convenções para a gravidade do log desses componentes nos [documentos de desenvolvimento sobre log](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
 
 Da mesma forma que os logs de contêiner, os logs de componentes do sistema no diretório `/var/log` devem ser rotacionados. Nos clusters do Kubernetes criados pelo script `kube-up.sh`, esses logs são configurados para serem rotacionados pela ferramenta `logrotate` diariamente ou quando o tamanho exceder 100MB.
@@ -115,12 +115,12 @@ O Kubernetes não especifica um agente de log, mas dois agentes de log opcionais
 
 Você pode usar um contêiner sidecar de uma das seguintes maneiras:
 
-- O container sidecar transmite os logs do aplicativo para seu próprio `stdout`.
-- O contêiner do sidecar executa um agente de log, configurado para selecionar logs de um contêiner de aplicativo.
+- O contêiner sidecar transmite os logs do aplicativo para seu próprio `stdout`.
+- O contêiner sidecar executa um agente de log, configurado para selecionar logs de um contêiner de aplicativo.
 
 #### Streaming sidecar conteiner
 
-![Conteiner sidecar com um streaming container](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png)
+![Contêiner sidecar com um contêiner de streaming](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png)
 
 Fazendo com que seus contêineres de sidecar fluam para seus próprios `stdout` e `stderr`, você pode tirar proveito do kubelet e do agente de log que já executam em cada nó. Os contêineres sidecar lêem logs de um arquivo, socket ou journald. Cada contêiner sidecar individual imprime o log em seu próprio `stdout` ou `stderr` stream.
 

content/pt-br/docs/concepts/configuration/secret.md

@@ -181,7 +181,7 @@ muitos Secrets. Escolha a opção que for mais conveniente para o caso de uso.
 
 Secrets podem ser montados como volumes de dados ou expostos como
 {{< glossary_tooltip text="variáveis de ambiente" term_id="container-env-variables" >}}
-para serem utilizados num container de um Pod. Secrets também podem ser
+para serem utilizados num contêiner de um Pod. Secrets também podem ser
 utilizados por outras partes do sistema, sem serem diretamente expostos ao Pod.
 Por exemplo, Secrets podem conter credenciais que outras partes do sistema devem
 utilizar para interagir com sistemas externos no lugar do usuário.

content/pt-br/docs/concepts/policy/resource-quotas.md

@@ -453,7 +453,7 @@ Esse recurso é beta e ativado por padrão. Você pode desativá-lo usando o [fe
 
 Ao alocar recursos computacionais, cada contêiner pode especificar uma solicitação e um valor limite para CPU ou memória. A cota pode ser configurada para cotar qualquer valor.
 
-Se a cota tiver um valor especificado para `requests.cpu` ou `requests.memory`, ela exigirá que cada container faça uma solicitação explícita para esses recursos. Se a cota tiver um valor especificado para `limits.cpu` ou `limits.memory`, em seguida exige que cada contêiner de entrada especifique um limite explícito para esses recursos.
+Se a cota tiver um valor especificado para `requests.cpu` ou `requests.memory`, ela exigirá que cada contêiner faça uma solicitação explícita para esses recursos. Se a cota tiver um valor especificado para `limits.cpu` ou `limits.memory`, em seguida exige que cada contêiner de entrada especifique um limite explícito para esses recursos.
 
 ## Como visualizar e definir cotas
 

content/pt-br/docs/concepts/services-networking/network-policies.md

@@ -101,7 +101,7 @@ solução de redes que suporte políticas de rede.
 __Campos obrigatórios__: Assim como todas as outras configurações do Kubernetes, uma `NetworkPolicy`
 necessita dos campos `apiVersion`, `kind` e `metadata`. Para maiores informações sobre 
 trabalhar com arquivos de configuração, veja 
-[Configurando containeres usando ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+[Configurando contêineres usando ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
 e [Gerenciamento de objetos](/docs/concepts/overview/working-with-objects/object-management).
 
 __spec__: A [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) contém todas as informações necessárias