RU localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files

Author: andreygoran

content/ru/docs/concepts/cluster-administration/flow-control.md

@@ -178,7 +178,7 @@ kube-apiserver поддерживает два вида объектов кон
 Добавление данной FlowSchema позволит злоумышленникам отправлять удовлетворяющие ей health-check-запросы в любом количестве. При наличии фильтра веб-трафика или аналогичного внешнего механизма безопасности для защиты API-сервера кластера от интернет-трафика можно настроить правила для блокировки любых health-check-запросов, поступающих из-за пределов кластера.
 {{< /caution >}}
 
-{{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}}
+{{% codenew file="priority-and-fairness/health-for-strangers.yaml" %}}
 
 ## Диагностика
 

content/ru/docs/concepts/cluster-administration/logging.md

@@ -23,7 +23,7 @@ weight: 60
 
 В примере ниже используется спецификация `Pod` с контейнером для отправки текста в стандартный поток вывода раз в секунду.
 
-{{< codenew file="debug/counter-pod.yaml" >}}
+{{% codenew file="debug/counter-pod.yaml" %}}
 
 Запустить его можно с помощью следующей команды:
 
@@ -132,13 +132,13 @@ Sidecar-контейнер можно использовать одним из 
 
 Предположим, к примеру, что в Pod'е работает один контейнер, который пишет логи в два разных файла в двух разных форматах. Вот пример конфигурации такого Pod'а:
 
-{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod.yaml" %}}
 
 Не рекомендуется писать логи разных форматов в один и тот же поток, даже если удалось перенаправить оба компонента в `stdout` контейнера. Вместо этого можно создать два sidecar-контейнера. Каждый из них будет забирать определенный лог-файл с общего тома и перенаправлять логи в свой `stdout`.
 
 Вот пример конфигурации Pod'а с двумя sidecar-контейнерами:
 
-{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
 
 Доступ к каждому потоку логов такого Pod'а можно получить отдельно, выполнив следующие команды:
 
@@ -186,15 +186,15 @@ Sidecar-контейнеры также можно использовать дл
 
 Ниже приведены два файла конфигурации sidecar-контейнера с лог-агентом. Первый содержит [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) для настройки fluentd.
 
-{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
+{{% codenew file="admin/logging/fluentd-sidecar-config.yaml" %}}
 
 {{< note >}}
 За информацией о настройке fluentd обратитесь к его [документации](https://docs.fluentd.org/).
 {{< /note >}}
 
 Второй файл описывает Pod с sidecar-контейнером, в котором работает fluentd. Pod монтирует том с конфигурацией fluentd.
 
-{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
 
 В приведенных выше примерах fluentd можно заменить на другой лог-агент, считывающий данные из любого источника в контейнере приложения.
 

content/ru/docs/concepts/cluster-administration/manage-deployment.md

@@ -15,7 +15,7 @@ weight: 40
 
 Многие приложения требуют создания нескольких ресурсов типа Deployment и Service. Управление ими можно упростить, сгруппировав в один YAML-файл (со строкой "---" в качестве разделителя). Например:
 
-{{< codenew file="application/nginx-app.yaml" >}}
+{{% codenew file="application/nginx-app.yaml" %}}
 
 Можно создавать сразу несколько ресурсов:
 

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

@@ -44,7 +44,7 @@ card:
 
 Ниже представлен пример `.yaml`-файла, в котором заданы обязательные поля и спецификация объекта, необходимая для объекта Deployment в Kubernetes:
 
-{{< codenew file="application/deployment.yaml" >}}
+{{% codenew file="application/deployment.yaml" %}}
 
 Один из способов создания объекта Deployment с помощью файла `.yaml`, показанного выше — использовать команду [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply), которая принимает в качестве аргумента файл в формате `.yaml`. Например:
 

content/ru/docs/contribute/style/write-new-topic.md

@@ -79,19 +79,15 @@ weight: 20
 При добавлении нового отдельного файла примера, например, в формате YAML, поместите код в одну из директорий `/examples/`, где `` — язык темы. В вашем файле темы используйте макрокод `codenew`:
 
 ```none
-{{</* codenew file="/my-example-yaml>" */>}}
+{{%/* codenew file="/my-example-yaml>" */%}}
 ```
 
 где `` — это путь к включаемому файлу относительно директории `examples`. Следующий макрокод Hugo ссылается на YAML-файл по пути `/content/en/examples/pods/storage/gce-volume.yaml`.
 
 ```none
-{{</* codenew file="pods/storage/gce-volume.yaml" */>}}
+{{%/* codenew file="pods/storage/gce-volume.yaml" */%}}
 ```
 
-{{< note >}}
-Чтобы отобразить Hugo-макрокоды в исходном виде, как в приведенном выше примере, поместите их в комментарии в стиле языка Си между `<` и `>`. Для примера посмотрите исходный код этой страницы.
-{{< /note >}}
-
 ## Демонстрация создания API-объекта из конфигурационного файла
 
 Если вам нужно показать, как создать объект API из файла конфигурации, поместите файл конфигурации в одну из директорий в `/examples`.

content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md

@@ -67,7 +67,7 @@ kubectl create namespace cpu-example
 В этом упражнении мы создадим Pod, имеющий один контейнер. Зададим для контейнера запрос в
 0.5 CPU и лимит в 1 CPU. Конфигурационный файл для такого Pod'а:
 
-{{< codenew file="pods/resource/cpu-request-limit.yaml" >}}
+{{% codenew file="pods/resource/cpu-request-limit.yaml" %}}
 
 Раздел `args` конфигурационного файла содержит аргументы для контейнера в момент старта.
 Аргумент `-cpus "2"` говорит контейнеру попытаться использовать 2 CPU.
@@ -160,7 +160,7 @@ CPU всегда запрашивается в абсолютных величи
 Ниже представлен конфигурационный файл для Pod'а с одним контейнером. Контейнер запрашивает 100 CPU,
 что почти наверняка превышает имеющиеся мощности любой ноды в кластере.
 
-{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}}
+{{% codenew file="pods/resource/cpu-request-limit-2.yaml" %}}
 
 Создадим Pod:
 

content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md

@@ -60,7 +60,7 @@ kubectl create namespace mem-example
 В этом упражнении создаётся Pod, содержащий один контейнер.
 Зададим контейнеру запрос памяти в 100 Мб и её ограничение в 200 Мб. Конфигурационный файл для Pod'а:
 
-{{< codenew file="pods/resource/memory-request-limit.yaml" >}}
+{{% codenew file="pods/resource/memory-request-limit.yaml" %}}
 
 Раздел `args` конфигурационного файла содержит аргументы для контейнера в момент старта.
 Аргументы `"--vm-bytes", "150M"` указывают контейнеру попытаться занять 150 Мб памяти.
@@ -129,7 +129,7 @@ kubectl delete pod memory-demo --namespace=mem-example
 Ниже представлен конфигурационный файл для Pod'a с одним контейнером, имеющим 50 Мб
 на запрос памяти и 100 Мб лимита памяти:
 
-{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
+{{% codenew file="pods/resource/memory-request-limit-2.yaml" %}}
 
 В разделе `args` можно увидеть, что контейнер будет пытаться занять
 250 Мб - и это значительно превышает лимит в 100 Мб.
@@ -239,7 +239,7 @@ kubectl delete pod memory-demo-2 --namespace=mem-example
 в кластере. Ниже представлен конфигурационный файл для Pod'a с одним контейнером,
 имеющим запрос памяти в 1000 Гб (что наверняка превышает ёмкость любой имеющейся ноды):
 
-{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
+{{% codenew file="pods/resource/memory-request-limit-3.yaml" %}}
 
 Создадим Pod:
 

content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -47,7 +47,7 @@ Kubernetes предоставляет liveness пробы, чтобы обнар
 
 В этом упражнении вы создадите Pod, который запускает контейнер, основанный на образе `registry.k8s.io/busybox`. Конфигурационный файл для Pod'а:
 
-{{< codenew file="pods/probe/exec-liveness.yaml" >}}
+{{% codenew file="pods/probe/exec-liveness.yaml" %}}
 
 В конфигурационном файле вы можете видеть, что Pod состоит из одного `Container`.
 Поле `periodSeconds` определяет, что kubelet должен производить liveness
@@ -126,7 +126,7 @@ liveness-exec   1/1       Running   1          1m
 
 Другой вид liveness пробы использует запрос HTTP GET. Ниже представлен файл конфигурации для Pod, который запускает контейнер, основанный на образе `registry.k8s.io/liveness`.
 
-{{< codenew file="pods/probe/http-liveness.yaml" >}}
+{{% codenew file="pods/probe/http-liveness.yaml" %}}
 
 В конфигурационном файле вы можете видеть Pod с одним контейнером.
 Поле `periodSeconds` определяет, что kubelet должен производить liveness
@@ -182,7 +182,7 @@ HTTP liveness проба использует этот прокси.
 kubelet будет пытаться открыть сокет к вашему контейнеру на определённый порт.
 Если он сможет установить соединение, контейнер будет считаться здоровым, если нет, будет считаться заваленным.
 
-{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
+{{% codenew file="pods/probe/tcp-liveness-readiness.yaml" %}}
 
 Как вы можете видеть, конфигурация TCP проверок довольно похожа на HTTP проверки.
 Этот пример использует обе - readiness и liveness пробы. Kubelet будет отправлять первую readiness пробу через 5 секунд после старта контейнера. Он будет пытаться соединиться с `goproxy` контейнером на порт 8080. Если проба успешна, Pod

content/ru/docs/tutorials/hello-minikube.md

@@ -39,9 +39,9 @@ Katacoda предоставляет бесплатную, встроенную 
 
 Для этого примера создан образ контейнера, собранный на основе следующих файлов:
 
-{{< codenew language="js" file="minikube/server.js" >}}
+{{% codenew language="js" file="minikube/server.js" %}}
 
-{{< codenew language="conf" file="minikube/Dockerfile" >}}
+{{% codenew language="conf" file="minikube/Dockerfile" %}}
 
 Чтобы получить больше информации по запуску команды `docker build`, ознакомьтесь с [документацией по Docker](https://docs.docker.com/engine/reference/commandline/build/).