Если я правильно понял по коду, то он отталкивается от статических данных, а не от текущей нагрузке на ноду. Это не спасает когда у нас 10 подов на одной ноде жрет ресурсов больше чем 20 на другой. При равной конфигурации. Но в теории можно дописать туда своих алгоритмов ))
У нас поды без трафика, это демоны которые крутятся все время. Но идея с лейблами годится, тогда контроллер поднимет новые, а уже потом можно из вне прибить старые.
Да исходники я уже тоже нашел и полез изучать ) Похоже все же надо будет ставить себе Го
А где можно прочесть про этот LeastRequestedPriority? Просто отстрелить их не получится, так как нужно без даунтайма это делать. Но если я правильно понял то и ролинг-апдейт тут подойдет.
Мы хотим оверселить ресурсы, и поймать момент когда пора скейлить инфраструктуру и переносить клиентов на новые ноды. Сразу предвидеть нагрузку нет возможности, так как все зависит от частного случая каждого клиента. А держать сервера в простое тоже не хочется.
Интересует вопрос миграции подов. Допустим система управления приняла решение разгрузить одну из нод, и должна выселить с ноды 30% подов. Как это возможно реализовать? Пока расматриваю 2 варианта:
Переводим ноду в статус unschedulable и запускаем rolling-update для репликейшен контроллеров которые имеют поды на необходимой ноде. Таким образом RC заменит поды по очереди, и стартанет их уже в новом месте
Настроить жеский контроль по лейблам, и так же ролинг апдейтом перемещать поды с ноды на ноду
Видимо вы плохо знакомы с функцией ESI, которая позволяет обновлять выборочно блоки на странице в зависимости от ситуации. Например если пользователь залогинен, или если у него в корзине появился товар, то varnish подгрузит и закеширует html блок для конкретного юзера (или группы пользователей). Ведь не зря в Magento используют его для кеширования всего, и никаких проблем с динамическими данными нет вообще.
Это костыль, и не работает в большинстве случаев (допустим если надо внедрить acl). Если уж собрались поддерживать философию IoC то надо поддерживать, а нет так, на пол шишечки.
Я бы попробовал сделать трюк с автолоадером, и перезаписывать пути к папкам в локальной версии приложения. Вот как тут stackoverflow.com/questions/28106850/how-to-use-composer-to-load-php-classes-from-local-repository и просто подключать локальный файл с доп правилами если есть. Или пойти глубже и написать плагин (или хук) для композера который будет зависеть от какого нибудь local_composer.json =)
Но все равно эта все похоже на костыль. Для локальной разработки библиотек надо строить дев окружение, а все остальные участники должны забирать обновления из удаленных репозиториев. Если вам хочется подключать локальные библиотеки, то надо или допилить автолоадер или иметь разные composer.json для вашего локального окружения и для продакшена. Тогда в локальном composer.json можно указать локальные пути библиотек для автолоадера. А в ide их добавить как внешние библиотеки.
Да исходники я уже тоже нашел и полез изучать ) Похоже все же надо будет ставить себе Го
Спасибо за наводку!
Все поды живут в одной сети.
Ну или шарить папку между нодами, а уже локальную папку монтировать в поды.
ps: тут довольно наглядно про фичу ruhighload.com/index.php/2010/01/22/%D0%BA%D0%B5%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86-%D1%83%D1%81%D0%BA%D0%BE%D1%80%D1%8F%D0%B5%D0%BC-%D1%81%D0%B0%D0%B9%D1%82-%D0%B2-100/
Символическая ссылка (symbolic links) — доступна с Windows Vista. en.wikipedia.org/wiki/NTFS_symbolic_link
Но все равно эта все похоже на костыль. Для локальной разработки библиотек надо строить дев окружение, а все остальные участники должны забирать обновления из удаленных репозиториев. Если вам хочется подключать локальные библиотеки, то надо или допилить автолоадер или иметь разные composer.json для вашего локального окружения и для продакшена. Тогда в локальном composer.json можно указать локальные пути библиотек для автолоадера. А в ide их добавить как внешние библиотеки.
На этой планете нет человека который бы смог сделать не глючащий удобный дропдаун для мобильных устройств, лучше нативного селекта.