Как настроить липкость балансировки нагрузки для Confluent Rest-Proxy
У меня есть настройка 3 экземпляров Rest-Proxy(Kafka-rest) в Kubernetes.
https://docs.confluent.io/current/kafka-rest/docs/index.html
https://github.com/confluentinc/kafka-rest
Я добавил NetScaler Ingress поверх развертывания.
В документах Citrix NetScaler я вижу, что NetScaler предоставляет постоянные конфигурации для обеспечения стабильности сеанса.
Документы Citrix для постоянства NetScaler
В документах Кафка-Отдых упоминается:
Прокси-кластеры REST и балансировка нагрузки. Прокси-сервер REST предназначен для поддержки нескольких экземпляров, работающих вместе для распределения нагрузки, и его можно безопасно запускать за различными механизмами балансировки нагрузки (например, циклический DNS, службы обнаружения, балансировщики нагрузки), если экземпляры настроены правильно,
А также
Хотя прокси-сервер не имеет постоянного состояния, он является состоянием, поскольку экземпляры потребителей связаны с конкретными экземплярами прокси.
Однако я перепробовал все возможные комбинации из конфигураций. Но все же некоторые из моих данных потребляют запросы в Rest-Proxy.
Я получаю ошибку HTTP 404.
Может ли кто-нибудь подсказать мне, какой тип сессионной липкости нужен Rest-Proxy и как я могу реализовать это в NetScaler в kubernetes.
ОБНОВИТЬ:
Я также нашел этот текст, в котором говорится, что мы должны использовать "base_uri", возвращаемый вызовом create rest rest. Теперь мой вопрос заключается в том, должны ли мы использовать его явно в оставшихся вызовах для потребления данных вместо URL-адреса балансировщика нагрузки или следует настроить липкость в балансировщике нагрузки, чтобы учесть возвращенный URL-адрес и соответственно отправить следующие запросы (если это даже возможно)
Если вы запускаете более одного экземпляра прокси-сервера, вы должны предоставить механизм балансировки нагрузки. Самые простые подходы используют циклический перебор DNS или службу обнаружения для выбора одного экземпляра на процесс приложения при запуске, отправляя весь трафик этому экземпляру. Вы также можете использовать балансировщик нагрузки HTTP, но отдельные экземпляры должны по-прежнему быть адресуемыми, чтобы поддерживать абсолютные URL-адреса, возвращаемые для использования в операциях чтения и смещения при приеме.