Главная » Хабрахабр » [Перевод] Так что же такое pod в Kubernetes?

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

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

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

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

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

Определение

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

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

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

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

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

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

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


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

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

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

Объекты Kubernetes


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

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

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

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

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

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

Обработка pod'а


Схема 4. Обработка pod'а

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

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

Планирование pod'а


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

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


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

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

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

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

Запуск pod'а


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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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


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

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

Фазы pod'а


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

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

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

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

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


Схема 10. Фазы pod'а

Ожидание (Pending)


Фаза Pending

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

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

Работает (Running)


Фаза Running

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

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

Успех (Success)


Фаза Success

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

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

Отказ (Failure)


Фаза Failure

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

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

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

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

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


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

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

Заключение

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Как увидеть черную дыру?

Полученное на прошлой неделе усилиями восьми телескопов и тринадцати институтов изображение черной дыры оказалось размытым и менее интересным, чем рисунки художников, поэтому историческое событие породило множество иногда ехидных мемов (если вдруг не видели: пончик, око Саурона, котик, котики, маркетинг). Как ...

Как Мегафон спалился на мобильных подписках

Уже давно как не смешные анекдоты ходят истории о платных мобильных подписках на IoT устройствах. С Пикабу Всем понятно, что без действий сотовых операторов эти подписки не обходятся. Но операторы сотовой связи упорно утверждают, что это абоненты лохи: оригинал Но ...