Экспонировать каждый модуль в statefulset в Интернете без собственного прокси

Question

У меня есть StatefulSet с модулями server-0, server-1 и т. Д. Я хочу открыть их напрямую в Интернете с помощью URL-адресов, таких как server-0.mydomain.com или mydomain.com/server-0.

Я хочу иметь возможность масштабировать StatefulSet и автоматически получать доступ к новым модулям из Интернета.Например, если я увеличу его до server-2, я хочу, чтобы mydomain.com/server-2 направлял запросы к новому модулю, когда он будет готов.Я не хочу также масштабировать какой-либо другой ресурс или создавать другую службу для достижения этого эффекта.

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

Есть ли способ заставить Ingress автоматически маршрутизировать к различным модулям в StatefulSet, или какой-то другой встроенный метод, который позволит избежать пользовательского кода?

Answer 1

Сервис Kubernetes - это набор правил iptables (или IPVS), которые перенаправляют пакет с ServiceIP в качестве адреса назначения на ONE OF PODS , которые имеют одинаковую метку.

из Документация по сервисам Kubernetes

Служба устанавливает правила iptables, которые выбирают внутренний модуль.По умолчанию бэкэнд выбирается случайным образом.

Это означает, что служба не может различать разные модули в одном наборе.

Если вы хотите принудительно выбрать конкретный Pod из набора, изменив iprules (довольно просто) или добавив прокси любого типа, проблематично: допустим, вы настроили pod-1 и pod-2 (1.1.1.1 и 1.1.1.2 соответственно), и вы настроили правила iptables для запросов DNAT с назначением от pod-1.myserver.com до 1.1.1.1 и то же для pod-2.(вы можете спросить, почему IP, и это просто потому, что это единственный способ различить эти модули). Этот подход не будет работать всякий раз, когда модуль перезапускается, скажем, сбой модуля 1, Kubernetes не будет воссоздавать тот же модуль с тем же IP иname, вместо этого создаст pod-3 с другим IP и обновит iptables соответственно.В результате все пакеты, идущие к 1.1.1.1, будут отброшены, пока вы не обновите прокси или iptables снова.

Фактически, это одна из причин, по которой мы используем сервис для доступа к модулям вместо прямого доступа к ним, поскольку Pod IP может меняться, а IP службы - нет.

Однако, так как эта очень специфическая часть kubernetes была моей работой в течение последних 4 месяцев, я разработал сценарий python , чтобы редактировать iptables и выбрать конкретный модуль, поэтому мой выводэта работа была дорогостоящей и отнимающей много времени и заставляла сервер отключаться на пару секунд при смене модулей. Вы можете взглянуть на код, он определенно работает, но его не рекомендуется.

Эта проблема является проблемой kubernetes, и решение этой проблемы заключается в изменении исходного кода Kube-proxy, что является моей текущей работой.

Предлагаю вам прочитать мой ответ, объясняющий, как именно службы kubernetes работают в этом вопросе: Какая служба выполняет распределение нагрузки между узлами kubernetes?

Answer 2

Не думаю, что ты сможешь это сделать.Будучи частью одного и того же StatefulSet, все модули, вплоть до pod-x, предназначены для службы.Так как вы не можете определить, какой модуль будет получать запрос, вы не можете принудительно отправить pod-1.yourapp.com или yourapp.com/pod-1.Он будет отправлен службе, и служба может отправить его на pod-4.

Даже если бы вы могли, вам нужно было бы динамически обновлять ваши правила входа, что может легко привести к простоям минут.

С пользовательским прокси я тоже не вижу возможности.Обратите внимание, что это должно было бы в основном заменить службу позади стручков.Если ваш входной контроллер знает, что ему нужно доставить пакет в службу, теперь вы должны заставить его доставить свой прокси.Но как?