#kubernetes #kubernetes-pod
#kubernetes #kubernetes-pod
Вопрос:
Кто-нибудь, пожалуйста, объясните мне (или направьте на подробный ресурс), почему kubernetes использует эту оболочку (pod) для работы с контейнерами. Каждый ресурс, с которым я сталкиваюсь, просто цитирует одни и те же слова — «это наименьшая единица в k8s». То, что я ищу, является причиной этого с инженерной точки зрения. Я понимаю, что он предоставляет пространство имен для хранения и сетевого взаимодействия для контейнеров внутри, но наилучшей практикой в любом случае является хранение одного контейнера в модуле.
Я много использовал docker-compose до того, как ознакомился с k8s, и мне трудно понять необходимость этого дополнительного слоя (оболочки) вокруг довольно простой сущности, контейнера.
Ответ №1:
Причина этого решения заключается просто в том, что модуль может содержать более одного контейнера, выполняющего разные функции.
Прежде всего, модуль может иметь init-контейнер, который отвечает за выполнение некоторых начальных операций, чтобы гарантировать правильную работу основного контейнера / контейнеров. Я мог бы загрузить в init-контейнер некоторую конфигурацию и подготовить ее для основного приложения или выполнить некоторые базовые операции, такие как восстановление резервной копии или аналогичные вещи.
В принципе, я могу ввести ряд операций в exec перед запуском основного приложения, не создавая заново образ контейнера основного приложения.
Во-вторых, даже если большинство приложений прекрасно работают с одним контейнером для Pod, существует несколько ситуаций, когда может быть полезно использовать более одного контейнера в одном Pod.
Примером может быть запуск основного приложения, а затем дополнительный контейнер, выполняющий прокси-сервер перед основным приложением, возможно, отвечающий за проверку токенов JWT.. или другим примером может быть вторичное приложение, извлекающее метрики из основного приложения или аналогичные вещи.
И последнее, позвольте мне процитировать документацию Kubernetes (https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)
Основная причина, по которой модули могут иметь несколько контейнеров, заключается в поддержке вспомогательных приложений, которые помогают основному приложению. Типичными примерами вспомогательных приложений являются съемники данных, толкатели данных и прокси. Вспомогательным и основным приложениям часто требуется взаимодействовать друг с другом. Обычно это делается через общую файловую систему, как показано в этом упражнении, или через сетевой интерфейс с обратной связью localhost. Примером этого шаблона является веб-сервер вместе с вспомогательной программой, которая опрашивает репозиторий Git на предмет новых обновлений.
Обновить
Как вы сказали, инициализируйте контейнеры.. или несколько контейнеров в одном модуле не являются обязательными, все функции, которые я перечислил, также могут быть получены другими способами, такими как точки входа или два отдельных модуля, взаимодействующих друг с другом, вместо двух контейнеров в одном модуле.
В использовании этих функций есть несколько преимуществ, поэтому позвольте мне еще раз процитировать документацию Kubernetes (https://kubernetes.io/docs/concepts/workloads/pods/init-containers /)
Поскольку init-контейнеры имеют отдельные изображения от контейнеров приложений, они имеют некоторые преимущества для кода, связанного с запуском:
Контейнеры инициализации могут содержать утилиты или пользовательский код для настройки, которых нет в образе приложения. Например, нет необходимости создавать изображение ИЗ другого изображения только для того, чтобы использовать такие инструменты, как sed, awk, python или dig во время установки.
Роли разработчика образов приложений и разработчика развертывания могут работать независимо друг от друга без необходимости совместного создания единого образа приложения.
Контейнеры инициализации могут работать с другим представлением файловой системы, чем контейнеры приложений в том же модуле. Следовательно, им может быть предоставлен доступ к секретам, к которым контейнеры приложений не могут получить доступ.
Поскольку init-контейнеры завершаются до запуска любых контейнеров приложений, init-контейнеры предлагают механизм блокировки или задержки запуска контейнера приложений до тех пор, пока не будет выполнен набор предварительных условий. После выполнения предварительных условий все контейнеры приложений в модуле могут запускаться параллельно.
Контейнеры инициализации могут безопасно запускать утилиты или пользовательский код, которые в противном случае сделали бы образ контейнера приложения менее безопасным. Сохраняя ненужные инструменты отдельно, вы можете ограничить область атаки изображения контейнера вашего приложения
То же самое относится к нескольким контейнерам, работающим в одном модуле, они могут безопасно взаимодействовать друг с другом, не передавая это сообщение другим в кластере, потому что они сохраняют его локальным.
Комментарии:
1. большое вам спасибо за ваш подробный ответ! Я понял варианты использования, но мне это все еще кажется чрезмерным. Задание инициализации — это в значительной степени команда точки ВХОДА в docker world, где я могу предоставить подготовленный сценарий, среди прочего. Конечно, это не сработало бы, если инициализация выполняется для нескольких контейнеров (но я действительно не вижу случая «нет другого способа сделать это», чтобы поместить много в один). В случае дополнительного вспомогательного контейнера для меня имеет смысл сделать его отдельным сервисом. Я был бы признателен за дополнительные соображения 🙂
2. «В случае дополнительного вспомогательного контейнера для меня имеет смысл сделать его отдельным сервисом» — гарантируется, что два контейнера в одном модуле всегда будут планироваться вместе на узле и, таким образом, могут совместно использовать один и тот же объем (что невозможно, когда модули получают расписание на разных узлах). Они также используют один и тот же сетевой интерфейс и могут взаимодействовать с помощью интерфейса обратной связи, что значительно ускоряет обмен данными между контейнерами (что может потребоваться в некоторых случаях). В документах k8s написано, что вы должны думать о модуле, подобном виртуальной машине, которая имеет свои собственные процессы, сетевые интерфейсы и дисковые тома
3. В дополнение к тому, что сказал @Matt, я также обновил свой ответ, добавив еще несколько преимуществ функциональности.