Обновить

Комментарии 9

Меня умиляет стремление иметь много виртуальных машин и много узлов (node - узел, утолщение) и стручков (pod - стручок, кокон, подвеска). Слово cordon можно писать и кирилицей - кордон, есть такое слово в русском языке.

Хотелось бы услышать объянение этого стремления от практикующего специалиста. .

Казалось бы, что лучше один стручок, но как у коня, но всё-таки когда их N+1, как-то поспокойнее. А то вдруг не поднимется, или чего хуже, упадёт в самый неподходящий момент.

мимо практикующий специалист

А что Вы думаете об издержках управления всей этой многоузловой и многостручковой конфигурацией?

Подскажу,: это не бесплатно.

А в целом ответ Ваш принимается. Да на таких ненадежных платформах как х86 и облако единственный выход это создавать софтверную избыточность и пытаться ее поддерживать через неизбежные издержки. Когда выигрываешь в одном обязательно проигрываешь в чем то другом.

В гарантированных прибылях при этом остаются только поставщики базового обеспечения (Кубернетес) и облачных сервисов.

Спасибо за статью. После прочтения появилось несколько вопросов:
1. Яндекс выключает прерываемую ноду не только раз в сутки, но и по своему усмотрению, когда потребуются ресурсы. Выключает он посылая сигнал shutdown на ноду, без предварительного уведомления. Вы как-то пытались победить?
2. Что вы будете делать, если в зоне закончатся ресурсы для прерываемых нод?

  1. Да, прерываемая ВМ может быть выключена в любое время, по этому пока используем в тестовых кластерах. Но за несколько месяцев использования еще не было ситуации чтобы это повлияло на работу кластера. И да, сигнал посылается и его даже можно отследить, то он отправляется за 30 секунд до отключения, так что толком ничего успеть не получится.

  2. Такая ситуация тоже возможна, но пока ниразу не сталкивались. Для обработки подобных сценариев дорабатываем оператор, чтобы он за раз не кордонил больше одной ноды и следил, чтобы новые ноды появляись во время. Возможно в будущем продумаем возможность переводить нагрузку на обычные ноды в случаи невозможности создать прерываемую.

Доброго дня. Подскажите, пожалуйста, а со стороны ОС не пробовали отловить сигнал от OS на shutdown, чисто если повыдумывать, можно отправить какой-нибудь rest на момент отключения ноды, который может бы и сообщил мастеру куба о выводе ноды из кластера или также посылать в ваш оркестратор информацию, чтобы он уже начинал конфигурировать по иному ваше окружение?

Выше писал, что Яндекс Облако посылает сигнал за 30 секунд до выключения ВМ, этого времени недостаточно чтобы что-то успеть сделать. По этому эту идею в начале откинули.

спасибо за статью! хорошая идея. мы настроили бота, который выключает все наши тестовые managed сервисы на ночь и на выходные, с интеграцией в mattermost, чтобы в случае чего, если тестировщику надо поработать, чтобы он отменил остановку или запустил все сервисы одной командой.

Да, мы тоже такой подход используем для ВМ разработчиков и части инфровых ВМ.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации