L
1 . Ок
2 . Но я хочу чтобы везде было, даже каталог везде сделал
2 . Но я хочу чтобы везде было, даже каталог везде сделал
А данные то останутся на старом узле
Size: a a a
2020 October 23
L
Их никто за подом не будет перевозюкать
А
А как правильно сделать?
L
А как правильно сделать?
Научится вопросы задавать. Развернуто.
AL
А как правильно сделать?
Создать отдельный PV на каждую ноду - но вообще ты сначала сформулируй че ты хочешь
L
Непонятно что ты хочешь )
k
имеется ввиду любой стейтфул ресурс, не только база конечно
Ну обычно стейтфул в кубе принято делать так, чтобы оно умело работать в несколько реплик и умирать отдельными подами.
Но тут может прийти другая беда:
Большинство приложений используют
Но тут может прийти другая беда:
Большинство приложений используют
podManagementPolicy: Ordered (значение по умолчанию), это значит что поды должны запускаться поотчерёдно. То есть если самая первая реплика выходит из строя и вы случайно перезапустили какую-нибудь другую реплику, то ничего не заведётся пока вы не почините самую первую репликуk
Ну обычно стейтфул в кубе принято делать так, чтобы оно умело работать в несколько реплик и умирать отдельными подами.
Но тут может прийти другая беда:
Большинство приложений используют
Но тут может прийти другая беда:
Большинство приложений используют
podManagementPolicy: Ordered (значение по умолчанию), это значит что поды должны запускаться поотчерёдно. То есть если самая первая реплика выходит из строя и вы случайно перезапустили какую-нибудь другую реплику, то ничего не заведётся пока вы не почините самую первую репликуКак починить такой statefulset?
Можно ли обновлять спеку в yaml?
Можно ли обновлять спеку в yaml?
А
Вообще хочу насоздавать экземпляров приложения для каждой ветки
k
Как починить такой statefulset?
Можно ли обновлять спеку в yaml?
Можно ли обновлять спеку в yaml?
В общем все эти моменты нужно понимать и принимать во внимание при запуске любого стейтфула в кубе.
k
В общем все эти моменты нужно понимать и принимать во внимание при запуске любого стейтфула в кубе.
Если все эти аспекты учесть, то выходит куб - это отличный инструмент как для stateless так и для stateful приложений, кто бы что не говорил
b
кто бы что не говорил, это можно выяснить только попробовав. спасибо за совет
k
кто бы что не говорил, это можно выяснить только попробовав. спасибо за совет
Именно, а стоит ли овчинка выделки - это уже совсем другой вопрос
L
Вообще хочу насоздавать экземпляров приложения для каждой ветки
Ветки чего... Что такое экземпляр приложения....
Странные термины....
Но кажется мне, что это надо ci/cd рисовать.
При чем тут pv?
Странные термины....
Но кажется мне, что это надо ci/cd рисовать.
При чем тут pv?
b
Именно, а стоит ли овчинка выделки - это уже совсем другой вопрос
Компетенция и экспертное мнение на реальном опыте, а не с потолка? Определенно стоит.
k
Компетенция и экспертное мнение на реальном опыте, а не с потолка? Определенно стоит.
Ну с точки зрения бизнеса разумеется.
Что будет затратнее:
Поднять отказоустойчивую постгрю в кубере с бэкапами и прочим или поднять условную виртуалку в проксмосе
Что будет затратнее:
Поднять отказоустойчивую постгрю в кубере с бэкапами и прочим или поднять условную виртуалку в проксмосе
DS
вобщем ваша мысль ясна. нужно понимать, что может сломаться и как это чинить. для этого нужно поэксперементировать
до фига там нюансов с базами, из-за которых жить будет больно. Но это зависит от самих баз естественно. Для стендов вообще пофиг. Если нагрузка небольшая тоже пофиг. А если у вас бд в несколько териков и 150K rps, и надо все отказоустойчиво. То можно в теории это в кубе держать, но я профита не вижу, только доп проблемы по траблшуту в случае поломок. Ну или если ты уверен в своём решении на кубе, и знаешь его вдоль и поперёк
DS
Компетенция и экспертное мнение на реальном опыте, а не с потолка? Определенно стоит.
если честно гораздо проще менеджить кластер, когда у тебя нет серьёзного там стейта. Нода упала? пфф пофиг, задрейнить можно любую. Обновить кластер - изи. А если в кластере серьёзный стейт, ты 10 раз подумаешь, прежде чем дрейнить ноду, проверишь, а не мастер ли базы там щас крутится и т. д.
SM
Ну с точки зрения бизнеса разумеется.
Что будет затратнее:
Поднять отказоустойчивую постгрю в кубере с бэкапами и прочим или поднять условную виртуалку в проксмосе
Что будет затратнее:
Поднять отказоустойчивую постгрю в кубере с бэкапами и прочим или поднять условную виртуалку в проксмосе
с точки зрения бызнеса, проще взять rds, это дешевле чем админ/дувопс который будет развлекаться с HA для BD, тк что в кубе, что на вм, не фига не тривиально