PT-BR localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files

Author: andreygoran

content/pt-br/docs/concepts/cluster-administration/flow-control.md

@@ -394,7 +394,7 @@ você pode configurar regras para bloquear qualquer solicitação de verificaç
 que se originam de fora do seu cluster.
 {{< /caution >}}
 
-{{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}}
+{{% codenew file="priority-and-fairness/health-for-strangers.yaml" %}}
 
 ## Diagnóstico
 

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

@@ -20,7 +20,7 @@ As arquiteturas de log no nível de cluster são descritas no pressuposto de que
 
 Nesta seção, você pode ver um exemplo de log básico no Kubernetes que gera dados para o fluxo de saída padrão(standard output stream). Esta demostração usa uma [especificação de pod](/examples/debug/counter-pod.yaml) com um contêiner que grava algum texto na saída padrão uma vez por segundo.
 
-{{< codenew file="debug/counter-pod.yaml" >}}
+{{% codenew file="debug/counter-pod.yaml" %}}
 
 Para executar este pod, use o seguinte comando:
 
@@ -128,13 +128,13 @@ Essa abordagem permite separar vários fluxos de logs de diferentes partes do se
 
 Considere o seguinte exemplo. Um pod executa um único contêiner e grava em dois arquivos de log diferentes, usando dois formatos diferentes. Aqui está um arquivo de configuração para o Pod:
 
-{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod.yaml" %}}
 
 Seria uma bagunça ter entradas de log de diferentes formatos no mesmo fluxo de logs, mesmo se você conseguisse redirecionar os dois componentes para o fluxo `stdout` do contêiner. Em vez disso, você pode introduzir dois contêineres sidecar. Cada contêiner sidecar pode direcionar um arquivo de log específico de um volume compartilhado e depois redirecionar os logs para seu próprio fluxo `stdout`.
 
 Aqui está um arquivo de configuração para um pod que possui dois contêineres sidecar:
 
-{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
 
 Agora, quando você executa este pod, é possível acessar cada fluxo de log separadamente, executando os seguintes comandos:
 
@@ -179,7 +179,7 @@ O uso de um agente de log em um contêiner sidecar pode levar a um consumo signi
 
 Como exemplo, você pode usar o [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/), que usa fluentd como um agente de log. Aqui estão dois arquivos de configuração que você pode usar para implementar essa abordagem. O primeiro arquivo contém um [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) para configurar o fluentd.
 
-{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
+{{% codenew file="admin/logging/fluentd-sidecar-config.yaml" %}}
 
 {{< note >}}
 A configuração do fluentd está além do escopo deste artigo. Para obter informações sobre como configurar o fluentd, consulte a [documentação oficial do fluentd](http://docs.fluentd.org/).
@@ -188,7 +188,7 @@ A configuração do fluentd está além do escopo deste artigo. Para obter infor
 O segundo arquivo descreve um pod que possui um contêiner sidecar rodando fluentemente.
 O pod monta um volume onde o fluentd pode coletar seus dados de configuração.
 
-{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
 
 Depois de algum tempo, você pode encontrar mensagens de log na interface do Stackdriver.
 

content/pt-br/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -38,7 +38,7 @@ Quando se cria um objeto do Kubernetes, deve-se fornecer a especificação do ob
 
 Aqui está um exemplo de arquivo `.yaml` que mostra os campos necessários e as especificações de objeto para uma implatação Kubernetes:
 
-{{< codenew file="application/deployment.yaml" >}}
+{{% codenew file="application/deployment.yaml" %}}
 
 Uma maneira de criar um Deployment usando um arquivo `.yaml` como o representado acima é usar o comando [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply
 ) na interface de linha de comando `kubectl`, passando o arquivo `.yaml` como argumento. Aqui está um exemplo:

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

@@ -623,7 +623,7 @@ plugins:
 
 Em seguida, crie um objeto de cota de recurso no _namespace_ `kube-system`:
 
-{{< codenew file="policy/priority-class-resourcequota.yaml" >}}
+{{% codenew file="policy/priority-class-resourcequota.yaml" %}}
 
 ```shell
 kubectl apply -f http://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system

content/pt-br/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -52,7 +52,7 @@ tolerations:
 
 Aqui está um exemplo de um pod que utiliza tolerâncias:
 
-{{< codenew file="pods/pod-with-toleration.yaml" >}}
+{{% codenew file="pods/pod-with-toleration.yaml" %}}
 
 O valor padrão de `operator` é `Equal`.
 

content/pt-br/docs/concepts/services-networking/ingress.md

@@ -59,7 +59,7 @@ Certifique-se de revisar a documentação do seu controlador Ingress para entend
 
 Um exemplo mínimo do recurso Ingress:
 
-{{< codenew file="service/networking/minimal-ingress.yaml" >}}
+{{% codenew file="service/networking/minimal-ingress.yaml" %}}
 
 Um Ingress precisa dos campos `apiVersion`, `kind`, `metadata` e `spec`. 
 O nome de um objeto Ingress deve ser um nome de [subdomínio DNS válido](/pt-br/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). 
@@ -105,7 +105,7 @@ Um `Resource` backend é um ObjectRef para outro recurso Kubernetes dentro do me
 Um `Resource` é uma configuração mutuamente exclusiva com o serviço, e a validação irá falhar se ambos forem especificados. 
 Um uso comum para um `Resource` backend é inserir dados em um backend de armazenamento de objetos com ativos estáticos.
 
-{{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
+{{% codenew file="service/networking/ingress-resource-backend.yaml" %}}
 
 Depois de criar o Ingress acima, você pode visualizá-lo com o seguinte comando:
 
@@ -181,14 +181,14 @@ As correspondências curinga exigem que o cabeçalho do `host` HTTP seja igual a
 | `*.foo.com` | `baz.bar.foo.com` | Sem correspondência, o curinga cobre apenas um único rótulo DNS |
 | `*.foo.com` | `foo.com`         | Sem correspondência, o curinga cobre apenas um único rótulo DNS |
 
-{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}}
+{{% codenew file="service/networking/ingress-wildcard-host.yaml" %}}
 
 ## Classe Ingress
 
 Os Ingress podem ser implementados por diferentes controladores, muitas vezes com diferentes configurações. 
 Cada Ingress deve especificar uma classe, uma referência a um recurso IngressClass que contém uma configuração adicional, incluindo o nome do controlador que deve implementar a classe.
 
-{{< codenew file="service/networking/external-lb.yaml" >}}
+{{% codenew file="service/networking/external-lb.yaml" %}}
 
 O campo `.spec.parameters` de uma classe Ingress permite que você faça referência a outro recurso que fornece a configuração relacionada a essa classe Ingress.
 
@@ -285,7 +285,7 @@ Existem alguns controladores Ingress que funcionam sem a definição de uma `Ing
 Por exemplo, o controlador Ingress-NGINX pode ser configurado com uma [flag](http://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class) `--watch-ingress-without-class`. 
 No entanto, é [recomendável](http://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) especificar a `IngressClass` padrão:
 
-{{< codenew file="service/networking/default-ingressclass.yaml" >}}
+{{% codenew file="service/networking/default-ingressclass.yaml" %}}
 
 ## Tipos de Ingress
 
@@ -294,7 +294,7 @@ No entanto, é [recomendável](http://kubernetes.github.io/ingress-nginx/#i-hav
 No Kubernetes existem conceitos que permitem expor um único serviço (veja [alternativas](#alternatives)). 
 Você também pode fazer isso com um Ingress especificando um *backend padrão* sem regras.
 
-{{< codenew file="service/networking/test-ingress.yaml" >}}
+{{% codenew file="service/networking/test-ingress.yaml" %}}
 
 Se você criá-lo usando `kubectl apply -f`, você deve ser capaz de visualizar o estado do Ingress que você adicionou:
 
@@ -324,7 +324,7 @@ Por exemplo, uma configuração como:
 
 exigiria um Ingress como:
 
-{{< codenew file="service/networking/simple-fanout-example.yaml" >}}
+{{% codenew file="service/networking/simple-fanout-example.yaml" %}}
 
 Quando você cria o Ingress com `kubectl apply -f`:
 
@@ -364,13 +364,13 @@ Os hosts virtuais baseados em nomes suportam o roteamento de tráfego HTTP para
 
 O Ingress a seguir diz ao balanceador de carga de apoio para rotear solicitações com base no [Host header](http://tools.ietf.org/html/rfc7230#section-5.4).
 
-{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
+{{% codenew file="service/networking/name-virtual-host-ingress.yaml" %}}
 
 Se você criar um recurso de Ingress sem nenhum host definido nas regras, qualquer tráfego da web para o endereço IP do seu controlador de Ingress pode ser correspondido sem que seja necessário um host virtual baseado em nome.
 
 Por exemplo, o Ingress a seguir roteia o tráfego solicitado para `first.bar.com` para `service1`, `second.bar.com` para `service2` e qualquer tráfego cujo cabeçalho de host de solicitação não corresponda a `first.bar.com` e `second.bar.com` para `service3`.
 
-{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
+{{% codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" %}}
 
 ### TLS
 
@@ -402,7 +402,7 @@ Tenha em mente que o TLS não funcionará na regra padrão porque os certificado
 Portanto, os hosts na seção `tls` precisam corresponder explicitamente ao `host` na seção `rules`.
 {{< /note >}}
 
-{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
+{{% codenew file="service/networking/tls-example-ingress.yaml" %}}
 
 {{< note >}}
 Há uma lacuna entre os recursos TLS suportados por vários controladores Ingress. 

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

@@ -220,7 +220,7 @@ comportamento padrão nesse namespace.
 Você pode criar uma política padrão de isolamento para um namespace criando um objeto `NetworkPolicy` 
 que seleciona todos os pods mas não permite o tráfego de entrada para esses pods.
 
-{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
+{{% codenew file="service/networking/network-policy-default-deny-ingress.yaml" %}}
 
 Isso garante que mesmo pods que não são selecionados por nenhuma outra política de rede ainda 
 serão isolados. Essa política não muda o comportamento padrão de isolamento de tráfego de saída 
@@ -232,15 +232,15 @@ Se você deseja permitir todo o tráfego de todos os pods em um namespace (mesmo
 sejam adicionadas faça com que alguns pods sejam tratados como "isolados"), você pode criar 
 uma política que permite explicitamente todo o tráfego naquele namespace.
 
-{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
+{{% codenew file="service/networking/network-policy-allow-all-ingress.yaml" %}}
 
 ### Bloqueio padrão de todo tráfego de saída
 
 Você pode criar uma política de isolamento de saída padrão para um namespace criando uma 
 política de redes que selecione todos os pods, mas não permita o tráfego de saída a partir 
 de nenhum desses pods.
 
-{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
+{{% codenew file="service/networking/network-policy-default-deny-egress.yaml" %}}
 
 Isso garante que mesmo pods que não são selecionados por outra política de rede não seja permitido 
 tráfego de saída. Essa política não muda o comportamento padrão de tráfego de entrada.
@@ -251,14 +251,14 @@ Caso você queira permitir todo o tráfego de todos os pods em um namespace (mes
 adicionadas e cause com que alguns pods sejam tratados como "isolados"), você pode criar uma 
 política explicita que permite todo o tráfego de saída no namespace.
 
-{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
+{{% codenew file="service/networking/network-policy-allow-all-egress.yaml" %}}
 
 ### Bloqueio padrão de todo tráfego de entrada e saída
 
 Você pode criar uma política padrão em um namespace que previne todo o tráfego de entrada 
 E saída criando a política a seguir no namespace.
 
-{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
+{{% codenew file="service/networking/network-policy-default-deny-all.yaml" %}}
 
 Isso garante que mesmo pods que não são selecionados por nenhuma outra política de redes não 
 possuam permissão de tráfego de entrada ou saída.

content/pt-br/docs/concepts/workloads/controllers/cron-jobs.md

@@ -33,7 +33,7 @@ CronJobs são úteis para criar tarefas periódicas e recorrentes, como a execu
 
 Este manifesto de CronJob de exemplo imprime a data e horário atuais, seguidos da mensagem "Hello from the Kubernetes cluster", uma vez por minuto:
 
-{{< codenew file="application/job/cronjob.yaml" >}}
+{{% codenew file="application/job/cronjob.yaml" %}}
 
 (O artigo [Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/) demonstra este exemplo com maiores detalhes).
 

content/pt-br/docs/concepts/workloads/controllers/replicaset.md

@@ -28,7 +28,7 @@ prefira usar um Deployment, e defina sua aplicação na seção spec.
 
 ## Exemplo
 
-{{< codenew file="controllers/frontend.yaml" >}}
+{{% codenew file="controllers/frontend.yaml" %}}
 
 Salvando esse manifesto como `frontend.yaml` e submetendo no cluster Kubernetes irá criar o ReplicaSet definido e os Pods mantidos pelo mesmo.
 
@@ -135,7 +135,7 @@ Enquanto você pode criar Pods diretamente sem problemas, é fortemente recomend
 
 Observe o exemplo anterior do ReplicaSet frontend, e seus Pods especificados no seguinte manifesto:
 
-{{< codenew file="pods/pod-rs.yaml" >}}
+{{% 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 combinam com o seletor do ReplicaSet frontend, eles serão imediatamente adquiridos pelo ReplicaSet.
 
@@ -303,7 +303,7 @@ Um ReplicaSet pode também ser controlado por um
 [Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). Isto é,
 um ReplicaSet pode ser automaticamente escalonado por um HPA. Aqui está um exemplo de um HPA controlando o ReplicaSet que nós criamos no exemplo anterior.
 
-{{< codenew file="controllers/hpa-rs.yaml" >}}
+{{% 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 autoescalona o ReplicaSet controlado dependendo do uso de CPU 

content/pt-br/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md

@@ -23,7 +23,7 @@ Neste exercício, você cria um Pod que executa dois contêineres. Os dois cont
 compartilham um volume que eles podem usar para se comunicar. Aqui está o arquivo de configuração
 para o Pod:
 
-{{< codenew file="pods/two-container-pod.yaml" >}}
+{{% codenew file="pods/two-container-pod.yaml" %}}
 
 No arquivo de configuração, você pode ver que o Pod tem um shared-data chamado
 `shared-data`.

content/pt-br/docs/tasks/access-application-cluster/connecting-frontend-backend.md

@@ -27,7 +27,7 @@ Esta tarefa utiliza [Serviços com balanceadores de carga externos](/docs/tasks/
 ## Criando o backend usando um Deployment.
 
 O backend é um microserviço simples de saudação. Aqui está o arquivo de configuração para o Deployment do backend:
-{{< codenew file="service/access/backend-deployment.yaml" >}}
+{{% codenew file="service/access/backend-deployment.yaml" %}}
 
 Crie o `Deployment` do backend:
 
@@ -84,7 +84,7 @@ A chave para enviar solicitações do frontend para o backend é o `Service` do
 
 Primeiro, explore o arquivo de configuração do `Service`:
 
-{{< codenew file="service/access/backend-service.yaml" >}}
+{{% codenew file="service/access/backend-service.yaml" %}}
 
 No arquivo de configuração, você pode ver que o `Service`, chamado de `hello`, roteia o tráfego para Pods que possuem as labels `app: hello` e `tier: backend`.
 
@@ -104,13 +104,13 @@ O frontend envia solicitações para os worker Pods do backend usando o nome DNS
 
 Os Pods no Deployment do frontend executam uma imagem nginx que é configurada para fazer proxy de solicitações para o Serviço de backend `hello`. Aqui está o arquivo de configuração nginx:
 
-{{< codenew file="service/access/frontend-nginx.conf" >}}
+{{% codenew file="service/access/frontend-nginx.conf" %}}
 
 Similarmente ao backend, o frontend possui um `Deployment` e um `Service`. Uma diferença importante a ser notada entre os serviços de backend e frontend é que a configuração do serviço de frontend tem o parâmetro `type: LoadBalancer`, o que significa que o serviço usa um balanceador de carga fornecido pelo provedor de nuvem e será acessível de fora do cluster.
 
-{{< codenew file="service/access/frontend-service.yaml" >}}
+{{% codenew file="service/access/frontend-service.yaml" %}}
 
-{{< codenew file="service/access/frontend-deployment.yaml" >}}
+{{% codenew file="service/access/frontend-deployment.yaml" %}}
 
 Crie o `Deployment` e o `Service` para o frontend:
 

content/pt-br/docs/tasks/configure-pod-container/assign-pods-nodes.md

@@ -66,7 +66,7 @@ juntamente com seus rótulos:
 Este arquivo de configuração de pod descreve um pod que tem um seletor de nó, 
 `disktype: ssd`. Isto significa que o pod será agendado em um nó que tem o rótulo `disktype=ssd`.
 
-{{< codenew file="pods/pod-nginx.yaml" >}}
+{{% codenew file="pods/pod-nginx.yaml" %}}
 
 1. Use o arquivo de configuração para criar um pod que será agendado no nó escolhido:
 
@@ -91,7 +91,7 @@ Este arquivo de configuração de pod descreve um pod que tem um seletor de nó,
 
 Você pode também agendar um pod para um nó específico usando `nodeName`.
 
-{{< codenew file="pods/pod-nginx-specific-node.yaml" >}}
+{{% codenew file="pods/pod-nginx-specific-node.yaml" %}}
 
 Use o arquivo de configuração para criar um pod que será agendado somente no nó `foo-node`.
 

content/pt-br/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md

@@ -87,7 +87,7 @@ para incializar [provisionamento dinâmico](http://kubernetes.io/blog/2016/10/d
 
 Aqui está o arquivo de configuração para o Volume Persistente `hostPath`:
 
-{{< codenew file="pods/storage/pv-volume.yaml" >}}
+{{% codenew file="pods/storage/pv-volume.yaml" %}}
 
 O arquivo de configuração especifica que o volume está no diretório `/mnt/data` do nó do cluster. 
 A configuração também especifica um tamanho de 10 gibibytes e um modo de acesso 
@@ -123,7 +123,7 @@ gibibytes, com acesso de leitura-escrita para pelo menos um nó.
 
 Aqui está o arquivo de configuração para o`PersistentVolumeClaim`:
 
-{{< codenew file="pods/storage/pv-claim.yaml" >}}
+{{% codenew file="pods/storage/pv-claim.yaml" %}}
 
 Crie o `PersistentVolumeClaim`:
 
@@ -163,7 +163,7 @@ O próximo passo é criar um Pod que usa o seu `PersistentVolumeClaim` como um v
 
 Aqui está o arquivo de configuração para o Pod:
 
-{{< codenew file="pods/storage/pv-pod.yaml" >}}
+{{% codenew file="pods/storage/pv-pod.yaml" %}}
 
 Note que o arquivo de configuração do Pod especifica um `PersistentVolumeClaim`, mas não 
 especifica um Volume Persistente. Do ponto de vista do Pod, a reivindicação é de um volume.
@@ -231,7 +231,7 @@ Você pode agora fechar o shell do seu nó.
 
 ## Montando o mesmo Volume Persistente em dois lugares
 
-{{< codenew file="pods/storage/pv-duplicate.yaml" >}}
+{{% codenew file="pods/storage/pv-duplicate.yaml" %}}
 
 Você pode realizar a montagem de 2 volumes no seu contêiner nginx: