Как однозначно обратиться к «процессу» в контейнеризованном мире?

Question

Это общий вопрос, но ради аргументов вы можете и предположить, что у нас есть набор процессов, взаимодействующих через комбинацию AMQP и HTTP.Необходимо рассмотреть два конкретных случая.

Самый простой:

• Q) Если A отправляет сообщение B, как B определяет местоположение A для отправки ответа.
• A) A должен указать B, куда как-то его отправить (обмен на AMQP, URL на http)

Более сложные:

• Q) Какотправляет ли процесс мониторинга сообщение A (где что-то еще вызвало это желание - например, B говорит, что A отправил мне неверный запрос)

• Q) Как процесс мониторинга убивает или перезапускает A.

  Это может быть что-то вроде уничтожения хоста + pid или pod или pod + container

  (см., Например, kubernetes restart container in pod )

  Возможно, вы захотите перезапустить весь сервис или некоторое подмножество процессов, предоставляющих этот сервис.

Теперь вы можете назначить UUID самостоятельно, но вам нужна таблица для его сопоставления.У него может быть несколько столбцов, но иногда один URI (или URI-подобный объект) полезен, например, как адрес «возник из / ответить на».

---

Другой способ просмотра этого вопроса.В старые времена было легко идентифицировать процесс.

Имя хоста (или IP-адрес) + PID было достаточно

Затем пришла виртуализация, IP-адрес идентифицирует виртуальный сетевой порт, назначенный дляVM и PID идентифицируют процесс внутри него.Имя хоста и IP-адрес все еще достаточно.Иногда вам также нужен vhost (хотя я никогда не понимал, почему)

Теперь при добавлении контейнеров в смесь контейнер не обязательно имеет собственный IP-адрес. host + pid может идентифицировать контейнер Но вы можете не знать хост, если вы используете kubernetes или docker swarm.

Теперь мы больше не столько говорим о процессах, сколько о сервисах,Раньше было достаточно для идентификации службы с использованием имени хоста (или IP-адреса) и порта (YMMV - . Может ли IP-адрес и номер порта вместе однозначно идентифицировать идентификатор процесса? ).

Теперь у нас есть балансировщики нагрузки и другие приемы (например, кэширование прокси-серверов) для перенаправления сообщений на что-то, что фактически предоставляет услугу.

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

Так что есть несколько разных способов адресации сообщения.Есть ли хороший стандартный способ сделать это?

На мой взгляд, очевидная вещь для использования - это URI (но я могу ошибаться).Существуют ли рекомендованные формы URI для обработки всех возможных случаев?(очевидно, у нас есть procotocl : // host : port / для простых случаев)

Answer 1

После некоторого рассмотрения я считаю, что host + pid все еще достаточно (но не обязательно лучший способ) для определения процесса, если вы помните следующее:

• чей PID вы имеете в видуможет быть неоднозначным.Это может быть PID пространства имен контейнера или хоста.

• Если вы обращаетесь к процессу извне контейнера, вам нужно использовать PID хоста, а не PID, так какпоявляется внутри контейнера, так как он находится в отдельном пространстве имен процесса.См., Например, the-curious-case-of-pid-namespaces

• Контейнер может быть способен идентифицировать хост и сам PID (в конце концов, этопредполагается, что это песочница)

• IP-адреса будут относиться к внутренней сети (как обычно)

• имена хостов будут проходить через поиск DNS (как обычно)

Теперь URI относится к порту, а не к PID, поэтому URI здесь не подходит.PID @ HOST, вероятно, является разумной нотацией, но остерегайтесь путаницы с user@host.

Помимо идентификаторов контейнеров и контейнеров, существуют и другие более удобные способы определения ресурса обработки, такие как наборы с отслеживанием состояния