Запланированные, автоматически масштабируемые задания в Google Cloud Platform

Question

Я немного новичок в облачной разработке, так что будьте спокойны со мной.Я даже не уверен, что я спрашиваю: возможно .

Я пытаюсь выяснить, как запланировать работу (возможно, каждый час или два) для выполнения рабочего процесса.это будет упаковано в пользовательский образ Docker.Рабочий процесс проверит любую «запланированную работу», которую он должен выполнить (по запросу пользователей приложения), подключившись к хранилищу данных приложения, а затем выполнит любую ожидающую работу.Когда я это сделаю, я хочу, чтобы все было снесено до следующего интервала графика, поэтому я не несу никаких затрат во время простоя.

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

Сводка требований

• Полный контроль над образом Docker.У меня есть пользовательские инструменты и код, который мне нужно будет вставить в образ.
• График, основанный на времени, для запуска выполнения кода в образе Docker.
• Запланированное выполнение работы может занять довольно много времени(может быть до 10 или 15 минут) для завершения.
• Настраиваемое, управляемое программным способом масштабирование и разбиение, которое создает x количество контейнеров Docker, каждый из которых имеет свой тип запланированной работы.Определение x будет основано на данных в хранилище данных приложения.
• Во время простоя абсолютно не несет никаких затрат.

Things I 'мы пробовали / рассматривали

K8s

Кажется, требует, чтобы кластер работал постоянно.Мне также неясно, как бы я имел разные узлы в кластере, отвечающие за разные типы запланированных работ.

AppEngine и Cloud Scheduler

Мне нужно было бы использовать гибкую среду из-за моегосделанное на заказ изображение Docker.Согласно this , это означает, что я должен оставить хотя бы один экземпляр запущенным постоянно.

Опять же, я не уверен, как бы я масштабировал его так, чтобы разные экземпляры имели дело с разнымитипы запланированных работ.

Вопросы

Итак, у меня есть несколько вопросов обо всем этом:

1. Прежде всего, возможно ли это даже с помощью GCP?Мои исследования до сих пор показывают, что это не так.
2. Каков наилучший подход к тому, чтобы максимально приблизиться к моим требованиям?

Answer 1

В принципе рабочая нагрузка хорошо подходит Kubernetes.Вы можете настроить Kubernetes CronJob для запуска каждого вида работника один раз в час;вы бы создали отдельный CronJob с отдельными переменными среды или параметрами командной строки для каждого вида рабочей нагрузки;при условии, что у вас есть реестр образов Docker (например, GCR ), вы можете запустить любой пользовательский образ Docker.

Единственный прием в том, что вы говорите о масштабировании контейнеров вверх и вниз, но в GKE вы платите за узлов .В GKE кластерный автоскалер автоматически создаст и удалит узлы для вас. Часто задаваемые вопросы звучит так, будто быстрое увеличение немного более важно для него, чем уменьшение, с целью получения достаточной мощности, чтобы начать все в течение 60 секунд. Это сократит количество узлов, которые используются менее чем на 50%, в течение 10 минут .

Если запланированные задания составляют большую часть вашей общей рабочей нагрузки, то, возможно, это приведет к тому, что узлы будутускорился и замедлился с, возможно, 50% средней загрузкой, с новым увеличением каждый час.Это также отвечает вашим требованиям к выставлению счетов (или, по крайней мере, лучше, чем постоянный запуск всего кластера).В документации по ценам GKE говорится:

GKE использует экземпляры Google Compute Engine для узлов в кластере.За каждый из этих экземпляров выставляется счет в соответствии с расценками Compute Engine, пока узлы не будут удалены.Ресурсы Compute Engine оплачиваются посекундно с минимальными затратами на использование в 1 минуту.

Если основной причиной этого является стоимость, оптимальной является ситуация, когда у вас никогда не бывает свободного узла.Самый простой способ сделать это - запустить выделенный экземпляр GCE для каждой задачи, а затем уничтожить его по завершении задачи.GCE поддерживает косвенно запущенные контейнеры в экземплярах , которые могут хорошо подойти для вашей задачи;Вы должны будете предоставить свой собственный планировщик заданий и дать ему возможность покупать и закрывать экземпляры GCE.Это становится компромиссом между тем, сколько денег вы хотите потратить на разработку пользовательского решения, и сколько денег вы хотите потратить на облачные ресурсы.