Сервис OpenShift с sessionAffinity перенаправляет трафик на два модуля

Контейнерная платформа OpenShift 3.11

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

  apiVersion: v1
  kind: Service
  metadata:
    name: server
  spec:
    ports:
    - name: "8200"
      port: 8200
      targetPort: 8200
    selector:
      test.service: server
    sessionAffinity: ClientIP
    sessionAffinityConfig:
      clientIP:
        timeoutSeconds: 10800 # default

Настройка клиентских и серверных модулей

sessionAffinity: ClientIP указывает, что до тех пор, пока у клиента один и тот же IP-адрес, его запросы перенаправляются на один и тот же серверный модуль (кроме случаев, когда достигнут тайм-аутSeconds). Эта установка работала, как ожидалось, в течение нескольких месяцев, пока внезапно запросы не распределились между двумя серверными модулями. Перезапуск клиентского модуля временно решил проблему, и запросы перенаправлялись на один серверный модуль только в течение некоторого времени. Однако через несколько дней та же проблема возникла снова.

Мой вопрос: есть ли что-нибудь, касающееся служб OpenShift и sessionAffinity: ClientIP, что объясняет, почему запросы от одного и того же клиента с неизмененным IP-адресом могут внезапно распределяться между двумя модулями серверов?


Некоторый дополнительный контекст:

Клиентский модуль получает токен сеанса (а не файл cookie) при подключении к серверному модулю. Маркер сеанса кэшируется внутри серверного модуля, но не используется совместно между серверными модулями. Следовательно, когда клиент подключается к другому серверу, он получит разрешение, запрещенное для токена сеанса. Затем клиент запрашивает новый токен сеанса. Если запросы клиента перенаправляются на один и тот же серверный модуль, и только иногда сервер изменяется (например, из-за того, что первый сервер вышел из строя), вышеуказанная настройка работает нормально. Однако, если запросы клиента распределяются между двумя или более серверами, токен сеанса будет недействительным при каждом втором или третьем запросе.


person user3252254    schedule 29.07.2020    source источник


Ответы (1)