Спасибо за статью! Как раз сейчас тоже разбираюсь с возможностями Openresty + Lua и материал статьи прям пришелся к моменту. Такой вопрос: в приведенных примерах используется вывод в лог с помощью например такой конструкции: "ngx.log(ngx.INFO, "Маршрутизируем URI: ", uri, " к ", ngx.var.target)". Но куда будет выведена эта запись? В моих экспериментах в докере если я использую аналогичный вывод в лог то записи нет в docker logs .. . Видимо нужно дополнительно настроить вывод?
Спасибо за комментарий! CNI плагинов много (и они по моему мнению больше про кластеры с больше чем одним worker'ом) и исследование их возможностей, плюсов и минусов это тема для отдельной статьи, которая я надеюсь будет. В данном случае как раз было интересно посмотреть ситуацию без них.
Про переключение контекста и возрастающие "сопутствующие" системные нагрузки при увеличении количества подов - в целом согласен, я тут как раз о возрастающем сетевом оверхеде и пытался разобраться и рассказать (остальные оверхеды решил оставить за рамками, что бы статья не разрасталась). Но эти оверхеды появляются при любом увеличении подов или процессов. Идея в том что если вдруг нужно запустить больше 110 подов, например 111 - то это можно сделать и ни чего плохого не будет. А вот если хочется запустить 1000 тут нужно все оценить и протестировать на реальных приложениях, нагрузках и кейсах.
Спасибо за статью! Как раз сейчас тоже разбираюсь с возможностями Openresty + Lua и материал статьи прям пришелся к моменту. Такой вопрос: в приведенных примерах используется вывод в лог с помощью например такой конструкции: "
ngx.log(ngx.INFO, "Маршрутизируем URI: ", uri, " к ",ngx.var.target)". Но куда будет выведена эта запись? В моих экспериментах в докере если я использую аналогичный вывод в лог то записи нет в docker logs .. . Видимо нужно дополнительно настроить вывод?Спасибо за комментарий!
CNI плагинов много (и они по моему мнению больше про кластеры с больше чем одним worker'ом) и исследование их возможностей, плюсов и минусов это тема для отдельной статьи, которая я надеюсь будет. В данном случае как раз было интересно посмотреть ситуацию без них.
Про переключение контекста и возрастающие "сопутствующие" системные нагрузки при увеличении количества подов - в целом согласен, я тут как раз о возрастающем сетевом оверхеде и пытался разобраться и рассказать (остальные оверхеды решил оставить за рамками, что бы статья не разрасталась). Но эти оверхеды появляются при любом увеличении подов или процессов. Идея в том что если вдруг нужно запустить больше 110 подов, например 111 - то это можно сделать и ни чего плохого не будет. А вот если хочется запустить 1000 тут нужно все оценить и протестировать на реальных приложениях, нагрузках и кейсах.
А разве что то такое же как bridge в ядро завезли?
Ох, косяк мой. Спасибо что заметили.