по лоад балансерах?
Например, когда ищу external-front-ip/dev/api перекидывать на external-back-ip/dev/api?
под редиректом что имеется в виду? 301/308/307 ответ для клиента? Или прозрачный для клиента?
Редиректнуть на другой сервис
я не понимаю что технически вы имеете в виду. Можно например редирект сделать на уровне http 301/308/307 ответом клиенту с другим Location Можно тупо запрос перенаправить на нужный бэкенд, на стороне reverse proxy
У меня фронт на js и заглянуть внутрь кубера не может
а зачем ему заглядывать внутр куба?
Ты что-то совсем тут запутал. Фронт и бек живут оба в кубере?
фронт живет в браузере у пользователя. В кубе мб статика хостится
О том и речь. Статика сама собой не материализуется и должна где-то жить
да, но когда мы говорим о запросах с фронта на бэк. Нам не надо думать где живет статика. Нам лишь надо думать о том, что пользователь из фронта (браузера) делает запросы в бэкенд (который в кубе)
Это один из кейсов, а если на фронте nginx статику раздает, например? И там есть location, который будет по пути проксировать запросы на указанный бекенд?
это все равно запросы из фронта (браузера клиента) куда-то. Разницы нет как там они уже внутри ходят
Есть конечно. Редирект тебя отправит в бек и тогда нужна связность сетевая от тебя до бека, а проксирование тебе позволит не вытаскивать бек наружу
проксировать location из nginx на бэк - это такая же связность. Только через дополнительынй reverse proxy. Это тоже самое архитектурно практически. Бэкенд точно также доступен из вне
Почему? Ты в nginx (если он в кубе) можешь легко указать clusterIP и тогда бек доступен только в оверлее будет
ну дык какая разница с точки зрения фронта? Ну ходишь ты на backend.example.com или на example.com/backend ? Это такой же доступный бэкенд из вне
С точки зрения фронта пох. С точки зрения архитектуры разница имеется
допонительное проксирование. Не вижу особой разницы
Обсуждают сегодня