Нет, конечно же, все это автоматизировано, как и написано в статье - пару-тройку дней летит обновление\фикс, который дрейнит ноды и все само переезжает.
Собственно, в этом и есть мой основной посыл: при наличие работающей схемы замены нод отказываться от нее и намеренно устраивать big bang – чревато. Посмотреть как кластер встаёт из бекапа, конечно, тоже интересно, но это отдельное развлечение со своими граблями.
Но, мы блокировали только calico etcd, а не etcd для всего kubernetes, так что теряли по сути только часть которая касается сетевого плагина, это гораздо меньшее из зол, т.к. все пробы, например, продолжают работать.
Тогда не так страшно, это да.
Конкретно в этом кейсе чистили как раз не ноду целиком, а только сетевые неймспейсы, а вся остальная инфа остается на ноде как и прежде. В большинстве случаев, мы, конечно же, не мелочимся, и если нужно "почистить" ноду, то мы ее просто полностью удаляем и выкатываем совсем новую на ее место.
Это, наверное, вторая часть моего посыла: если в кубернетисах что-то работает не так, проще снести и пересоздать с нуля, чем чинить.
У нас разработчики все выкатывают с помощью helm в котором да, фактически чистые Deployment и STS
Понял. Это, в целом, рабочая схема, но не очень гуманно по отношению к продуктовым разработчикам (хелм – это текстовый шаблонизатор поверх ямла, и работает он примерно так же хорошо, как можно ожидать), и может выйти боком для инфраструктуры, если в кластер шаловливые ручки выкатят что-то неожиданное.
Нагрузка там от разработчиков, тестировщиков и прочих причастных к приложениям. В препроде меньше нод чем в стейдже, потомучто он не пользуется у нас большой популярностью, к сожалению, и это как раз хочется исправить, чтобы однажды наш stage и правда был тем самым dev, который не страшно уложить.
Нагрузка в стейджинге треть от прода, а в препроде ещё столько же – серьезно у вас относятся к тестам, внушает!
Несколько кластеров полезно и уменьшением blast radius когда что-то пошло не так, и вообще я сторонник держать все окружение архитектурно максимально унифицированными, но, возможно, тут расхождения в терминах. У вас в препроде настоящие данные пользователей? Если да, то его ломать никому не надо, и продуктовым разработчикам нужен всегда рабочий стейджинг. Если в препроде настоящих данных нет, то он на самом стейджинге, а стейджинг на самом деле дев.
Не выдержал и после стольких лет зарегался, потому что "моя свирепость не выносит такой наглости".
Вот зачем было так старательно искать приключений на свои вторые девяносто, когда правильный вариант действий был не просто возможен, а вы же его сами и описали – перезапускать ноды по одной. Да долго, да скучно, зато безопасно! А если после восьми часов махания kubectl drain вам начинает хотеться этот процесс как-то автоматизировать... То это правильное желание, автоматизировать такие вещи можно и нужно, диапазон вариантов крайне широк, от баш-скрипта до пачки операторов. Версию кубернетисов вы как обновляете? Тоже тушите кластера на пару дней? А на проде?
Для тех, кто не настолько погружен в тему, поясню. В некоторых аспектах кубернетисы довольно хрупкая система, и масштабирования туда не завезли. Сломать кластер нагрузкой на API server или etcd – фигня вопрос. Контроль нагрузки предлагается делать на клиенте. Да, на кажом. Да, самостоятельно. Нет, никакого метода понять, какие ограничения ставить нет. Да, в большинстве случаев в из или не трогают и берут значения по умолчанию, или выставляют от балды. При таких вводных делать масштабные операции типа "перезапустить все поды в кластере" – это просто напрашиваться на неприятности. И вообще в кубернетисах большие кластера живут со скрипом, лучше несколько маленьких кластеров, чем один большой.
С другой стороны, если с ним правильно обращаться, то кластер становится живучим, как советская власть – при возникновении ошибок операции by design повторяются до позеленения и куча вещей пересоздаются: прибил под – он пересоздался как ни в чем не бывало, отрубил ноду – поды разбежались по другим как тараканы, и снова работают. За то кубернетисы и любят.
Теперь подробнее по статье по пунктам.
блокировка базы данных — это нужно, чтобы минимизировать любые воздействия. Она приводит к невозможности запуска новых подов: деплоев и просто перезапусков подов вследствие выхода из строя ноды.
Заодно потеряли ивенты, и вообще все изменения в кластере. Под помер, а убрать его из эндпоинтов нельзя.
Практически единовременный запуск почти 5 000 подов — это серьёзная задачка.
Настолько серьезная, что API server скорее всего будет адски тупить в это время.
при замене нод ETCD, если поды не могли достучаться до старого хранилища, они впадали в ступор и вели себя точно так же
Э? Поды в etcd, вообще говоря, не ходят. Кьюблет взаимодействует с API сервером, а тот уже ходит в etcd.
Для этого нужно погасить containerd, удалить всю информацию о выделенных сетевых неймпейсах и запустить всё назад.
Эээ? Ну допусти ноды у вас железные, ваше право, но почему нет какого-нибудь ансибля, или парапета, или что там сейчас любят железячные админы, который придет и снесет все выступающее возвращая ноду в первозданное состояние? А операционку на нодах вы как обновляете когда там RCA находят?
Бегаю к разным нодам, руками осуществляю эти схемы зачистки
Ну, собственно, и вот, бегать по нодам и пришлось, только не в нормальном рабочем режиме, а в состоянии "шеф, все пропало!"
Успешно обежав с десяток нод, запускаю зачистку автоматами. Указываю, что запуск должен быть не более чем на двух нодах одновременно, чтобы не задавить систему ресурсоёмкими конкурентными запросами.
Автоматизация и контроль одновременных запросов, это правильно, именно так и надо было делать с самого начала.
некоторые поды не могут запуститься, потому что из registry не читаются данные.
Registry это который container registry? Вы бы какие нибудь ключевые слова к нему приписали, если не container, то OCI или докер, а то этих реестров – в каждом утюге, непонятно когда какой имеется в виду.
Делаю слепок всех установленных deployment и statefulset и удаляю эти объекты из кластера,
У вас приложение катятся прямо как Deployments и StatefulSets? Не сильно удобно для разработчиков, прямо скажем, особенно если много кластеров. А кластеров лучше много, по ому что см. выше про отсутствие масштабирования.
Но из-за зачистки всего и вся, мы получили бутшторм не по CPU, а по сети — все встали в очередь за образами.
Угумс, и это ещё ноды таскают образа по одному, иначе container registry тоже может мяукнуться.
Но у инфраструктуры фактически нет разделения на стейдж\пре\прод
Чистая правда, и поэтому нужен ещё один контур, например дев, который можно немножко сломать к хренам и парализовать работу только инфры, а не все разработки.
Решения для кластеров с парой десятков нод, скорее всего, не подходят для кластеров с сотнями нод.
Чистая правда, кубернетисы не умеют в масштабирование. Увы.
Наш k8s в стейдже понемногу пытается догнать продовые кластеры в Kubernetes по количеству нод: в проде — 240 и 194 ноды, в препроде — 109 и 77, в стейдже — 141.
Нахрена столько нод в стейджинге? У вас деньги лишние, что ли? Или откуда там такая нагрузка? А в препроде (это же Гамма, да? Новый код, зависимости и данные из прода) откуда, там вообще кроме тестов перед выкаткой никакой нагрузки нет? А, ну и да, два кластера. Лучше, чем один, и запас по росту у вас есть, но все равно лучше бы было больше.
Из-за запуска большого количества подов в стейдже registry, который находится не в стейдже, падает по ООМ.
Кстати, а почему он падает, а не ругается пятисотками? Может на нем каких защит накрутить?
А в завершение – извините, если критика прозвучало слишком резко, и здорово, что вы написали так подробно и с таймлайнами. Опыт, он так и приобретается, с упавшими кластерами, сегфолтами, а иногда и звонками роботети в два часа ночи. Удачи вам!
Собственно, в этом и есть мой основной посыл: при наличие работающей схемы замены нод отказываться от нее и намеренно устраивать big bang – чревато. Посмотреть как кластер встаёт из бекапа, конечно, тоже интересно, но это отдельное развлечение со своими граблями.
Тогда не так страшно, это да.
Это, наверное, вторая часть моего посыла: если в кубернетисах что-то работает не так, проще снести и пересоздать с нуля, чем чинить.
Понял. Это, в целом, рабочая схема, но не очень гуманно по отношению к продуктовым разработчикам (хелм – это текстовый шаблонизатор поверх ямла, и работает он примерно так же хорошо, как можно ожидать), и может выйти боком для инфраструктуры, если в кластер шаловливые ручки выкатят что-то неожиданное.
Нагрузка в стейджинге треть от прода, а в препроде ещё столько же – серьезно у вас относятся к тестам, внушает!
Несколько кластеров полезно и уменьшением blast radius когда что-то пошло не так, и вообще я сторонник держать все окружение архитектурно максимально унифицированными, но, возможно, тут расхождения в терминах. У вас в препроде настоящие данные пользователей? Если да, то его ломать никому не надо, и продуктовым разработчикам нужен всегда рабочий стейджинг. Если в препроде настоящих данных нет, то он на самом стейджинге, а стейджинг на самом деле дев.
EDIT: рано отправил.
А что не так с базами в кубернетисах? При условии, что база данных может пережить потерю реплики, конечно.
Не выдержал и после стольких лет зарегался, потому что "моя свирепость не выносит такой наглости".
Вот зачем было так старательно искать приключений на свои вторые девяносто, когда правильный вариант действий был не просто возможен, а вы же его сами и описали – перезапускать ноды по одной. Да долго, да скучно, зато безопасно! А если после восьми часов махания kubectl drain вам начинает хотеться этот процесс как-то автоматизировать... То это правильное желание, автоматизировать такие вещи можно и нужно, диапазон вариантов крайне широк, от баш-скрипта до пачки операторов. Версию кубернетисов вы как обновляете? Тоже тушите кластера на пару дней? А на проде?
Для тех, кто не настолько погружен в тему, поясню. В некоторых аспектах кубернетисы довольно хрупкая система, и масштабирования туда не завезли. Сломать кластер нагрузкой на API server или etcd – фигня вопрос. Контроль нагрузки предлагается делать на клиенте. Да, на кажом. Да, самостоятельно. Нет, никакого метода понять, какие ограничения ставить нет. Да, в большинстве случаев в из или не трогают и берут значения по умолчанию, или выставляют от балды. При таких вводных делать масштабные операции типа "перезапустить все поды в кластере" – это просто напрашиваться на неприятности. И вообще в кубернетисах большие кластера живут со скрипом, лучше несколько маленьких кластеров, чем один большой.
С другой стороны, если с ним правильно обращаться, то кластер становится живучим, как советская власть – при возникновении ошибок операции by design повторяются до позеленения и куча вещей пересоздаются: прибил под – он пересоздался как ни в чем не бывало, отрубил ноду – поды разбежались по другим как тараканы, и снова работают. За то кубернетисы и любят.
Теперь подробнее по статье по пунктам.
Заодно потеряли ивенты, и вообще все изменения в кластере. Под помер, а убрать его из эндпоинтов нельзя.
Настолько серьезная, что API server скорее всего будет адски тупить в это время.
Э? Поды в etcd, вообще говоря, не ходят. Кьюблет взаимодействует с API сервером, а тот уже ходит в etcd.
Эээ? Ну допусти ноды у вас железные, ваше право, но почему нет какого-нибудь ансибля, или парапета, или что там сейчас любят железячные админы, который придет и снесет все выступающее возвращая ноду в первозданное состояние? А операционку на нодах вы как обновляете когда там RCA находят?
Ну, собственно, и вот, бегать по нодам и пришлось, только не в нормальном рабочем режиме, а в состоянии "шеф, все пропало!"
Автоматизация и контроль одновременных запросов, это правильно, именно так и надо было делать с самого начала.
Registry это который container registry? Вы бы какие нибудь ключевые слова к нему приписали, если не container, то OCI или докер, а то этих реестров – в каждом утюге, непонятно когда какой имеется в виду.
У вас приложение катятся прямо как Deployments и StatefulSets? Не сильно удобно для разработчиков, прямо скажем, особенно если много кластеров. А кластеров лучше много, по ому что см. выше про отсутствие масштабирования.
Угумс, и это ещё ноды таскают образа по одному, иначе container registry тоже может мяукнуться.
Чистая правда, и поэтому нужен ещё один контур, например дев, который можно немножко сломать к хренам и парализовать работу только инфры, а не все разработки.
Чистая правда, кубернетисы не умеют в масштабирование. Увы.
Нахрена столько нод в стейджинге? У вас деньги лишние, что ли? Или откуда там такая нагрузка? А в препроде (это же Гамма, да? Новый код, зависимости и данные из прода) откуда, там вообще кроме тестов перед выкаткой никакой нагрузки нет? А, ну и да, два кластера. Лучше, чем один, и запас по росту у вас есть, но все равно лучше бы было больше.
Кстати, а почему он падает, а не ругается пятисотками? Может на нем каких защит накрутить?
А в завершение – извините, если критика прозвучало слишком резко, и здорово, что вы написали так подробно и с таймлайнами. Опыт, он так и приобретается, с упавшими кластерами, сегфолтами, а иногда и звонками роботети в два часа ночи. Удачи вам!