Балансировка балансировки нагрузки для сервисов с отслеживанием состояния в Kubernetes

Question

В настоящее время я переключаюсь с Service Fabric на Kubernetes, и мне было интересно, как выполнить настраиваемую и более сложную балансировку нагрузки.

До сих пор я уже читал о Kubernetes, предлагающем «Services», которые выполняют балансировку нагрузки для модулей, скрытых позадиих, но это доступно только более простым способом.

То, что я хочу переписать прямо сейчас, выглядит в Service Fabric следующим образом:

У меня есть этот интерфейс:

public interface IEndpointSelector
{
    int HashableIdentifier { get; }
}

Отслеживание контекста учетной записи в моем приложении ASP.Net, например, наследует это. Затем я написал некоторый код, который на данный момент будет выполнять обнаружение сервисов через API кластера сервисной фабрики и отслеживать все сервисы, обновляя их, когда любые экземпляры умирают или возрождаются.

Затем, основываясь на детерминированномХарактер этого идентификатора (из-за того, что контекст кешируется и т. д.) и с учетом нескольких копий целевой службы вызова внешнего интерфейса ->, я могу надежно направлять трафик для определенной учетной записи в определенный экземпляр конечной точки.

Теперь, как бы я поступил так в Kubernetes?

Как я уже упоминал, я нашел "Services", но кажется, что их балансировка нагрузки не поддерживает пользовательскую логику и скорее полезна только при работе сэкземпляры без сохранения состояния.

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

Answer 1

StatefulSet

StatefulSet - это строительный блок для рабочей нагрузки с состоянием в Kubernetes с определенными гарантиями.

Стабильная и уникальная сетевая идентификация

StatefulSet Pod имеет уникальный идентификатор, который состоит из порядкового номера, стабильного сетевого идентификатора и стабильного хранилища.

Например, если ваш StatefulSet имеет имя sharded-svc

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sharded-svc

И у вас есть, например, 3 реплики, которые будут называться <name>-<ordinal>, где порядковый номер начинается от 0 до реплик-1.

Имяваши стручки будут:

sharded-svc-0
sharded-svc-1
sharded-svc-2

, и эти стручки могут быть доступны с помощью имени DNS:

sharded-svc-0.sharded-svc.your-namespace.svc.cluster.local
sharded-svc-1.sharded-svc.your-namespace.svc.cluster.local
sharded-svc-2.sharded-svc.your-namespace.svc.cluster.local

, если ваша служба безголового сообщения названа sharded-svc и вы развернете его в пространстве имен your-namespace.

Sharding или Partitioning

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

Что вы здесь описываете, так это то, что ваша служба с состоянием - это то, что называется sharded или partitioned . Это не выходит из коробки из Кубернетеса, но у вас есть все необходимые строительные блоки для этого вида услуг. Может случиться, что существует сторонняя служба, предоставляющая эту функцию, которую вы можете развернуть, или она может быть разработана.

Sharding Proxy

Вы можете создать службу sharding-proxy, состоящий из одного или нескольких модулей (возможно, из Развертывание , так как он может быть без состояния). Это приложение должно наблюдать за конечными точками pods / service / в вашем sharded-svc, чтобы знать, куда оно может направлять трафик. Это может быть разработано с использованием client-go или других альтернатив.

Этот сервис реализует логику, которую вы хотите использовать в своем шардинге, например, account-nr модуль 3 направляется всоответствующий модуль порядковый номер

Обновление: Существуют сторонние прокси с sharding функциональными возможностями, например, Weaver Proxy

Запрос на разделение, основанный на полях заголовка / пути / тела

Рекомендуемое чтение: Weaver: Простое разделение

Использование службы сегментирования

Чтобы использовать вашу услугу, которую они используют, клиенты отправляют запрос на ваш sharding-proxy, который затем применяет вашу маршрутизацию или логика шардинга (например, запрос с account-nr модуль 3 направляется на соответствующий модуль * (1095 * порядковый номер ) и перенаправляет запрос на копию из sharded-svc, соответствующую вашей логике.

Альтернативные решения

Служба каталогов: Это, вероятно, easier для реализации sharded-proxy в качестве службы каталогов , но это зависит от ваших требований. Клиенты могут спросить вашу службу каталогов , в какую реплику StatefulSet мне следует отправить account-nr X и ваш ответ на запрос, например, sharded-svc-2

Логика маршрутизациив клиенте: Вероятно, самое простое решение - это иметь логику маршрутизации в клиенте и позволить этой логике вычислять, в какую реплику statefulSet отправлять запрос.

Answer 2

Сервисы обычно запускают прокси в пространстве ядра по соображениям производительности, поэтому написание пользовательского кода затруднительно. Cillium позволяет писать программы eBPF для некоторых сетевых функций, но я не думаю, что сервисная маршрутизация является одной из них. Так что это в значительной степени означает работу с прокси пользовательского пространства. Если ваша служба основана на HTTP, вы можете взглянуть на некоторые из существующих контроллеров Ingress, чтобы узнать, достаточно ли они близки или позволяют написать собственную логику маршрутизации сеанса. В противном случае вам придется самому написать демона, чтобы справиться с этим.