> Эм. С разморозкой, да?? Чем тебе stateful в _современном_ кубере жмет? Нет,
> ну в 1.9 понятно, а сейчас-то что не так? Унифицированное управление,
> мониторинг, автоматизация всякой рутины не нравятся?Ну вот и они, свидетели современности. Что ж, поясню немного.
Куб -- прекрасный оркестратор, он великолепно упрощает множество процессов. Но как и любая event-driven архитектура, он тонкий аж пипец: одно неверное движение, не предусмотренное заранее разработчиками -- и всё, ты в неизвестном непаханном поле один на один с проблемой.
Я вот сталкивался с ситуациями, когда человек полностью поломал ингресс-контроллер одним некорректным ингрессом. Я видел, как человек положил одну из мастер-нод куба, просто скормив ему некорректный манифест сервиса. Да, виноват в этом был не сам куб, а CNI, да и в первом случае это была конечно же вина самого контроллера, однако от этого не легче, потому что: куб по природе своей является мешаниной весьма свежих, не вполне отлаженных технологий.
Из этого вылезает ещё одна песня: мажорные обновления. Куб с пейлоадом в принципе нельзя обновлять, обязательно что-нибудь случится. Причина банальна: разработчики чартов прорабатывают развёртывание, но почти никогда не прорабатывают удаление. Обычно где-нибудь нет-нет, да и выстрелит "самая частая проблема" с PDB, которую придётся фиксить вручную. Так что мажорные обновления куба -- только через блюгрин, и никак иначе.
В общем, много чего может в кубе пойти не так. А ведь всё выше описанное -- оно ещё даже не подошло к стейтфулам.
А стейтфулы -- это же сетевое взаимодействие с блочным устройством. У любого профессионала сразу возникает вопрос: а на чём реализован бэкенд volume provisioner-а, и где он расположен? Там должна быть хорошая сеть, подогнанная под размер блока. Там должно быть хорошее резервирование. Если чего-то из этого нет -- то получаешь либо низкую производительность, либо DoS в самый неожиданный момент.
Если ты на baremetal -- это всё конечно можно гарантировано сделать правильно, но это будет стоить дорого весьма, и очень, очень непросто в обслуживании: придёт пора апгрейдить полку -- поймёшь. Во время этого процесса лучше даже не дышать: одно неверное движение, и всё, каюк. А базы, знаешь ли, могут восстанавливаться весьма небыстро. Даже если есть холодные бэкапы. Особенно при такой архитектуре. Это, что ли, ты называешь "не нравится автоматизация всякой рутины"?
А если же ты в облаке -- то ты понятия не имеешь, как оно реализовано у них, и можно ли их архитектуре доверять. Тут масса всего может пойти не так. Я лично был свидетелем, как у амазона диски на compute instance-ах сыпались. Или вот у того же MCS полки разваливались за последние 3 года -- дважды. И второй раз они восстанавливались 10 дней, между прочим. Да, при заявленном SLA 99.95%.
В общем, тащить стейтфул в куб откровенно не весело.
