Балансировка нагрузки веб-сокетных соединений в Kubernetes с помощью Ingress

Question

Я хочу использовать nginx.ingress.kubernetes.io/upstream-hash-by для сетевых подключений нескольких клиентов, когда связанные клиенты (на основе URL) должны придерживаться одного и того же сервера.

Ingress- nginx, кажется, перебалансирует трафик c когда что-то меняет количество реплик (модуль отключается и будет автоматически заменен новым, или число увеличивается в масштабе времени выполнения).

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

Это мое входное определение:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: websocket-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/upstream-hash-by: "$1"
spec:
  rules:
  - http:
      paths:
      - path: /socket-service/?clients/(.*)/.*
        backend:
          serviceName: websocket-test
          servicePort: 80

Существует ли конфигурация, позволяющая каким-либо образом управлять этим поведением, либо отключая «перебалансировку», либо автоматически прерывая существующие соединения?

Answer 1

Я думаю, что в этом случае вы можете посмотреть в направлении Envoy и Istio .

Возможно, вас заинтересует LoadBalancerSettings.ConsistentHashLB flag:

Согласованная балансировка нагрузки на основе Ha sh может использоваться для обеспечения мягкого соответствия сеанса на основе заголовков HTTP, файлов cookie или других свойств. Эта политика балансировки нагрузки применима только для HTTP-соединений. Привязанность к определенному хосту назначения будет потеряна, если один или несколько хостов будут добавлены / удалены из службы назначения.

С Envoy Поддерживаемые балансировщики нагрузки - ring-ha sh документация

В распределителе нагрузки ring / modulo ha sh реализовано согласованное хеширование для вышестоящих хостов. Каждый хост отображается на круг («кольцо») путем хеширования его адреса; затем каждый запрос направляется на хост путем хеширования некоторого свойства запроса и поиска ближайшего соответствующего хоста по часовой стрелке вокруг кольца. Этот метод также широко известен как хеширование «Ketama», и, как и все балансировщики нагрузки на основе ha sh, он эффективен только при использовании маршрутизации протокола, которая задает значение ha sh on.

Каждый хозяин хэшируется и помещается на ринг несколько раз пропорционально его весу. Например, если хост A имеет вес 1, а хост B имеет вес 2, то в кольце может быть три записи: одна для хоста A и две для хоста B. На самом деле это не обеспечивает желаемых 2: 1 разбиение круга, однако, поскольку вычисленные хэши могут совпадать очень близко друг к другу; поэтому необходимо умножить количество хэшей на хост - например, вставить 100 записей в кольцо для хоста A и 200 записей для хоста B - чтобы лучше аппроксимировать желаемое распределение. Рекомендуется явно устанавливать значения Minimum_ring_size и Maximum_ring_size и контролировать датчики min_hashes_per_host и max_hashes_per_host для обеспечения хорошего распределения. При правильном разделении кольца добавление или удаление одного хоста из набора из N хостов повлияет только на запросы 1 / N.

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