Как заставить мою EKS AutoScalingGroup запускать узел с экземпляром определенного типа, если он еще не запущен?
Я просматривал документацию, пытаясь выяснить, можем ли мы реализовать конкретную архитектуру EKS для нашего варианта использования, и не нашел четкого ответа о том, как это сделать и возможно ли это.
Объем
У нас есть несколько небольших модулей, которые работают круглосуточно и без выходных, отслеживая новые запросы задач. Когда обнаруживается новая задача, эти модули мониторинга запускают рабочие модули, которые требуют гораздо больше ресурсов ЦП и памяти.
Чего мы хотели бы достичь в EKS, так это наличия 2 (или более) типов экземпляров в одной AutoScalingGroup:
Небольшой недорогой экземпляр для работы модулей 24/7.
Большие, дорогие экземпляры для запуска задач, а затем их прекращение.
Согласно документации, наличие нескольких типов экземпляров в ASG не является проблемой, но в ней не указано, как гарантировать, что малые модули будут назначены маленькому экземпляру, а большие модули — большому экземпляру.
На данный момент проведено тестирование:
(Max = 3, Min = 1, Desired = 1)
В настоящее время у нас есть большой тип инстанса с приоритетом 1, а малый — с приоритетом 2. Таким образом, при запуске запускается один большой инстанс.
Когда я запускаю свой небольшой модуль с селектором узла, установленным на тип небольшого экземпляра, он остается в состоянии «ожидания» из-за события ошибки: Доступно 0/1 узлов: 1 узел (узлы) не соответствует селектору узлов.
Итак, на данный момент мой вопрос: Как заставить мой ASG запускать узел с конкретным типом экземпляра, если он еще не запущен, в зависимости от требований модуля для этого конкретного типа экземпляра? Любые указатели на ссылки, документацию или предложения по улучшению подходов приветствуются, спасибо!
Ответы 2
У меня никогда не было такого варианта использования, но я думаю, вам следует попробовать комбинацию автомасштабирования кластера с nodeAffinity.
См. Особое примечание по экземплярам GPU
Похоже, это непонимание с моей стороны того, как работает автомасштабирование и ASG. Основываясь на отзывах от кого-то на другом форуме, я узнал, что
А) автомасштабирование работает как pod на самом кластере (поэтому готовый EKS не поддерживает минимум 0 узлов; для запуска kube-system/auto-scaler требуется хотя бы один узел стручки).
и B) один модуль автоматического масштабирования может масштабировать несколько ASG, существующих в кластере. Таким образом, это позволяет нам разделить наши экземпляры на отдельные ASG по стоимости и гарантировать, что дорогостоящие экземпляры используются только по запросу рабочих модулей.
Наше решение пока таково:
Настройте как минимум 2 ASG:
- Запускает модули 24/7 и модули kube-system. В этой ASG используются меньшие по размеру и более дешевые типы экземпляров.
- (или больше, если это соответствует варианту использования) Запускает расширяемые модули. Этот ASG использует более крупные и дорогие типы экземпляров, необходимые для обработки задач.
Нанесите идентификационные метки на ASG. Рекомендуемый подход EKS (особенно если вы хотите использовать спотовые инстансы) заключается в использовании размера инстанса (например, микро, большой, 4xlarge). Это позволяет легко добавлять экземпляры с теми же размерами ресурсов в существующую ASG для большей надежности. Пример:
Labels: asgsize=xlargeПримените селектор узла в yaml пода, чтобы он соответствовал нужному узлу:
spec: nodeSelector: asgsize: xlargeУстановите 24/7, малый экземпляр ASG на минимум = 1, желаемый = 1, максимальный = 1 (по крайней мере; максимум может быть больше, если это соответствует вашим потребностям)
Установите для расширяемого ASG для крупных экземпляров значение min=0, желательное значение = 0, максимальное значение = (независимо от того, что требуется для вашей среды).
Когда мы реализовали этот подход, мы смогли успешно запустить небольшой инстанс 24/7, а более крупные инстансы запускались с нуля только при создании пода с этой меткой.
Отказ от ответственности:
Мы также столкнулись с этой небольшой ошибкой в нашем автомасштабаторе, когда большой ASG изначально не масштабировался с 0: https://github.com/kubernetes/autoscaler/issues/2418
Обходное решение в этой проблеме сработало для нас. Мы заставили наш большой ASG иметь min=1. Затем мы запустили модуль в этой группе, снова установили min=0 и удалили модуль. Экземпляр автоматически уменьшился и был остановлен, а затем в следующий раз, когда мы запросили модуль, он автоматически масштабировался правильно.
Вы ответили, пока я печатал свое собственное решение :) Да, по сути, это было то, что мы в конечном итоге сделали, узнав, что мы неправильно понимаем пару ключевых поведений автоматического масштабирования. Спасибо за ответ!