Merge pull request #34803 from flant/ru-docs-concepts-1
[ru] Translate docs/concepts/containers/ - RU K8s docspull/40082/head
Kubernetes Prow Robot
GitHub
commit
205c57605c
|
|
@ -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)
|
||||
|
|
@ -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/).
|
||||
|
|
@ -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/).
|
||||
|
|
@ -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/).
|
||||
|
|
@ -0,0 +1,294 @@
|
|||
---
|
||||
reviewers:
|
||||
title: Образы
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Образ контейнера содержит исполняемые данные приложения и всех его программных зависимостей. Образы контейнеров — это исполняемые пакеты программного обеспечения, способные автономно работать и дополненные конкретными предположениями о соответствующей среде исполнения.
|
||||
|
||||
Как правило, образ контейнера с приложением предварительно собирается и размещается в реестре, после чего его можно использовать в {{< glossary_tooltip text="Pod'е" term_id="pod" >}}.
|
||||
|
||||
На этой странице представлено общее описание концепции контейнерных образов.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Названия образов
|
||||
|
||||
Образам контейнеров обычно присваивается имя, намекающее на их функционал и цели, например, `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-name>:<tag>` на `<image-name>@<digest>`
|
||||
(например, `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 <name> --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 <<EOF > pod.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: foo
|
||||
namespace: awesomeapps
|
||||
spec:
|
||||
containers:
|
||||
- name: foo
|
||||
image: janedoe/awesomeapp:v1
|
||||
imagePullSecrets:
|
||||
- name: myregistrykey
|
||||
EOF
|
||||
|
||||
cat <<EOF >> ./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).
|
||||
|
|
@ -0,0 +1,131 @@
|
|||
---
|
||||
reviewers:
|
||||
title: RuntimeClass
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
|
||||
|
||||
На этой странице описывается ресурс RuntimeClass и механизм выбора исполняемой среды.
|
||||
|
||||
RuntimeClass позволяет выбрать конфигурацию исполняемой среды для контейнеров. Используется для настройки исполняемой среды в Pod'е.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Мотивация
|
||||
|
||||
Разным 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).
|
||||
|
|
@ -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'ом и исполняемой средой контейнеров.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Интерфейс 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" >}}.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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).
|
||||
|
|
|
|||
|
|
@ -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" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Пространства имен используются для организации объектов в кластере и разграничивают ресурсы кластера. Имена ресурсов должны быть уникальными в пределах одного пространства имен, но не в разных пространствах имен. Ограничения на основе пространства имен применимы только к объектам на уровне пространств имен _(например, Deployments, Services и т.д.)_, но не для объектов на уровне кластера _(таких как StorageClass, Nodes, PersistentVolumes и т.д.)_.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Позволяет повысить контроль над использованием конфиденциальной информации и снизить риск ее случайного раскрытия. Секретные значения кодируются в формат base64 и по умолчанию хранятся в незашифрованном виде, но могут быть настроены на шифрование "at rest" (при записи в хранилище). {{< glossary_tooltip text="Pod" term_id="pod" >}} ссылается на Secret как на файл при монтировании тома. Secret также используется kubelet'ом при извлечении образов для Pod'а. Secret'ы отлично подходят для хранения конфиденциальных данных, [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) – для неконфиденциальных.
|
||||
|
|
@ -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" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Процессы внутри Pod'а аутентифицируются сервером API и относятся к определенной учетной записи (service account) (например, к `default`) для доступа к кластеру. Если при создании Pod'а служебная учетная запись не указана, ему автоматически присваивается service account по умолчанию в том же {{< glossary_tooltip text="пространстве имен" term_id="namespace" >}}.
|
||||
Loading…
Reference in New Issue