diff --git a/content/ru/docs/concepts/cluster-administration/flow-control.md b/content/ru/docs/concepts/cluster-administration/flow-control.md index 0424b87d29..0962949c17 100644 --- a/content/ru/docs/concepts/cluster-administration/flow-control.md +++ b/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" %}} ## Диагностика diff --git a/content/ru/docs/concepts/cluster-administration/logging.md b/content/ru/docs/concepts/cluster-administration/logging.md index 66bf34fca9..6e227e74c1 100644 --- a/content/ru/docs/concepts/cluster-administration/logging.md +++ b/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,7 +186,7 @@ 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/). @@ -194,7 +194,7 @@ Sidecar-контейнеры также можно использовать дл Второй файл описывает 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 можно заменить на другой лог-агент, считывающий данные из любого источника в контейнере приложения. diff --git a/content/ru/docs/concepts/cluster-administration/manage-deployment.md b/content/ru/docs/concepts/cluster-administration/manage-deployment.md index e4c96fbd0d..400a8d3ba3 100644 --- a/content/ru/docs/concepts/cluster-administration/manage-deployment.md +++ b/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" %}} Можно создавать сразу несколько ресурсов: diff --git a/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md index edf4753bdf..cc4ba312f1 100644 --- a/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/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`. Например: diff --git a/content/ru/docs/contribute/style/write-new-topic.md b/content/ru/docs/contribute/style/write-new-topic.md index 37f989b2c7..9d82e455be 100644 --- a/content/ru/docs/contribute/style/write-new-topic.md +++ b/content/ru/docs/contribute/style/write-new-topic.md @@ -79,19 +79,15 @@ weight: 20 При добавлении нового отдельного файла примера, например, в формате YAML, поместите код в одну из директорий `/examples/`, где `` — язык темы. В вашем файле темы используйте макрокод `codenew`: ```none -{{/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" */%}} ``` -{{< note >}} -Чтобы отобразить Hugo-макрокоды в исходном виде, как в приведенном выше примере, поместите их в комментарии в стиле языка Си между `<` и `>`. Для примера посмотрите исходный код этой страницы. -{{< /note >}} - ## Демонстрация создания API-объекта из конфигурационного файла Если вам нужно показать, как создать объект API из файла конфигурации, поместите файл конфигурации в одну из директорий в `/examples`. diff --git a/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md index d91ea012c7..bb36749830 100644 --- a/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/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: diff --git a/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md index 826aa6c577..0d60bd7de2 100644 --- a/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/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: diff --git a/content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 267f05a9e5..97de8ecffb 100644 --- a/content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/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 diff --git a/content/ru/docs/tutorials/hello-minikube.md b/content/ru/docs/tutorials/hello-minikube.md index 1c986a7234..f4ce7ca7be 100644 --- a/content/ru/docs/tutorials/hello-minikube.md +++ b/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/).