то есть, можно разделить сорсы на "редко меняющиеся" и "часто меняющиеся" на два слоя. Только а) нужна для этого хорошая эвристика и б) когда "редко меняющиеся" сорсы поменяются то все равно придется качать много
Можно слои разделить на зависимости и свой код. Бывает что зависимости дофига занимают в php/js
Так при изменении количества реплик (например при масштабировании), у тебя из-за этого: 1) новые реплики будут подниматься долго 2) если ты там еще будешь приложение собирать в initContainers это все будет кушать CPU и память при старте пода
+ все эти телодвежения в контейнере при старе ведут к менее повторяймому коду (вдруг сборка внезпано пройдет как-то не так, и будем ловить баги, что в одном поде при старте что-то собралось неправильно). Одно дело когда у тебя один раз собран образ и он раскатывается - просто и надежно.
Ну и кластеры тоже бывают разными. В моих кластерах например стоит политика readOnlyRootFilesystem: true, и пришлось бы вам еще больней с такмими телодвижениями жить, юзать emtyDir и тому подобное
Если приложение с базой не держит кипалайва, то ipvs дропает через 15 минут (по дефолту) соединение по неактивности. Причем дропает только у себя, обе стороны об этом не знают. Если посмотреть tcpdump, то видно, что в рамках уже открытого соединения приложение шлет пакет, а он отбивается RST, потому что такого открытого в ipvs уже нет.
Если приложение с базой не держит кипалайва, то ipvs дропает через 15 минут (по дефолту) соединение по неактивности. Причем дропает только у себя, обе стороны об этом не знают. Если посмотреть tcpdump, то видно, что в рамках уже открытого соединения приложение шлет пакет, а он отбивается RST, потому что такого открытого в ipvs уже нет.
15 минут это много. У меня инициализация базы данных приложения идет минуту. При этом после 15 секунд инициализации я вижу ошибки.