[ru] Add RU localization for docs/concepts/containers/*

Apply suggestions from code review

Co-authored-by: Dmitry Shurupov <[email protected]>

Author: 2 people

content/ru/docs/concepts/architecture/cri.md

@@ -0,0 +1,31 @@
+---
+title: Container Runtime Interface (CRI)
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+
+Интерфейс CRI позволяет kubelet работать с различными исполняемыми средами контейнеров без необходимости перекомпиляции компонентов кластера.
+
+{{<glossary_tooltip text="Исполняемая среда контейнеров" term_id="container-runtime">}} должна работать на всех узлах кластера, чтобы {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} мог запускать {{< glossary_tooltip text="Pod'ы" term_id="pod" >}} и их контейнеры.
+
+{{< glossary_definition prepend="Интерфейс Kubernetes Container Runtime Interface (CRI)" term_id="container-runtime-interface" length="all" >}}
+
+<!-- body -->
+
+## API {#api}
+
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
+
+Kubelet выступает в роли клиента при подключении к исполняемой среде через gRPC. Конечные точки ImageService и RuntimeService должны быть доступны в исполняемой среде контейнеров; в kubelet их можно настроить независимо с помощью [флагов командной строки](/docs/reference/command-line-tools-reference/kubelet) `--image-service-endpoint` и `--container-runtime-endpoint`.
+
+В Kubernetes v{{< skew currentVersion >}} kubelet предпочитает использовать CRI `v1`. Если исполняемая среда контейнера не поддерживает `v1` CRI, kubelet пытается перейти на более старую поддерживаемую версию. В версии v{{< skew currentVersion >}} kubelet также может работать с CRI `v1alpha2`, но эта версия считается устаревшей. Если согласовать поддерживаемую версию CRI не удается, узел не регистрируется.
+
+## Обновление
+
+При обновлении Kubernetes kubelet автоматически выбирает последнюю версию CRI при перезапуске компонента. Если это не удается, происходит откат, как описано выше. Если повторный вызов gRPC произошел из-за обновления исполняемой среды контейнера, последняя также должна поддерживать первоначально выбранную версию, иначе повторный вызов будет неудачным. Для этого требуется перезапуск kubelet'а.
+
+## {{% heading "whatsnext" %}}
+
+- Дополнительная информация о [протоколе CRI](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)

content/ru/docs/concepts/containers/_index.md

@@ -0,0 +1,33 @@
+---
+title: Контейнеры
+weight: 40
+description: Технология упаковки приложения вместе с его runtime-зависимостями.
+reviewers:
+content_type: concept
+no_list: true
+---
+
+<!-- overview -->
+
+Каждый запускаемый контейнер воспроизводим; стандартизация благодаря включению зависимостей позволяет каждый раз получать одинаковое поведение при запуске.
+
+Контейнеры абстрагируют приложения от базовой инфраструктуры хоста, упрощая развертывание в различных облачных средах или ОС.
+
+
+
+
+<!-- body -->
+
+## Образы контейнеров
+[Образ контейнера](/docs/concepts/containers/images/) – это готовый к запуску пакет программного обеспечения, содержащий все необходимое для запуска приложения: код, среду исполнения, прикладные и системные библиотеки, а также значения по умолчанию всех важных параметров.
+
+Контейнер по определению неизменяем (immutable): код работающего контейнера невозможно поменять. Чтобы внести правки в контейнеризованное приложение, необходимо собрать новый образ, содержащий эти правки, а затем запустить контейнер на базе обновленного образа.
+
+## Исполняемые среды контейнеров
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## {{% heading "whatsnext" %}}
+
+* Раздел об [образах контейнеров](/docs/concepts/containers/images/).
+* Раздел о [Pod'ах](/docs/concepts/workloads/pods/).

content/ru/docs/concepts/containers/container-environment.md

@@ -0,0 +1,51 @@
+---
+reviewers:
+title: Контейнерное окружение
+content_type: concept
+weight: 20
+---
+
+<!-- overview -->
+
+На этой странице описаны ресурсы, доступные для контейнеров в соответствующем окружении. 
+
+
+
+
+<!-- body -->
+
+## Контейнерное окружение
+
+Контейнерное окружение Kubernetes предоставляет контейнерам несколько важных ресурсов:
+
+* Файловую систему, сочетающую в себе [образ](/docs/concepts/containers/images/) и один или несколько [томов](/docs/concepts/storage/volumes/).
+* Информацию о самом контейнере.
+* Информацию о других объектах в кластере.
+
+### Информация о контейнере
+
+*Hostname* контейнера — имя Pod'а, в котором запущен контейнер. Его можно получить с помощью команды `hostname` или функции [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) в libc.
+
+Имя Pod'а и его пространство имен можно получить из переменных окружения в [Downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/).
+
+Контейнеру также доступны переменные окружения из определения Pod'а, заданные пользователем, а также любые переменные окружения, указанные статически в образе контейнера.
+
+### Информация о кластере
+
+Список всех сервисов, активных на момент создания контейнера, доступен этому контейнеру в виде переменных окружения. Этот список ограничен сервисами в пространстве имен, которому принадлежит Pod с данным контейнером, а также сервисами управляющего слоя Kubernetes.
+
+Для сервиса *foo*, связанного с контейнером *bar*, определены следующие переменные:
+
+```shell
+FOO_SERVICE_HOST=<хост, на котором запущен сервис>
+FOO_SERVICE_PORT=<порт, на котором запущен сервис>
+```
+
+Сервисы получают выделенные IP-адреса и доступны для контейнера через DNS, если включен [аддон DNS](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/). 
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [Хуки жизненного цикла контейнера](/docs/concepts/containers/container-lifecycle-hooks/).
+* Упражнение: [Подключаем обработчики к событиям жизненного цикла контейнера](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).

content/ru/docs/concepts/containers/container-lifecycle-hooks.md

@@ -0,0 +1,87 @@
+---
+reviewers:
+- TBD
+- TBD
+title: Хуки жизненного цикла контейнеров
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+
+На этой странице описывается, как контейнеры под управлением kubelet могут использовать механизм хуков для запуска кода, инициированного событиями во время своего жизненного цикла.
+
+
+
+
+<!-- body -->
+
+## Общая информация
+
+Многие платформы для разработки предлагают хуки жизненного цикла компонентов (например, Angular). Kubernetes имеет аналогичный механизм. Хуки позволяют контейнерам оставаться в курсе событий своего жизненного цикла и запускать запакованный в обработчик код при наступлении определенных событий, приводящих к вызову хука.
+
+## Хуки контейнеров
+
+В распоряжении контейнеров имеются два хука:
+
+`PostStart`
+
+Выполняется сразу после создания контейнера. Однако нет гарантии, что хук закончит работу до ENTRYPOINT контейнера. Параметры обработчику не передаются.
+
+`PreStop`
+
+Вызывается непосредственно перед завершением работы контейнера в результате запроса API или иного события (например, неудачное завершение теста liveness/startup, вытеснение, борьба за ресурсы и т.п.). Вызов хука `PreStop` завершается неудачно, если контейнер уже находится в прерванном (terminated) или завершенном (completed) состоянии. Кроме того, работа хука должна закончиться до того, как будет отправлен сигнал TERM для остановки контейнера. Отсчет задержки перед принудительной остановкой Pod'а (grace-период) начинается до вызова хука `PreStop`. Таким образом, независимо от результата выполнения обработчика, контейнер будет остановлен в течение этого grace-периода. Параметры обработчику не передаются.
+
+Более подробное описание поведения при прекращении работы можно найти в разделе [Прекращение работы Pod'ов](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
+
+### Реализации обработчиков хуков
+
+Чтобы контейнер имел доступ к хуку, необходимо реализовать и зарегистрировать обработчик для этого хука. Существует два типа обработчиков хуков, доступных для контейнеров:
+
+* Exec — Выполняет определенную команду, например, `pre-stop.sh`, внутри cgroups и пространств имен контейнера. Ресурсы, потребляемые командой, прибавляются к ресурсам, потребляемым контейнером.
+* HTTP — Выполняет HTTP-запрос к определенной конечной точке контейнера.
+
+### Выполнение обработчиков хуков
+
+При вызове хука, привязанного к жизненному циклу контейнера, система управления Kubernetes выполняет обработчик в соответствии с типом хука: kubelet отвечает за `httpGet` и `tcpSocket`, а `exec` выполняется в контейнере.
+
+Вызовы обработчиков хуков синхронны в контексте Pod'а, содержащего контейнер. Это означает, что в случае `PostStart`-хука ENTRYPOINT контейнера и хук запускаются асинхронно. При этом если хук выполняется слишком долго или зависает, контейнер не может достичь состояния `Running`.
+
+Хуки `PreStop` не запускаются асинхронно с сигналом на остановку контейнера; хук должен завершить свою работу до отправки сигнала TERM. Если хук `PreStop` зависнет во время выполнения, Pod будет пребывать в состоянии `Terminating` до истечения периода `terminationGracePeriodSeconds`, после чего Kubernetes "убьет" его. Этот grace-период включает как время, которое требуется для выполнения хука `PreStop`, так и время, необходимое для нормальной остановки контейнера. Например, если `terminationGracePeriodSeconds` равен 60, работа хука занимает 55 секунд, а контейнеру требуется 10 секунд для нормальной остановки после получения сигнала, то контейнер будет "убит" до того, как сможет нормально завершить свою работу, поскольку `terminationGracePeriodSeconds` меньше, чем суммарное время (55+10), необходимое для работы хука и остановки контейнера.
+
+Если любой из хуков `postStart` / `preStop` завершается неудачей, Kubernetes "убивает" контейнер.
+
+Поэтому обработчики для хуков должны быть максимально простыми. Однако бывают случаи, когда применение "тяжелых" команд оправдано – например, при сохранении состояния перед остановкой контейнера.
+
+### Гарантии поставки хука
+
+Хук должен выполниться *хотя бы один раз*. Это означает, что он может вызываться неоднократно для любого события вроде `PostStart` или `PreStop`. Задача по правильной обработке подобных вызовов возложена на сам хук.
+
+Как правило, поставка хука выполняется однократно. Если, например, приемник HTTP-хука не работает и не может принимать трафик, повторная попытка отправки не предпринимается. В редких случаях может происходить двойная поставка. Например, если kubelet перезапустится в процессе доставки хука, тот может быть отправлен повторно.
+
+### Отладка обработчиков хуков
+
+Логи обработчиков хуков не отображаются в событиях Pod'а. В случае сбоя обработчика тот транслирует событие. Для `PostStart` это событие `FailedPostStartHook`, для `PreStop` — событие `FailedPreStopHook`. Чтобы самостоятельно сгенерировать событие `FailedPreStopHook`, в манифесте [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) замените команду для postStart на что-то заведомо невыполнимое (`badcommand`) и примените его. Если теперь выполнить команду `kubectl describe pod lifecycle-demo`, вы увидите следующее:
+
+```
+Events:
+  Type     Reason               Age              From               Message
+  ----     ------               ----             ----               -------
+  Normal   Scheduled            7s               default-scheduler  Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2...
+  Normal   Pulled               6s               kubelet            Successfully pulled image "nginx" in 229.604315ms
+  Normal   Pulling              4s (x2 over 6s)  kubelet            Pulling image "nginx"
+  Normal   Created              4s (x2 over 5s)  kubelet            Created container lifecycle-demo-container
+  Normal   Started              4s (x2 over 5s)  kubelet            Started container lifecycle-demo-container
+  Warning  FailedPostStartHook  4s (x2 over 5s)  kubelet            Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n"
+  Normal   Killing              4s (x2 over 5s)  kubelet            FailedPostStartHook
+  Normal   Pulled               4s               kubelet            Successfully pulled image "nginx" in 215.66395ms
+  Warning  BackOff              2s (x2 over 3s)  kubelet            Back-off restarting failed container
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Дополнительная информация о [контейнерном окружении](/docs/concepts/containers/container-environment/).
+* Упражнение: [Подключаем обработчики к событиям жизненного цикла контейнера](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).