У меня есть приложение. Он может создавать файлы CSV. Это состоит из:
У меня нет доступа к источнику приложения, и я не могу его изменить.
Приложение было разработано без учета Kubernetes, но, тем не менее, похоже, что Kubernetes StatefulSet с радостью его приспособит. (Это мое предположение, и я открыт для других вариантов.)
В любом случае, меня беспокоит то, как настроить следующий вариант использования:
Задания полностью независимы друг от друга, могут быть запущены в любое время, а количество заданий заранее не известно.
Я считаю, что (1) само по себе, вероятно, можно было бы обработать с помощью конструкции Kubernetes 'job'.
Мой вопрос поэтому: Какими способами можно справиться с (2) и (3)?
NB: профиль использования ресурсов приложения немного хаотичен, поэтому использование основных ограничений ресурсов на CPU / MEM или что-то еще, вероятно, будет недостаточно.
Непонятно, почему задание на шаге 1 создает StatefulSet для выполнения некоторых операций и впоследствии удалим его. Кажется, это противоречит цель сохранения состояния:
Если приложению не требуются стабильные идентификаторы или упорядоченное развертывание, удаление или масштабирование, вам следует развернуть приложение с помощью контроллера, который предоставляет набор реплик без отслеживания состояния. Контроллеры, такие как Deployment или ReplicaSet, могут лучше подходить для ваших нужд без сохранения состояния.
Если это не указано в вопросе, похоже, нет необходимости в StatefulSet в вашем сценарии, и это выглядит как Job лучше подходит для этого.
Поскольку вы открыты для других подходов, вот один из них:
В целом кажется, что вы пытаетесь создать ресурсы, которые происходит из других ресурсов в пределах кластер, и эти ресурсы могут не иметь некоторых необходимых вам ограничений (т.е. ограничивать количество StatefulSets для запуска в кластере).
Вместо того, чтобы создавать новые объекты из кластера, я бы предложил общение напрямую с API для создания всего необходимого извне кластера.
Такой подход имеет следующие преимущества:
Это, конечно, требует написания кода самостоятельно, и потенциальный недостаток может быть связан со временем, которое требуется для создания / развертывания объектов после того, как какое-либо действие вызвало его, и может сильно зависеть от размера ваших изображений и вашего политика извлечения изображений.
В заключение вы можете отправить образы приложений в любой репозиторий, который вы используете, и каждый раз, когда требуется запуск нового пакета, обращайтесь к API, чтобы создать необходимые ресурсы, чтобы они были созданы.
Это, конечно, не требует какого-либо изменения кода приложения.