Как запустить процесс в отдельном Pod?

Question

[Dmitry Shnyrev]

Предыстория вопроса.
Долго работал c Heroku и привык к некоторым специфичным фичам. Сейчас мигрируем на Google Cloud Platform с его GKE (Kubernetes) и стал вопрос найти аналог фиги из Heroku.

Мне надо запускать некоторые процессы (python скрипты) в контексте моего приложения. На хероку это делаетс так:

heroku run bash --app my-app

Что делает Heroku, он поднимает ОТДЕЛЬНЫЙ dyno (аналог Pod) без запуска самого приложения (аналог EXEC из Dockerfile) и предоставляет доступ к командной строке. Я могу запустить все что мне угодно и после выхода этой сессии dyno убивается. Очень удобная штука когда мне надо запускать какие-то скрипты в изолированном продакшен окружении, не затрагивая уже работающие dynos с самим web приложением. Также я могу запутить такой отдельный dyno запустить скрипт как detached что позволит оставить dyno работать до окончания выполнеия скрипта и потом умереть.

heroku run:detached --size=performance-m --app my-app -- \
	python my-very-long-running-script.py

На GKE/Kubernates не могу найти аналог. Все что смог это подключиться к уже работающему Pod
такой командой

kubectl exec -it my-pod-6679fc8544-xbmhf -- bash

Но мне именно нужен отдельный чистый pod где я могу запускать всякого рода возможно деструктивные скрипты которые могут сожрать всю память и cpu и чтобы это не влияло на работу самого приложения.

Какие возможны решения?

Answer 1

[Дмитрий Шицков]

kubectl run -it some_unique_name --image youre/image:tag --restart=Never --rm -- /bin/bash

С --rm pod будет удален после отключения от терминала или завершения другой команды, какая была вызвана вместо bash. Без него будет просто остановлен - полезно если вам нужны логи в кубе после завершения работы.

Так же обратите внимание на возможности Kubernetes - Job и CronJob, как более декларативный подход.

Comments

[Dmitry Shnyrev]

Что-то мне такую штуку возвращаят

pod "bash" deleted
error: timed out waiting for the condition


Не сталкивались?

[Дмитрий Шицков]

Dmitry Shnyrev, а можете скинуть целиком какую команду выполняли?
Похоже что где-то или пробел лишний, или не хватает --

[Dmitry Shnyrev]

Совсем полную не могу, проект рабочий (изменил имя image). Так же убрал namespace гурается что не может найти.

Вот примерно такое у меня.

kubectl run -it --rm --image eu.gcr.io/xxxxxxxx/yyyyyyyy:f8b64e5e404c3ffd0df4890f32bccf3232e56ca3 -- bash

[Дмитрий Шицков]

Dmitry Shnyrev, кажется --restart=Never в этом случае нужен обязательно.

kubectl run -it temp_pod_1 --image eu.gcr.io/xxxxxxxx/yyyyyyyy:f8b64e5e404c3ffd0df4890f32bccf3232e56ca3 --restart=Never --rm -- /bin/bash

[Dmitry Shnyrev]

ДА!!!! Как раз параллельно нашел причину. Надо было temp_pod_1 добавить. Под этим именем pod появляется в списке Workloads в GKE.

Спасибо!!!! То что надо!!!!

[Dmitry Shnyrev]

Дмитрий Шицков, спасибо за сам ответ. В общем вы ответили на мой вопрос. Но поигравшись понял что кое чего не хватает :( Дело в том что для запуска самого приложения у нас огромный yaml и там тонна Env Vars прописана. Команда из вашего ответа не учитывает этот yaml и это логично (просто поднимается докер контейнер из image). Есть ли какой-то способ поднять наш pod с настройками из yaml файла который используется для Deployment?

[Дмитрий Шицков]

Dmitry Shnyrev, хитрые вы задачи придумываете. Никогда так не пробовал и не уверен, возможно ли это с использованием "run". Он упрощенный аналог docker run.
Для задачи когда нужен интерактив я бы выдрал из Deployment описание поды и создал бы на основе него описание отдельного "mypod" Pod в yaml со всеми монтируемыми конфигами и переменными окружения.

kubectl apply -f ./mypod.yaml
kubectl exec -it mypod -- bash

А для неинтерактивных случаев запуска - Job

[Dmitry Shnyrev]

Ну отчего ж хитрые задачи. Задачи очень даже простые и понятные. Есть большой Django проект. Кроме того что он просто запускается в нем еще запилено кучу кастосных cli тулов которые запускаются в контексте данного django проекта вручную (https://docs.djangoproject.com/en/3.2/howto/custom...).
запускать эти комманды в обычных подах в которых крутится сам Django не лучший вариант. Надо использовать отдельное окружение, но оно должно быть приближено к проду.
Пока работали с Хероку все выглядено крайне просто - сделал
heroku run bash --app my-app
отработал и закрыл.
Даже написали несколько интересных тестовых стенда, которые используя heroku cli запускали разные скрипты на "продакшен" подах. Само web приложение крутится по себе, скрипты запускаются в изолированных окружениях, отрабатывают и умирают.

Думал что в гугл/кубернейт такое тоже имеется. Но по ходу сравнивать Хероку с Кубернейтс не совсем корректно.

Буду развивать эту тему :)

[Дмитрий Шицков]

Dmitry Shnyrev, у вас подход просто, похоже, со времени эксплуатации проекта на vm.
Консольная админка у нас на старых монолитах на php уже осталась. Все новые микросервисы немутабельны, либо это редеплой с новой конфигурацией. Поэтому для меня - это хитрые задачи, еще и с нарушением безопасности :-)

Посмотрите в сторону remote cli у django, вроде есть у него такая реализация. Тогда можно административную поду отдельно держать от основного проекта.

Еще вариант - держать второй деплоцмент для администрирования. Делать scale 1,выполнять работы и делать scale 0.

Answer 2

[killla]

Подними рядом точно такой же деплоймент да и всё. Обзови как-нибудь dev-deployment. Енвы точно также прокинь из того же конфигмапа/секрета.
Если надо поменяй в конфигах базу на тестовую, например.
Если надо, чтоб джанга не запускалась, переопредели в темплейте command и arg с запуска джанги на баш.
Колхозить так по полному))