RU localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files
This commit is contained in:
Andrey Goran
parent
ff6d646409
commit
9cd3c6ac89
|
|
@ -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" %}}
|
||||
|
||||
## Диагностика
|
||||
|
||||
|
|
|
|||
|
|
@ -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 можно заменить на другой лог-агент, считывающий данные из любого источника в контейнере приложения.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ weight: 40
|
|||
|
||||
Многие приложения требуют создания нескольких ресурсов типа Deployment и Service. Управление ими можно упростить, сгруппировав в один YAML-файл (со строкой "---" в качестве разделителя). Например:
|
||||
|
||||
{{< codenew file="application/nginx-app.yaml" >}}
|
||||
{{% codenew file="application/nginx-app.yaml" %}}
|
||||
|
||||
Можно создавать сразу несколько ресурсов:
|
||||
|
||||
|
|
|
|||
|
|
@ -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`. Например:
|
||||
|
||||
|
|
|
|||
|
|
@ -79,19 +79,15 @@ weight: 20
|
|||
При добавлении нового отдельного файла примера, например, в формате YAML, поместите код в одну из директорий `<LANG>/examples/`, где `<LANG>` — язык темы. В вашем файле темы используйте макрокод `codenew`:
|
||||
|
||||
```none
|
||||
{{</* codenew file="<RELPATH>/my-example-yaml>" */>}}
|
||||
{{%/* codenew file="<RELPATH>/my-example-yaml>" */%}}
|
||||
```
|
||||
|
||||
где `<RELPATH>` — это путь к включаемому файлу относительно директории `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 из файла конфигурации, поместите файл конфигурации в одну из директорий в `<LANG>/examples`.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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/).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue