Возможно, вам необходимо отделить HTTP-сервис от серверной обработки. Если выполнение задания занимает минуты или дольше, большинство браузеров и других HTTP-клиентов истечет время ожидания до его завершения, поэтому для его завершения HTTP необходимо каким-то образом запустить задание и немедленно вернуть какое-то сообщение об успехе.
Как только вы это сделаете, вы можете найти очередь заданий, как RabbitMQ, полезным компонентом инфраструктуры. Опять же, это отделяет очередь заданий от механизма их фактического запуска. В пространстве Docker / Kubernetes вы запускаете некоторое количество постоянных работников, которые все слушали очередь и работали так, как она появилась там. Вы не обязательно запускаете одного работника на работу; или, возможно, у вас будет только один работник, который запускает другие контейнеры Docker или рабочие места Kubernetes; но если отставание в работе стало слишком длинным, вы могли бы привлечь дополнительных работников.
В чистом Docker-пространстве теоретически возможно использовать Docker API для запуска дополнительных контейнеров. Однако выполнение этого дает вашему процессу неограниченный доступ корневого уровня к хосту; если вы используете это в контексте HTTP-сервера, вы должны быть чрезвычайно осторожны в вопросах безопасности. У Kubernetes также есть API, и с точки зрения безопасности это, вероятно, лучше: вы можете настроить служебную учетную запись, у которой есть разрешения только для запуска заданий, и запускать задание для каждого поступающего задания. (Безопасность по-прежнему важна, но злонамеренному вводу намного сложнее получить root-права на хост.)