У меня есть система, которая должна выполнять сотни тысяч краткосрочных заданий в день. Каждое задание выполняется от нескольких секунд до пары часов. Каждое задание выполняет HTTP-запросы к внешним веб-серверам, записывает данные на диск (от нескольких мегабайт до сотен гигабайт) и устанавливает серию подключений к базам данных.
Каждое задание - это один и тот же контейнер Docker, в котором выполняется один и тот же процесс Java. Каждое задание имеет свою конфигурацию, передаваемую как переменная среды.
В настоящее время мы развертываем эти задания в кластере Kubernetes, используя спецификацию «Job». Однако кластер не сразу доступен для заданий, когда должен быть запущен большой поток заданий. Мы также должны постоянно запрашивать кластер Kubernetes, чтобы определить, было ли задание завершено или убито (например, из-за нехватки памяти).
Я хотел бы найти решение, которое позволило бы нам развернуть эти задания как можно быстрее, не беспокоясь о том, доступны ли ресурсы или требуя от нас запроса системы, чтобы определить, выполнено ли задание.
На ум приходит AWS Lambda, но у меня мало опыта с этим.
В качестве архитектурного примечания у нас есть наш процесс, который обслуживает планировщик, который вычисляет, какое задание должно быть выполнено и когда. этот процесс в настоящее время отправляет задание в кластер Kubernetes.
Учитывая вышеприведенное описание, какие архитектуры я должен оценивать, чтобы минимизировать количество проблем, которые вызывает эта система: 1) доступны ли ресурсы для обработки задания и 2) сбой этого задания по какой-либо причине, "не связанной с приложением".
В настоящее время эта система работает на GCP и AWS. Мы открыты для любого решения, даже если это означает выбор одной (и потенциально другой) платформы.
Если задания недолговечны, ваша цель может быть лучше достигнута путем реализации очереди заданий и набора долгоживущих рабочих, которые потребляют задания из очереди. Есть ли причина, по которой вам нужно запускать задания в самом k8s?
Предположительно ваш кластер ограничен в ресурсах. Для достижения большего объема работы, если это необходимо, необходимо более эффективное приложение или больше ресурсов.
Такие крупные провайдеры, как вы, сдают в аренду столько экземпляров, сколько позволяет ваш бюджет. Увеличьте масштаб кластера, возможно, автоматически. Возможно, потребуется некоторая свободная мощность, если вы планируете работу в короткие сроки.
Альтернативой опросу задания Kubernetes является ваш код, передающий сообщение. В конце задания позвоните своему планировщику с указанием завершения.
Конечно, он мог умереть и никогда не отчитается. В конечном итоге это должно стать состоянием отказа. Подумайте о том, чтобы опрашивать работу через определенные промежутки времени после обычного кратчайшего времени работы и отказываться от нее после жесткого ограничения, например activeDeadlineSeconds.