Динамическая маршрутизация с отслеживанием состояния (межсервисная привязка) в Kubernetes / Istio

У меня есть ReplicaSet общей микрослужбы Java («служба БД»), которая может взаимодействовать с любой базой данных JDBC на основе метаданных. Когда вышестоящая микрослужба вызывает эту микрослужбу БД, она выделяет пул соединений JDBC. Допустим, администратор базы данных предоставил мне 50 подключений для работы с конкретным вариантом использования (некоторая единица развертывания метаданных, которую моя система может «выполнить»).

Я хотел бы иметь две реплики БД, каждая из которых создает 25 подключений (MAX / 2) в локальном пуле подключений. Отныне вышестоящая микрослужба теперь должна направлять свои вызовы только этим двум репликам, которые теперь содержат эти 2 пула соединений, минуя другие реплики X DB, которые не создавали никаких соединений.

Если вышестоящая микрослужба добавляет заголовок HTTP, уникальный для этого варианта использования («StatefulRoute = ConnectionName»), можно ли обмануть K8s и / или Istio, чтобы направить запрос к подмножеству реплик БД, которые создали эти локальные пулы соединений JDBC для этот вариант использования?

Обратите внимание, что многие другие варианты использования могут быть развернуты пользователем с течением времени, каждый вариант использования потенциально также требует подключения JDBC. Эти варианты использования следует распространить на другие реплики БД на основе проверок готовности уже занятых реплик БД.

Я представляю себе дополнительную микрослужбу Resource Manager (проводник), с которой каждая реплика БД будет взаимодействовать, чтобы спрашивать: 1) могу ли я выделить пул соединений для этого запроса, 2) сколько соединений я могу выделить.

Когда самая первая (неинициализированная) реплика БД получает новый запрос (маршрут еще не установлен), она взаимодействует с диспетчером ресурсов. Этот менеджер, в свою очередь, должен затем динамически настроить K8s / Istio (вызов REST?) Для маршрутизации запросов (для конкретного варианта использования) к этой реплике.

Resource Manager будет Singleton или, если он станет узким местом, ReplicaSet, использующим распределенный кеш для отслеживания «грантов пула соединений». Если у него заканчиваются соединения, он будет пинговать реплики БД, которые долгое время не отправляли сердцебиение (мог быть перезапущен K8s). Если он обнаружит, что одна реплика не отвечает, он позволит новой реплике выделить пул соединений на основе оставшихся доступных соединений (на стороне базы данных).

Если все ранее инициализированные реплики все еще активны и обслуживают запрос (и, таким образом, максимальное количество физических подключений к базе данных используется), менеджер отклонит запрос на подключение, и запрашивающая реплика базы данных вернет ошибку («больше подключений для запрос на обслуживание ") к вышестоящему микросервису.

Кто нибудь сталкивался с этим требованием?

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

Спасибо.


kubernetes istio routes stateful affinity
person Bo Stern    schedule 16.05.2020    source источник
comment
Если я правильно вас понял, вы спрашиваете, может ли istio отправлять запросы с заголовком StatefulRoute=ConnectionName, скажем, для версии 1 вашего модуля?   -  person Jakub    schedule 18.05.2020
comment
Да, каким-то образом мне нужно динамически создать подмножество дистрибутива для версий моего модуля, которые создали пул соединений с отслеживанием состояния. Например, Connection1DB2 будет перенаправлен на версии 1 и 3, а Connection2Oracle будет перенаправлен на версии 2 и 4 - если указанные версии обслужили начальный (перенаправленный случайным образом) запрос и, таким образом, стали бы выбранными для создания пулов соединений. Поскольку я никогда не знаю, какие варианты использования (потоки программ) пользователь будет «развертывать» в кластере, я не могу заранее настроить что-либо из этого. Спасибо.   -  person Bo Stern    schedule 18.05.2020
comment
Я изучаю этот вариант: istio.io/docs/ ссылка / config / сеть / правило назначения /   -  person Bo Stern    schedule 19.05.2020

Ответы (1)


arrow_upward
0
arrow_downward

Если вы хотите настроить маршрутизацию трафика istio, есть несколько ссылок, по которым можно перейти.

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

Затем следуйте этой документации istio о маршрутизации запросов, в ней объясняется, как вы настраиваете свои виртуальные службы и правила назначения, чтобы они соответствовали правильным подмножествам ваших модулей.

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

Взгляните на этот пример

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  ...
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Итак, у нас есть 3 подмножества развертывания обзора, v1, v2 и v3, а также сервис для них. Вы можете посмотреть здесь, как он построен, каждое развертывание для проверки имеет ярлык приложения и версии, которые мы можем использовать в наших правилах виртуального сервиса и назначения.

kubectl get pods
reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

kubectl get services
reviews                    10.0.0.170   <none>        9080/TCP             6m

Как видно из приведенного выше виртуального сервиса, если есть пользователь с именем конечного пользователя, которое точно соответствует jason, то он отправляет весь трафик на v2, если нет, то по умолчанию он отправляет все на v1.

person Jakub    schedule 19.05.2020
comment
Спасибо за предложение! - person Bo Stern; 21.05.2020