По крайней мере - не в 100% случаев

++++

у меня кстати была ситуация. Прилетела задача - добавить Access-Control-Allow-Origin. И прогеру прилетела задача сделать тоже самое.  И мы оба сделали, я на балансировщике, он на бэкенде. В итоге получили дублирующийся Access-Control-Allow-Origin. А многие браузеры ой как такое не любят, и часть запросов сломалась.
С тех пор, любые заголовки, которые требуются приложению выставляются в нем же. А на балансировщике только всякая мета информация, которая приложением не используется, или не влияет на его работоспособность.

Спасибо, в ПН на планерке пну нодеров, пусть поправят))))

Часто люди не понимают разницы между вебсервером и реверс прокси. И если у вас нджинкс работает в режиме вебсервера, то приложение не всегда получает все запросы (отдача статики шлёт привет). Поэтому иногда установку некоторых заголовков приходится выносить в вебсервер

Только аргументов собери - почему плохо так делать

Начинаю новую серию идиотских вопросов ))))) Теперь сертификаты.
Подскажите, сейчас у меня есть кластер Кубера, что я вчера собрал с помощью RKE..... Кластер находится внутри локалки, с серыми айпишниками, естественно. Снаружи, из инета, прямого доступа к кластеру и его сервисам нет, есть только из локалки. Если мне нужен будет какой-то доступ извне к сервисам Кубера, он будет происходит с помощью редиректов главного вышестоящего проксирующего Nginx......
В связи с этим вопрос: RKE устанавливаясь нагенерил самоподписанных сертификатов для Кубера. Надо ли прокидывать, именно для кластера как такогого, какие то доменные имена и нужно ли для кластера как-то генерить сертификаты Let's Encrypt?

доступ снаружи только тебе для управления кластером или другим человекам в какие то приложения в этом кластере?

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

предполагаю, что все вопросы проброса порта к мастеру или проксированию https с сертификатами это просто системное администрирование. сертификат можно положить в nginx, который пойдет в кластер кубера на адрес:порт приложения

для управления конечно лучше впн себе подними и будь как дома в лане

внутри кластера самоподписанные серты используются, там и не нужны другие

идея тут в том, что доступ к кластеру извне как правило закрыт и нужен только внутри, поэтому и не нужно использовать внешние удостоверяющие центры и вот это всё

это решается ингрессом

ага! вопрос с сертами именно для кластера снят, спасибо!
Теперь по поводу приложений и ингресса. Сейчас у нас в конторе принят такой порядок действий, если нужно опубликовать какой-то сервис в инете:
- создается необходимое доменное имя (если оно нужно), запись ДНС смотрит на на главный проксирующий нгинкс.
- на проксирующем нгинксе создается редирект указанного доменного имени на внутренний айпишник с переключением на HTTPS
- на этом же нгинкс с помощью CertBot генерируется сертификат под это доменное имя, котороый и покрывает это соединение.

Как эта схема должна измениться (если вообще должна) в случае приложения, размещенного в Кубере, имеется ввиду в связке с ингрессом?

тебе ингресс не нужен

ты можешь с прокси нгинкс лить трафик напрямую в кубер

+1 ))

А зачем тебе серт если он геениртся на внешнем нджинксе? Внутри ходи по хттп а тои вообще выкидывай service

смотря на каком этапе тебе нужно терминировать SSL