From 260d241ddc0d3e6b347cbeb74eddcb62060e5bf6 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Wed, 11 May 2022 11:28:31 +0300 Subject: [PATCH] [ru] Add RU localization for docs/concepts/containers/* Apply suggestions from code review Co-authored-by: Dmitry Shurupov --- content/ru/docs/concepts/architecture/cri.md | 31 ++ content/ru/docs/concepts/containers/_index.md | 33 ++ .../containers/container-environment.md | 51 +++ .../containers/container-lifecycle-hooks.md | 87 ++++++ content/ru/docs/concepts/containers/images.md | 294 ++++++++++++++++++ .../docs/concepts/containers/runtime-class.md | 131 ++++++++ .../glossary/container-runtime-interface.md | 18 ++ .../reference/glossary/container-runtime.md | 10 +- .../ru/docs/reference/glossary/namespace.md | 17 + content/ru/docs/reference/glossary/secret.md | 18 ++ .../reference/glossary/service-account.md | 18 ++ 11 files changed, 703 insertions(+), 5 deletions(-) create mode 100644 content/ru/docs/concepts/architecture/cri.md create mode 100644 content/ru/docs/concepts/containers/_index.md create mode 100644 content/ru/docs/concepts/containers/container-environment.md create mode 100644 content/ru/docs/concepts/containers/container-lifecycle-hooks.md create mode 100644 content/ru/docs/concepts/containers/images.md create mode 100644 content/ru/docs/concepts/containers/runtime-class.md create mode 100644 content/ru/docs/reference/glossary/container-runtime-interface.md create mode 100644 content/ru/docs/reference/glossary/namespace.md create mode 100644 content/ru/docs/reference/glossary/secret.md create mode 100644 content/ru/docs/reference/glossary/service-account.md diff --git a/content/ru/docs/concepts/architecture/cri.md b/content/ru/docs/concepts/architecture/cri.md new file mode 100644 index 0000000000..efa0708d75 --- /dev/null +++ b/content/ru/docs/concepts/architecture/cri.md @@ -0,0 +1,31 @@ +--- +title: Container Runtime Interface (CRI) +content_type: concept +weight: 50 +--- + + + +Интерфейс CRI позволяет kubelet работать с различными исполняемыми средами контейнеров без необходимости перекомпиляции компонентов кластера. + +{{}} должна работать на всех узлах кластера, чтобы {{< 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" >}} + + + +## 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) diff --git a/content/ru/docs/concepts/containers/_index.md b/content/ru/docs/concepts/containers/_index.md new file mode 100644 index 0000000000..e04cb3cdb1 --- /dev/null +++ b/content/ru/docs/concepts/containers/_index.md @@ -0,0 +1,33 @@ +--- +title: Контейнеры +weight: 40 +description: Технология упаковки приложения вместе с его runtime-зависимостями. +reviewers: +content_type: concept +no_list: true +--- + + + +Каждый запускаемый контейнер воспроизводим; стандартизация благодаря включению зависимостей позволяет каждый раз получать одинаковое поведение при запуске. + +Контейнеры абстрагируют приложения от базовой инфраструктуры хоста, упрощая развертывание в различных облачных средах или ОС. + + + + + + +## Образы контейнеров +[Образ контейнера](/docs/concepts/containers/images/) – это готовый к запуску пакет программного обеспечения, содержащий все необходимое для запуска приложения: код, среду исполнения, прикладные и системные библиотеки, а также значения по умолчанию всех важных параметров. + +Контейнер по определению неизменяем (immutable): код работающего контейнера невозможно поменять. Чтобы внести правки в контейнеризованное приложение, необходимо собрать новый образ, содержащий эти правки, а затем запустить контейнер на базе обновленного образа. + +## Исполняемые среды контейнеров + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* Раздел об [образах контейнеров](/docs/concepts/containers/images/). +* Раздел о [Pod'ах](/docs/concepts/workloads/pods/). diff --git a/content/ru/docs/concepts/containers/container-environment.md b/content/ru/docs/concepts/containers/container-environment.md new file mode 100644 index 0000000000..465f841615 --- /dev/null +++ b/content/ru/docs/concepts/containers/container-environment.md @@ -0,0 +1,51 @@ +--- +reviewers: +title: Контейнерное окружение +content_type: concept +weight: 20 +--- + + + +На этой странице описаны ресурсы, доступные для контейнеров в соответствующем окружении. + + + + + + +## Контейнерное окружение + +Контейнерное окружение 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/). diff --git a/content/ru/docs/concepts/containers/container-lifecycle-hooks.md b/content/ru/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000..78f6bce799 --- /dev/null +++ b/content/ru/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,87 @@ +--- +reviewers: +- TBD +- TBD +title: Хуки жизненного цикла контейнеров +content_type: concept +weight: 30 +--- + + + +На этой странице описывается, как контейнеры под управлением kubelet могут использовать механизм хуков для запуска кода, инициированного событиями во время своего жизненного цикла. + + + + + + +## Общая информация + +Многие платформы для разработки предлагают хуки жизненного цикла компонентов (например, 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/). diff --git a/content/ru/docs/concepts/containers/images.md b/content/ru/docs/concepts/containers/images.md new file mode 100644 index 0000000000..3b78e08ed0 --- /dev/null +++ b/content/ru/docs/concepts/containers/images.md @@ -0,0 +1,294 @@ +--- +reviewers: +title: Образы +content_type: concept +weight: 10 +--- + + + +Образ контейнера содержит исполняемые данные приложения и всех его программных зависимостей. Образы контейнеров — это исполняемые пакеты программного обеспечения, способные автономно работать и дополненные конкретными предположениями о соответствующей среде исполнения. + +Как правило, образ контейнера с приложением предварительно собирается и размещается в реестре, после чего его можно использовать в {{< glossary_tooltip text="Pod'е" term_id="pod" >}}. + +На этой странице представлено общее описание концепции контейнерных образов. + + + +## Названия образов + +Образам контейнеров обычно присваивается имя, намекающее на их функционал и цели, например, `pause`, `example/mycontainer` или `kube-apiserver`. Образы также могут включать имя хоста реестра, например, `fictional.registry.example/imagename`, и (в некоторых случаях) номер порта, например, `fictional.registry.example:10443/imagename`. + +Если имя хоста реестра не указано, Kubernetes по умолчанию будет использовать публичный реестр Docker. + +После имени образа можно добавить _тег_ (как, например, в командах `docker` и `podman`). Теги помогают идентифицировать различные версии одной и той же линейки образов. + +Теги образов могут состоять из строчных и прописных букв, цифр, знаков подчеркивания (`_`), точек (`.`) и дефисов (`-`). +Кроме того, существуют дополнительные правила размещения символов-разделителей (`_`, `-` и `.`) внутри тега. +Если тег не указан, Kubernetes по умолчанию использует тег `latest`. + +## Обновление образов + +При первоначальном создании объекта типа {{< glossary_tooltip text="Deployment" term_id="deployment" >}}, {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod или другого объекта, включающего шаблон Pod'а, политика извлечения всех контейнеров в этом Pod'е будет по умолчанию установлена на `IfNotPresent`, если иное не указано явно. В рамках этой политики {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} не извлекает образ, если тот уже присутствует в кэше. + +### Политика извлечения образов + +Политика `imagePullPolicy` контейнера и тег образа определяют поведение [kubelet'а](/docs/reference/command-line-tools-reference/kubelet/) при извлечении (загрузке) данного образа. + +Вот список возможных значений `imagePullPolicy` и их влияние: + +`IfNotPresent` +: образ извлекается только в том случае, если он еще не доступен локально. + +`Always` +: каждый раз при запуске контейнера kubelet запрашивает [дайджест](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier) образа в реестре образов контейнеров. Если полученный дайджест полностью совпадает с дайджестом кэшированного образа, kubelet использует кэшированный образ; иначе извлекается и используется образ с полученным дайждестом. + +`Never` +: kubelet не пытается скачать образ. Если образ уже присутствует локально, kubelet пытается запустить контейнер; в противном случае запуск завершается неудачей. Для получения более подробной информации обратитесь к разделу о [предварительно извлеченных](#предварительно-извлеченные-образы) (pre-pulled) образах. + +Благодаря семантике кэширования, лежащей в основе механизма поставки образов, даже `imagePullPolicy: Always` может быть вполне эффективной (при условии, что реестр надежно доступен). Исполняемая среда для контейнера может обнаружить, что слои образов уже имеются на узле и их не нужно скачивать еще раз. + +{{< note >}} +Избегайте использования тега `:latest` при развертывании контейнеров в production, поскольку в этом случае не понятно, какая именно версия образа используется и на какую ее нужно откатить при необходимости. + +Всегда указывайте содержательный тег, например `v1.42.0`. +{{< /note >}} + +Чтобы убедиться, что Pod всегда использует одну и ту же версию образа контейнера, можно указать дайджест образа вместо тега; для этого замените `:` на `@` +(например, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). + +Изменение кода, к которому привязан некий тег, может привести к тому, что в Pod'ах окажется две версии кода — старая и новая. Дайджест образа однозначно идентифицирует конкретную версию образа, что гарантирует идентичность кода при запуске контейнера с заданным именем образа и дайджестом. Таким образом, изменение кода в реестре уже не может привести к смешению версий. + +Существуют сторонние [admission-контроллеры](/docs/reference/access-authn-authz/admission-controllers/), которые модифицируют Pod'ы (и их шаблоны) при создании, из-за чего рабочая нагрузка определяется на основе дайджеста образа, а не тега. Это может быть полезно в случаях, когда необходимо убедиться, что вся рабочая нагрузка использует идентичный код независимо от изменений тегов в реестре. + +#### Политика извлечения образов по умолчанию {#imagepullpolicy-defaulting} + +Когда информация о новом Pod'е поступает на сервер API, кластер устанавливает поле `imagePullPolicy` в соответствии со следующими условиями: + + +- `imagePullPolicy` автоматически присваивается значение `Always`, если поле `imagePullPolicy` не задано, а тег для образа контейнера имеет значение `:latest`; +- `imagePullPolicy` автоматически присваивается значение `Always`, если поле `imagePullPolicy` не задано, а тег для образа контейнера не указан; +- `imagePullPolicy` автоматически присваивается значение `IfNotPresent`, если поле `imagePullPolicy` не задано, а тег для образа контейнера имеет значение, отличное от `:latest`. + +{{< note >}} +Значение `imagePullPolicy` контейнера всегда устанавливается при первом _создании_ объекта и не обновляется при последующем изменении тега образа. + +Например, если в Deployment'е используется образ с тегом, _отличным_ от `:latest`, а потом он меняется на `:latest`, поле `imagePullPolicy` останется прежним (т.е. _не_ будет изменено на `Always`). После первоначального создания любого объекта его политику извлечения можно изменить вручную. +{{< /note >}} + +#### Обязательное извлечение образов + +Для принудительного извлечения образов можно сделать следующее: + +- Установить `imagePullPolicy` контейнера в `Always`; +- Не устанавливать `imagePullPolicy` и использовать тег `:latest` для образа; Kubernetes автоматически поменяет политику на `Always`, получив информацию о Pod'е; +- Не устанавливать `imagePullPolicy` и тег образа; Kubernetes автоматически применит политику `Always`, получив информацию о Pod'е; +- Включить admission-контроллер [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages). + + +### ImagePullBackOff + +При создании kubelet'ом контейнеров для Pod'а может возникнуть ситуация, когда контейнер пребывает в состоянии [Waiting](/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) из-за `ImagePullBackOff`. + +Статус `ImagePullBackOff` означает, что контейнер не может запуститься, поскольку у Kubernetes не получается извлечь его образ (например, из-за ошибки в имени или попытки извлечь образ из приватного репозитория без `imagePullSecret`). `BackOff` в названии статуса указывает на то, что Kubernetes будет продолжать попытки извлечь образ, постепенно увеличивая интервал между ними. + +Так, интервал между попытками будет расти до тех пор, пока не достигнет установленного предела в 300 секунд (5 минут). + +## Мультиархитектурные образы с индексами + +Помимо обычных исполняемых образов реестр контейнеров также может хранить так называемые [индексы образов](https://github.com/opencontainers/image-spec/blob/master/image-index.md). Индекс образа содержит ссылки на различные [манифесты образов](https://github.com/opencontainers/image-spec/blob/master/manifest.md), каждый из которых предназначен для определенной архитектуры. Идея здесь в том, чтобы любой пользователь мог получить образ, оптимизированный под конкретную архитектуру, используя его унифицированное, общее для всех архитектур имя (например, `pause`, `example/mycontainer`, `kube-apiserver`). + +Сам Kubernetes обычно добавляет суффикс `-$(ARCH)` к имени образа. Для обратной совместимости также рекомендуется генерировать образы с суффиксами в названиях. Например, универсальный образ `pause`, содержащий манифест для всех архитектур, рекомендуется дополнить образом `pause-amd64` для обратной совместимости со старыми конфигурациями или YAML-файлами, в которых могут быть жестко прописаны образы с суффиксами. + +## Работа с приватным реестром + +Для чтения образов из приватных реестров могут потребоваться соответствующие ключи. +Доступ к таким реестрам можно получить следующими способами: + - Аутентификация на уровне узлов: + - все Pod'ы имеют доступ ко всем настроенным приватным реестрам; + - требуется конфигурация узлов администратором кластера; + - Предварительно извлеченные образы: + - все Pod'ы могут использовать любые образы, кэшированные на узле; + - для настройки требуется root-доступ ко всем узлам; + - imagePullSecrets на уровне Pod'а: + - доступ к реестру получают только Pod'ы с ключами; + - Специализированные расширения от вендора/пользователя: + - в кастомных конфигурациях могут существовать специализированные механизмы аутентификации узлов в реестре контейнеров, реализованные самим пользователем или поставщиком облачных услуг. + +Ниже мы подробнее остановимся на каждом из вариантов. + +### Аутентификация на уровне узлов + +Конкретные инструкции по настройке учетных данных зависят от среды исполнения контейнера и реестра. Для получения наиболее подробной информации следует обратиться к документации используемого решения. + +Пример настройки частного реестра образов контейнеров приводится в упражнении [Извлекаем образ из частного реестра](/docs/tasks/configure-pod-container/pull-image-private-registry). В нем используется частный реестр в Docker Hub. + +### Интерпретация config.json {#config-json} + +Интерпретация `config.json` отличается в оригинальной Docker-реализации и в Kubernetes. В Docker ключи `auths` могут указывать только корневые URL, в то время как Kubernetes позволяет использовать URL с подстановками (globbing) и пути с префиксами. То есть `config.json`, подобный этому, вполне допустим: + +```json +{ + "auths": { + "*my-registry.io/images": { + "auth": "…" + } + } +} +``` + +Корневой URL (`*my-registry.io`) сопоставляется с помощью следующего синтаксиса: + +``` +pattern: + { term } + +term: + '*' соответствует любой последовательности символов, не являющихся разделителями + '?' соответствует любому одиночному символу, не являющемуся разделителем + '[' [ '^' ] { диапазон символов } ']' + класс символов (не может быть пустым) + c соответствует символу c (c != '*', '?', '\\', '[') + '\\' c соответствует символу c + +диапазон символов: + c соответствует символу c (c != '\\', '-', ']') + '\\' c соответствует символу c + lo '-' hi соответствует символу c при lo <= c <= hi +``` + +Учетные данные теперь будут передаваться в CRI-совместимую исполняемую среду для контейнеров для каждого действительного шаблона. Ниже приведены примеры имен образов, удовлетворяющие требованиям к паттерну: + +- `my-registry.io/images` +- `my-registry.io/images/my-image` +- `my-registry.io/images/another-image` +- `sub.my-registry.io/images/my-image` +- `a.sub.my-registry.io/images/my-image` + +kubelet последовательно извлекает образы для каждой обнаруженной учетной записи. Это означает, что `config.json` может содержать сразу несколько записей: + +```json +{ + "auths": { + "my-registry.io/images": { + "auth": "…" + }, + "my-registry.io/images/subpath": { + "auth": "…" + } + } +} +``` + +К примеру, если необходимо извлечь образ `my-registry.io/images/subpath/my-image`, kubelet будет пытаться загрузить его из второго источника, если первый не работает. + +### Предварительно извлеченные образы + +{{< note >}} +Этот подход применим, если имеется доступ к конфигурации узлов. Он не будет надежно работать, если поставщик облачных услуг управляет узлами и автоматически заменяет их. +{{< /note >}} + +По умолчанию kubelet пытается извлечь каждый образ из указанного реестра. Однако если параметр `imagePullPolicy` контейнера установлен на `IfNotPresent` или `Never`, используется локальный образ (преимущественно или исключительно, соответственно). + +Чтобы использовать предварительно извлеченные образы (и не связываться с аутентификацией для доступа к реестру), необходимо убедиться, что они идентичны на всех узлах кластера. + +Предварительная загрузка образов позволяет увеличить скорость работы и является альтернативой аутентификации в приватном реестре. + +При этом у всех Pod'ов будет доступ на чтение всех предварительно извлеченных образов. + +### Задаем imagePullSecrets на уровне Pod'а + +{{< note >}} +Это рекомендуемый подход для запуска контейнеров на основе образов в приватных реестрах. +{{< /note >}} + +Kubernetes поддерживает указание ключей реестра образов на уровне Pod'а. + +#### Создаем Secret с помощью конфигурационного файла Docker + +Для аутентификации в реестре необходимо знать имя пользователя, пароль, имя хоста реестра и адрес электронной почты клиента. + +Выполните следующую команду, подставив соответствующие значения вместо параметров, выделенных заглавными буквами: + +```shell +kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL +``` + +При наличии файла учетных данных Docker можно импортировать их как {{< glossary_tooltip text="Secret'ы" term_id="secret" >}} Kubernetes вместо команды, приведенной выше. + +В разделе [Создание Secret'а на основе существующих учетных данных Docker](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) рассказывается, как это можно сделать. + +Это особенно удобно в случае нескольких приватных реестров контейнеров, так как `kubectl create secret docker-registry` создает Secret, который работает только с одним приватным реестром. + +{{< note >}} +Pod'ы могут работать только с Secret'ами в собственном пространстве имен, поэтому данный процесс необходимо повторить для каждого пространства имен. +{{< /note >}} + +#### Ссылаемся на imagePullSecrets в Pod'е + +Теперь можно создавать Pod'ы, ссылающиеся на данный Secret, добавив раздел `imagePullSecrets` в манифест Pod'а. + +Например: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: foo + namespace: awesomeapps +spec: + containers: + - name: foo + image: janedoe/awesomeapp:v1 + imagePullSecrets: + - name: myregistrykey +EOF + +cat <> ./kustomization.yaml +resources: +- pod.yaml +EOF +``` + +Это необходимо проделать для каждого Pod'а, работающего с приватным репозиторием. + +Процесс можно автоматизировать, задав imagePullSecrets в ресурсе [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/). + +Подробные инструкции см. в разделе [Добавить ImagePullSecrets в Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). + +Этот подход можно использовать совместно с файлами `.docker/config.json`, определяемыми для каждого узла. Учетные данные будут объединены. + +## Примеры использования + +Существует ряд решений для настройки приватных реестров. Вот некоторые распространенные случаи использования и рекомендуемые решения: + +1. Кластер, работающий только со свободными (например, Open Source) образами. Необходимость скрывать образы отсутствует. + - Используйте общедоступные образы из Docker Hub; + - Настройка не требуется; + - Некоторые облачные провайдеры автоматически кэшируют или зеркалируют публичные образы, что повышает доступность и сокращает время их извлечения. +1. В кластере используются закрытые образы. Они должны быть скрыты для всех за пределами компании, но доступны для всех пользователей кластера. + - Используйте приватный репозиторий; + - Может потребоваться ручная настройка на узлах, которым необходим доступ к частному репозиторию; + - В качестве альтернативы можно завести внутренний приватный реестр с доступом на чтение, скрыв его за сетевым экраном; + - Настройка Kubernetes не требуется; + - Используйте сервис для работы с образами, контролирующий доступ к ним; + - Этот подход лучше работает с автомасштабированием кластера, нежели ручная настройка узлов; + - Если изменение конфигурации узлов в кластере затруднено, можно использовать imagePullSecrets. +1. Кластер с несвободными образами, некоторые из которых требуют более строгого контроля доступа. + - Убедитесь, что [AlwaysPullImages admission-контроллер](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) включен. В противном случае у всех Pod'ов потенциально будет доступ ко всем образам; + - Переместите конфиденциальные данные в Secret вместо того, чтобы упаковывать их в образ. +1. Кластер категории multi-tenant (многопользовательский), где каждому пользователю требуется собственный приватный репозиторий. + - Убедитесь, что [admission-контроллер AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) включен. В противном случае у всех Pod'ов всех пользователей потенциально будет доступ ко всем образам; + - Создайте приватный реестр с обязательной авторизацией; + - Сгенерируйте учетные данные для доступа к реестру для каждого пользователя, поместите их в Secret и добавьте его в пространство имен каждого пользователя; + - Каждый пользователь должен добавить свой Secret в imagePullSecrets каждого пространства имен. + + +Если нужен доступ к нескольким реестрам, можно создать по Secret'у для каждого реестра. + +## {{% heading "whatsnext" %}} + +* [Спецификация манифестов образов OCI](https://github.com/opencontainers/image-spec/blob/master/manifest.md). +* Сборка "мусора" в Kubernetes — [неиспользуемые контейнеры и образы](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection). +* [Извлечение образов из приватных репозиториев](/docs/tasks/configure-pod-container/pull-image-private-registry). diff --git a/content/ru/docs/concepts/containers/runtime-class.md b/content/ru/docs/concepts/containers/runtime-class.md new file mode 100644 index 0000000000..7169da2868 --- /dev/null +++ b/content/ru/docs/concepts/containers/runtime-class.md @@ -0,0 +1,131 @@ +--- +reviewers: +title: RuntimeClass +content_type: concept +weight: 20 +--- + + + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +На этой странице описывается ресурс RuntimeClass и механизм выбора исполняемой среды. + +RuntimeClass позволяет выбрать конфигурацию исполняемой среды для контейнеров. Используется для настройки исполняемой среды в Pod'е. + + + +## Мотивация + +Разным Pod'ам можно назначать различные RuntimeClass'ы, соблюдая баланс между производительностью и безопасностью. Например, если часть рабочей нагрузки требует высокого уровня информационной безопасности, связанные с ней Pod'ы можно запланировать так, чтобы они использовали исполняемую среду для контейнеров на основе аппаратной виртуализации. Это обеспечит повышенную изоляцию, но потребует дополнительных издержек. + +Также можно использовать RuntimeClass для запуска различных Pod'ов с одинаковой исполняемой средой, но с разными настройками. + +## Подготовка + +1. Настройте реализацию CRI на узлах (зависит от используемой исполняемой среды); +2. Создайте соответствующие ресурсы RuntimeClass. + +### 1. Настройте реализацию CRI на узлах + +Конфигурации, доступные с помощью RuntimeClass, зависят от реализации Container Runtime Interface (CRI). Для настройки определенной реализации CRI обратитесь к соответствующему разделу документации ([ниже](#cri-configuration)). + +{{< note >}} +По умолчанию RuntimeClass предполагает однородную конфигурацию узлов в кластере (то есть все узлы настроены одинаково в плане исполняемой среды для контейнеров). Для гетерогенных конфигураций узлов см. раздел [Scheduling](#scheduling) ниже. +{{< /note >}} + +Каждой конфигурации соответствует обработчик, на который ссылается RuntimeClass. Имя обработчика должно соответствовать [синтаксису для меток DNS](/docs/concepts/overview/working-with-objects/names/#dns-label-names). + +### 2. Создайте соответствующие ресурсы RuntimeClass + +К каждой конфигурации, настроенной на шаге 1, должно быть привязано имя обработчика (`handler`), которое ее идентифицирует. Для каждого обработчика создайте соответствующий объект RuntimeClass. + +На данный момент у ресурса RuntimeClass есть только 2 значимых поля: имя RuntimeClass (`metadata.name`) и обработчик (`handler`). Определение объекта выглядит следующим образом: + +```yaml +# RuntimeClass определен в API-группе node.k8s.io +apiVersion: node.k8s.io/v1 +kind: RuntimeClass +metadata: + # Имя, которое ссылается на RuntimeClass + # ресурс RuntimeClass не включается в пространство имен + name: myclass +# Имя соответствующей конфигурации CRI +handler: myconfiguration +``` + +Имя объекта RuntimeClass должно удовлетворять [синтаксису для поддоменных имен DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +{{< note >}} +Рекомендуется ограничить доступ к операциям записи RuntimeClass (create/update/patch/delete) администратором кластера. Обычно это сделано по умолчанию. Более подробную информацию см. в разделе [Общая информация об авторизации](/docs/reference/access-authn-authz/authorization/). +{{< /note >}} + +## Использование + +После того как RuntimeClasses настроены для кластера, использовать их очень просто. Достаточно указать `runtimeClassName` в спецификации Pod'а. Например: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + runtimeClassName: myclass + # ... +``` + +kubelet будет использовать указанный RuntimeClass для запуска этого Pod'а. Если указанный RuntimeClass не существует или CRI не может запустить соответствующий обработчик, Pod войдет в [фазу завершения работы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. Полное сообщение об ошибке можно получить, обратившись к соответствующему [событию](/docs/tasks/debug/debug-application/debug-running-pod/) (event). + +Если имя `runtimeClassName` не указано, будет использоваться RuntimeHandler по умолчанию (что эквивалентно поведению, когда функция RuntimeClass отключена). + +### Настройка CRI + +Для получения более подробной информации о настройке исполняемых сред CRI обратитесь к разделу [Установка CRI](/docs/setup/production-environment/container-runtimes/). + +#### {{< glossary_tooltip term_id="containerd" >}} + +Обработчики исполняемой среды настраиваются в конфигурации containerd в файле `/etc/containerd/config.toml`. Допустимые обработчики прописываются в разделе runtimes: + +``` +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] +``` + +Дополнительная информация доступна в [документации по конфигурации containerd](https://github.com/containerd/cri/blob/master/docs/config.md). + +#### {{< glossary_tooltip term_id="cri-o" >}} + +Обработчики исполняемой среды настраиваются в файле конфигурации CRI-O (`/etc/crio/crio.conf`). Допустимые обработчики прописываются в [таблице crio.runtime](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table): + +``` +[crio.runtime.runtimes.${HANDLER_NAME}] + runtime_path = "${PATH_TO_BINARY}" +``` + +Более подробную информацию см. в [документации по конфигурации CRI-O](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md). + +## Scheduling + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +Поле `scheduling` в RuntimeClass позволяет наложить определенные ограничения, гарантировав, что Pod'ы с определенным RuntimeClass'ом будут планироваться на узлы, которые его поддерживают. Если параметр `scheduling` не установлен, предполагается, что данный RuntimeClass поддерживается всеми узлами. + +Чтобы гарантировать, что Pod'ы попадают на узлы, поддерживающие определенный RuntimeClass, эти узлы должны быть связаны общей меткой, которая затем выбирается полем `runtimeclass.scheduling.nodeSelector`. nodeSelector RuntimeClass'а объединяется с nodeSelector'ом admission-контроллера, на выходе образуя пересечение подмножеств узлов, выбранных каждым из селекторов. Если возникает конфликт, Pod отклоняется. + +Если поддерживаемые узлы объединены неким taint'ом, чтобы предотвратить запуск на них Pod'ов с другими RuntimeClass'ами, можно к нужному RuntimeClass'у добавить `tolerations`. Как и в случае с `nodeSelector`, tolerations объединяются с tolerations Pod'а admission-контроллера, фактически образуя объединение двух подмножеств узлов с соответствующими tolerations. + +Чтобы узнать больше о настройке селектора узлов и tolerations, см. раздел [Назначаем Pod'ы на узлы](/docs/concepts/scheduling-eviction/assign-pod-node/). + +### Pod Overhead + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Можно указать _overhead_-ресурсы, необходимые для работы Pod'а. Это позволит кластеру (и планировщику) учитывать их при принятии решений о Pod'ах и управлении ресурсами. + +В RuntimeClass дополнительные ресурсы, потребляемые Pod'ом, указываются в поле `overhead`. С помощью этого поля можно указать ресурсы, необходимые Pod'ам с данным RuntimeClass'ом, и гарантировать их учет в Kubernetes. + +## {{% heading "whatsnext" %}} + +- Описание [RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md); +- Описание [RuntimeClass Scheduling](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling); +- Концепция [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/); +- Описание функции [PodOverhead](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead). diff --git a/content/ru/docs/reference/glossary/container-runtime-interface.md b/content/ru/docs/reference/glossary/container-runtime-interface.md new file mode 100644 index 0000000000..8bb24114a0 --- /dev/null +++ b/content/ru/docs/reference/glossary/container-runtime-interface.md @@ -0,0 +1,18 @@ +--- +title: Container Runtime Interface +id: container-runtime-interface +date: 2021-11-24 +full_link: /docs/concepts/architecture/cri +short_description: > + Основной протокол для связи между kubelet'ом и исполняемой средой контейнеров. + +aka: +tags: + - cri +--- + +Container Runtime Interface (CRI) — это основной протокол для связи между kubelet'ом и исполняемой средой контейнеров. + + + +Интерфейс Kubernetes Container Runtime Interface (CRI) задает основной [gRPC-протокол](https://grpc.io), на базе которого осуществляется коммуникация между [компонентами кластера](/docs/concepts/overview/components/#node-components): {{< glossary_tooltip text="kubelet'ом" term_id="kubelet" >}} и {{< glossary_tooltip text="исполняемой средой" term_id="container-runtime" >}}. diff --git a/content/ru/docs/reference/glossary/container-runtime.md b/content/ru/docs/reference/glossary/container-runtime.md index 25916582e5..0ff3f1c47d 100644 --- a/content/ru/docs/reference/glossary/container-runtime.md +++ b/content/ru/docs/reference/glossary/container-runtime.md @@ -1,21 +1,21 @@ --- -title: Среда выполнения контейнера +title: Иполняемая среда контейнеров id: container-runtime date: 2019-06-05 full_link: /docs/setup/production-environment/container-runtimes short_description: > - Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров. + Иполняемая среда контейнеров — это программа, предназначенная для запуска контейнеров. aka: tags: - fundamental - workload --- - Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров. + Иполняемая среда контейнера — это программа, предназначенная для запуска контейнера в Kubernetes. -Kubernetes поддерживает несколько сред для запуска контейнеров: {{< glossary_tooltip term_id="docker">}}, +Kubernetes поддерживает различные среды для запуска контейнеров: {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}, -и любая реализация [Kubernetes CRI (Container Runtime +и любые реализации [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). diff --git a/content/ru/docs/reference/glossary/namespace.md b/content/ru/docs/reference/glossary/namespace.md new file mode 100644 index 0000000000..9e876227cd --- /dev/null +++ b/content/ru/docs/reference/glossary/namespace.md @@ -0,0 +1,17 @@ +--- +title: Пространство имен +id: namespace +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/namespaces +short_description: > + Абстракция, которую Kubernetes использует для изоляции групп ресурсов в рамках одного кластера. + +aka: +tags: +- fundamental +--- + Абстракция, которую Kubernetes использует для изоляции групп ресурсов в рамках одного {{< glossary_tooltip text="кластера" term_id="cluster" >}}. + + + +Пространства имен используются для организации объектов в кластере и разграничивают ресурсы кластера. Имена ресурсов должны быть уникальными в пределах одного пространства имен, но не в разных пространствах имен. Ограничения на основе пространства имен применимы только к объектам на уровне пространств имен _(например, Deployments, Services и т.д.)_, но не для объектов на уровне кластера _(таких как StorageClass, Nodes, PersistentVolumes и т.д.)_. diff --git a/content/ru/docs/reference/glossary/secret.md b/content/ru/docs/reference/glossary/secret.md new file mode 100644 index 0000000000..4abf91292d --- /dev/null +++ b/content/ru/docs/reference/glossary/secret.md @@ -0,0 +1,18 @@ +--- +title: Secret +id: secret +date: 2018-04-12 +full_link: /docs/concepts/configuration/secret/ +short_description: > + Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи ssh. + +aka: +tags: +- core-object +- security +--- + Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи ssh. + + + +Позволяет повысить контроль над использованием конфиденциальной информации и снизить риск ее случайного раскрытия. Секретные значения кодируются в формат base64 и по умолчанию хранятся в незашифрованном виде, но могут быть настроены на шифрование "at rest" (при записи в хранилище). {{< glossary_tooltip text="Pod" term_id="pod" >}} ссылается на Secret как на файл при монтировании тома. Secret также используется kubelet'ом при извлечении образов для Pod'а. Secret'ы отлично подходят для хранения конфиденциальных данных, [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) – для неконфиденциальных. diff --git a/content/ru/docs/reference/glossary/service-account.md b/content/ru/docs/reference/glossary/service-account.md new file mode 100644 index 0000000000..87abd6a193 --- /dev/null +++ b/content/ru/docs/reference/glossary/service-account.md @@ -0,0 +1,18 @@ +--- +title: ServiceAccount +id: service-account +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-service-account/ +short_description: > + Отвечает за идентификацию процессов, выполняющихся в Pod'е. + +aka: +tags: +- fundamental +- core-object +--- + Отвечает за идентификацию процессов, выполняющихся в {{< glossary_tooltip text="Pod'е" term_id="pod" >}}. + + + +Процессы внутри Pod'а аутентифицируются сервером API и относятся к определенной учетной записи (service account) (например, к `default`) для доступа к кластеру. Если при создании Pod'а служебная учетная запись не указана, ему автоматически присваивается service account по умолчанию в том же {{< glossary_tooltip text="пространстве имен" term_id="namespace" >}}.