Вообще сам nginx умеет конфиг перегружать без остановки. А в реализации

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

Насколько я знаю, именно это и происходит, релоад же. Не рестарт.

Без остановки не умеет, а вот без прерывания текущих запросов может

ну пусть он даже и останавливается, он же там завершает все запросы и только потом гасит процесс, и при этом уже обслуживает новые?! вроде нет проблемы?

Именно что без остановки умеет.

есть, коннекты сбрасываются, но можно поставить таймаут, но они все равно сбросяться после таймаута. Актуально для websocket но даже если не websocket, это довольно дорогая операция, спаун новых процессов, заново tls хэндшейки, и всё это на каждый релоад. А в кубе релоады могут быть частыми из-за динамичности среды. Я даже ловил такое что nginx тупо повис и не отвечал на live пробы после ряда релоадов (аплаились новые ingress'ы), в кластере где были вебсокеты и соотвественно настроен shutdown timeout. Было > 120 процессов в поде и ошибки - не могу за спавнить процесс бла бла бла

Почитайте внимательнее

Nginx reload сто лет в обед. Что именно не умеет без остановки?

Не умеет

Он же воркеры пересоздает, фуфуфу

Ну и пусть, главное без downtime

Так это и есть даунтайм. Вебсокеты рвутся, большие файлы не качаются, вот это всё

nginx reload это и есть остановка, а потом запуск, не умеет он без остановки, почитайте внимательнее про nginx reload

Это разные вещи

а разницу ты почуствуешь когда у тебя будут миллионы соединений, и воркеры не будут заверщаться пока они их не обработают)), и у тебя релоад будет длиться несколько минут))), сразу поймёшь что такое релоад и почему всё таки изменения с остановкой применяются Они применяются без разрыва текущих соединений, это да, но с остановкой

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

а грейсфуллшутдауна вполне хватает на завершение запросов веба, если веб обрабатывает запросы несколько минут, то наверно есть у веба проблемы посерьезнее, чем внезапно прерванный запрос из-за перезапуска воркеров nginx

Отдельные ингрессы для вебсокетов? Это что-то странное

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

Отдельный ингресс чисто для вебсокетов - ИМХО, как раз и есть ошибка архитектуры.

на то оно и имхо

Тебе какая разница, что подменяется, конфиг в памяти или процесс? В конечном итоге какой-то указатель у тебя вначале указывал на одну структуру, потом атомарно поменялся и стал указывать на другую. Меняется только путь, а для конечного пользователя выглядит "одинаково", сначала соединения "видели" один домен, потом стали "видеть" два. А не так, что текущие соединения прервались, потом соединения перестали приниматься, потом стали приниматься с новым конфигом.

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

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

Договорились. Дальше спорить не имеет смысла, вопрос договоренности терминов, что считать перезапуском. В моём понимании перезапуск - это остановка сервиса, в твоём - когда отдельный процесс останавливается и запускается следующий. Опустим подробности, что процессы и потоки в пуле воркеров могут меняться и без команды на релоад.

таким образом роллаут деплоймента - с "остановкой", мы точно хотим именно этот термин использовать?

поподробнее о том что процессы в пуле воркеров могут меняться, я впервые о таком слышу

я не упоминал вообще в данном случае кубер, я дискутировал исключительно на тему nginx

Что будет, если воркер по какой-либо причине сдохнет? Мастер поднимет новый.

верно, но я бы не назвал это штатной ситуацией, по какой причине он сдохнет?* оом? или ошибка в коде? это нифига не штатная ситуация и в таком случае воркер ещё и оборвёт активные с ним соединения

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