[Перевод] Так что же такое под в Kubernetes?

Прим. перев.: Эта статья продолжает цикл материалов от технического писателя из Google, работающего над документацией для Kubernetes (Andrew Chen), и директора по software engineering из SAP (Dominik Tornow). Их цель — доступно и наглядно объяснить основы организации Kubernetes. В прошлый раз мы переводили статью про high availability, а теперь речь пойдет про такое базовое понятие в Kubernetes, как под.

Kubernetes — движок оркестровки контейнеров, созданный для запуска контейнеризированных приложений на множестве узлов, которые обычно называют кластером. В этих публикациях мы используем подход системного моделирования с целью улучшить понимание Kubernetes и его нижележащих концепций. Читающим рекомендуется уже иметь базовое представление о Kubernetes.

Поды (Pods) — базовые строительные блоки Kubernetes, однако даже опытные пользователи Kubernetes не всегда могут объяснить, что же это такое.

Данная публикация предлагает лаконичную мысленную модель, которая проливает свет на определяющие характеристики подов Kubernetes. Ради этой краткости пришлось опустить некоторые другие особенности подов, такие как liveness и readiness probes, разделение ресурсов (включая появившееся недавно namespace sharing — прим. перев.), работу с сетью.

Определение

Под представляет собой запрос на запуск одного или более контейнеров на одном узле.

Под определяется представлением запроса на запуск (execute) одного или более контейнеров на одном узле, и эти контейнеры разделяют доступ к таким ресурсам, как тома хранилища и сетевой стек.

Однако в обиходе термин «под» может употребляться и в смысле этого запроса, и в смысле совокупности контейнеров, которые запускаются в ответ на запрос. Поэтому в публикации мы будем использовать слово «под», когда говорим о запросе, а для второго случая — употреблять выражение «набор контейнеров».

Поды считаются базовыми строительными блоками Kubernetes, потому что все рабочие нагрузки в Kubernetes — например, Deployments, ReplicaSets и Jobs — могут быть выражены в виде подов.

Под — это один и единственный объект в Kubernetes, который приводит к запуску контейнеров. Нет пода — нет контейнера!

Схема 1. Deployment, ReplicaSet, под и контейнеры

Архитектура Kubernetes

Схема 2. Поды, планировщик (Scheduler) и Kubelet

На этой иллюстрации выделены соответствующие объекты и компоненты. Поды представлены как Kubernetes Pod Objects, а работой с ними занимаются:

• планировщик (Scheduler),
• Kubelet.

Объекты Kubernetes

Схема 3. Объекты Kubernetes

На этой иллюстрации показаны объекты Kubernetes, ответственные за работу с подом:

• собственно объект пода (Pod Object);
• объект связывания (Binding Object);
• объект узла (Node Object).

Pod Object задаёт набор контейнеров, которые будут запущены, и желаемую политику перезапуска (restart policy) в случае падения контейнера, а также отслеживает состояние запуска.

Binding Object привязывает Pod Object к Node Object, т.е. назначает под на узел для последующего запуска.

Node Object представляет узел в кластере Kubernetes.

Обработка пода

Схема 4. Обработка пода

Когда под создан пользователем или контроллером вроде ReplicaSet Controller или Job Controller, Kubernetes обрабатывает под в два этапа:

• Scheduler планирует под,
• Kubelet запускает под.

Планирование пода

Схема 5. Управляющий цикл планировщика Kubernetes

Задача планировщика (Scheduler) в Kubernetes — запланировать под, то есть назначить ему подходящий узел в кластере Kubernetes для последующего запуска.

Связывание объекта пода с объектом узла

Под назначается узлу (или связывается с ним) тогда и только тогда, когда есть объект связывания (binding), у которого:

• пространство имён равняется пространству имён пода,
• название равняется названию пода,
• тип цели равняется Node,
• название цели равняется названию узла.

(Любители приключений могут посмотреть на GitHub gist от Kelsey Hightower под названием «Creating and Scheduling a Pod Manually» — пошаговое руководство по созданию объекта связывания вручную.)

Запуск пода

Схема 6. Управляющий цикл Kubelet

Задача Kubelet — запустить под, что по сути означает запуск набора контейнеров пода. Запуск пода Kubelet'ом происходит в две фазы: инициализацию и основную стадию.

Как правило, набор контейнеров на фазе инициализации осуществляет подготовительные работы, такие как подготовку необходимой структуры директорий и файлов. А набор контейнеров на основной фазе выполняет уже «самые главные» задачи.

В обиходе же, хотя это и не совсем корректно, термин «под» зачастую подразумевает набор контейнеров на основной фазе или же ещё более узкое значение «самого главного» контейнера основной фазы.

Схема 7.1. Запуск пода, фаза инициализации (init) и основная фаза (main)

Во время инициализации Kubelet последовательно запускает контейнеры в соответствии со спецификациями пода .Spec.InitContainers и в заданном в списке порядке. Для успешного запуска пода и с учётом политики рестарта, его init-контейнеры должны запуститься и успешно завершиться.

Во время основной фазы Kubelet одновременно запускает контейнеры в соответствии со спецификациями пода .Spec.Containers. Здесь уже для успешного запуска пода и с учётом политики рестарта, его основные (main) контейнеры должны быть запущены и либо успешно завершиться, либо работать неограниченное время.

Схема 7.2. Запуск пода, подробности этого процесса

В случае сбоя у контейнера, когда контейнер прекращает работу с отличным от нуля (0) кодом возврата (exit code), Kubelet может перезапустить контейнер в соответствии с политикой рестарта пода. Эта политика имеет одно из следующих значений: Always, OnFailure, Never.

У политики рестарта пода различная семантика для init-контейнеров и основных контейнеров: если запуск init-контейнеров обязан привести к завершению, то основные контейнеры могут и не завершаться.

Политика рестарта для init-контейнера

Init-контейнер будет перезапущен (т.е. повлечёт за собой запуск нового контейнера с такой же спецификацией) при завершении своей работы только при выполнении следующих условий:

• exit-код контейнера сообщает об ошибке и
• политика рестарта пода имеет значение Always или OnFailure.

Политика рестарта для основного (main) контейнера

Основной контейнер будет перезапущен (т.е. повлечёт за собой запуск нового контейнера с такой же спецификацией) при завершении своей работы только при выполнении следующих условий:

• политика рестарта определена как Always или
• политика рестарта определена как OnFailure и exit-код контейнера сообщает об ошибке.

Схема 8. Пример временной шкалы с красной точкой, символизирующей сбой у контейнера

На иллюстрации показана возможная временная шкала запуска пода с двумя спецификациями init-контейнеров и двумя спецификациями основных контейнеров. Также она показывает создание (в соответствии с политикой рестарта) нового контейнера Main Container 1.2 после проблемы с запуском Main Container 1.1.

Фазы пода

Схема 9. Взаимодействие Kubelet с объектом пода и исполняемой средой контейнера (container runtime)

Kubelet получает спецификации пода .Spec.InitContainers и .Spec.Containers, запускает указанный набор контейнеров и соответствующим образом обновляет значения пода .Status.InitContainerStatuses и .Status.ContainerStatuses.

Kubelet сворачивает .Status.InitContainerStatuses и .Status.ContainerStatuses пода в одно значение — .Status.Phase.

Фаза пода — это проекция состояния контейнеров из набора контейнеров, она зависит от:

• состояний и exit-кодов init-контейнеров,
• состояний и exit-кодов основных контейнеров.

Схема 10. Фазы пода

Ожидание (Pending)

Фаза Pending

Под находится в фазе ожидания тогда и только тогда, когда:

• ни один из init-контейнеров пода не находится в состоянии Terminated с ошибкой (Failure);
• все основные контейнеры пода находятся в состоянии Waiting.

Работает (Running)

Фаза Running

Под находится в фазе работы тогда и только тогда, когда:

• все init-контейнеры пода находятся в состоянии Terminated с успехом (Success);
• хотя бы один основной контейнер пода находится в состоянии Running;
• ни один из основных контейнеров пода не находится в состоянии Terminated с ошибкой (Failure).

Успех (Success)

Фаза Success

Под находится в фазе успеха тогда и только тогда, когда:

• все init-контейнеры пода находятся в состоянии Terminated с успехом (Success);
• все основные контейнеры пода находятся в состоянии Terminated с успехом (Success).

Отказ (Failure)

Фаза Failure

Под находится в фазе отказа тогда и только тогда, когда:

• все контейнеры пода находятся в состоянии Terminated;
• хотя бы один из контейнеров пода находятся в состоянии Terminated с ошибкой (Failure).

Неизвестно (Unknown)

В дополнение к описанным выше фазам под может находиться в неизвестной фазе, что свидетельствует о невозможности определить его текущую фазу.

Сбор мусора для подов

Схема 11. Управляющий цикл сборщика мусора для подов (Pod Garbage Collector)

После того, как под был запланирован и запущен, специальный контроллер в Kubernetes — Pod Garbage Collector Controller — отвечает за удаление объектов подов из хранилища объектов Kubernetes Object Store.

Заключение

Под — базовый строительный блок Kubernetes: под определяется как представление запроса на запуск одного или более контейнеров на одном узле. После того, как под создан, Kubernetes обрабатывает его в два этапа: сначала планировщик (Scheduler) планирует под, а затем — Kubelet запускает его. На протяжении своего жизненного цикла под проходит через разные фазы, сообщая о состоянии — или, точнее говоря, о состоянии своего набора контейнеров — пользователю и системе.

P.S. от переводчика

Читайте также в нашем блоге:

Let's block ads! (Why?)