У меня есть настройка 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 Proxy и балансировка нагрузки - REST Proxy разработан для поддержки нескольких экземпляров, работающих вместе для распределения нагрузки, и его можно безопасно запускать за различными механизмами балансировки нагрузки (например, DNS с циклическим перебором, службы обнаружения, балансировщики нагрузки) до тех пор, пока экземпляры настроены правильно.
И
Хотя прокси-сервер не имеет постоянного состояния, он является состоянием, поскольку экземпляры потребителей связаны с конкретными экземплярами прокси.
Однако я попробовал все возможные комбинации из конфигураций. Но все же некоторые из моих данных потребляют запросы в Rest-Proxy.
Я получаю ошибку HTTP 404.
Может ли кто-нибудь подсказать мне, какой тип поддержки сеанса необходим Rest-Proxy и как я могу реализовать это в NetScaler в kubernetes.
UPDATE:
Я также нашел этот текст, в котором говорится, что мы должны использовать "base_uri" , возвращаемый вызовом create rest rest. Теперь мой вопрос заключается в том, должны ли мы использовать его явно в оставшихся вызовах для потребления данных вместо URL-адреса балансировщика нагрузки или следует настроить липкость в балансировщике нагрузки, чтобы учесть возвращенный URL-адрес и соответственно отправить следующие запросы (если это даже возможно)
Если вы запускаете более одного экземпляра прокси-сервера, вы должны предоставить некоторый механизм балансировки нагрузки. Самые простые подходы используют циклический перебор DNS или службу обнаружения для выбора одного экземпляра на процесс приложения при запуске, отправляя весь трафик этому экземпляру. Вы также можете использовать HTTP-балансировщик нагрузки, но отдельные экземпляры должны по-прежнему быть адресуемыми, чтобы поддерживать абсолютные URL-адреса, возвращаемые для использования в операциях чтения и смещения при приеме.