настраиваемая балансировка нагрузки в пределах kubernetes - PullRequest
0 голосов
/ 07 июня 2018

Я пытаюсь развернуть приложение с балансировкой нагрузки в kubernetes.

Ниже приведена моя схема развертывания

enter image description here

в идеалеприложение разворачивается с помощью набора модулей с использованием развертывания k8s с типом «backend»

, обычно пользовательские экземпляры хранятся в архиве.и динамически восстанавливаются в один из модулей по запросу, остаются там в течение времени TTL (скажем, 30 минут), а также удаляются и резервируются в архив.

в идеале баланс нагрузки развертывается набором модулейиспользуя развертывание k8s с типом "frontend".

в идеале интерфейс настраивается как сеанс layer7, привязанный к "sticky = host".хост равен UID бэкэнда pod

, пользователь запрашивает сервис с помощью сообщения SOAP, которое содержит параметры "host" и "user" в своем теле.

при достижении сообщения SOAPво внешнем интерфейсе значение «host» извлекается из тела сообщения.

если значение «host» является допустимым, сообщение SOAP пересылается в соответствующий модуль бэкэнда (UID которого равен значению хоста).в противном случае назначается случайный внутренний модуль.

(обработка здесь зависит от приложения). В модуле бэкэнда приложение проверяет доступность пользовательского экземпляра по значению «user».

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

Я искал вокруг и не нашел подобных примеров.особенно липкая конфигурация сеанса layer7, и реализация пользовательского получения липкого значения из тела входящего сообщения.

1 Ответ

0 голосов
/ 19 июля 2018

Это звучит как сценарий использования, когда вы выполняете аутентификацию через внешний балансировщик нагрузки.Вы смотрели на Истио и посла.Похоже, что Istio и Envoy могли бы предоставить сервисную сетку для маршрутизации запросов к модулям.Затем вам нужно будет написать собственный модуль плагина в Ambassador, чтобы создать конкретный механизм маршрутизации и аутентификации, который вы ищете.

Пример службы нестандартной аутентификации Ambassador: https://www.getambassador.io/user-guide/auth-tutorial

https://www.getambassador.io/user-guide/with-istio

Эту настраиваемую маршрутизацию сессионного сеанса также можно выполнять с использованием других шлюзов API, но все еще используя Istio для маршрутизации на другие модули.Однако было бы лучше, если бы модули определялись как отдельные службы, чтобы упростить сегментацию с помощью шлюза API (Ambassador, Kong, Nginx) на основе параметров тела сообщения.

...