How to start a process in a separate Pod?

Question

Google Cloud Platform

Background of the question.
I worked with Heroku for a long time and got used to some specific features. Now we are migrating to the Google Cloud Platform with its GKE (Kubernetes) and the question has become to find an analogue of the fig from Heroku.

I need to run some processes (python scripts) in the context of my application. On Heroku, this is done like this:

heroku run bash --app my-app

What Heroku does is it raises a SEPARATE dyno (similar to Pod) without running the application itself (similar to EXEC from a Dockerfile) and provides access to the command line. I can run whatever I want and after that session exits the dyno is killed. A very handy thing when I need to run some scripts in an isolated production environment without affecting the already running dynos with the web application itself. Also, I can make such a separate dyno run the script as detached, which will allow the dyno to run until the end of the script execution and then die.

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

I can't find an analogue on GKE/Kubernates. All I could do was connect to an already running Pod
with such a command

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

. But I just need a separate clean pod where I can run all sorts of possibly destructive scripts that can gobble up all the memory and cpu and so that this does not affect the operation of the application itself.

What are the possible solutions?

Answer 1

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

With --rm , the pod will be removed after disconnecting from the terminal or after completing another command that was called instead of bash. Without it, it will simply stop - useful if you need logs in the cube after the work is completed.
Also look at the Kubernetes Job and CronJob features for a more declarative approach.

Answer 2

Raise exactly the same deployment nearby and that's it. Call it something dev-deployment. Envy just likewise from the same configmap/secret.
If necessary, change the database in the configs to the test one, for example.
If you want djanga not to start, redefine command and arg in the template from starting djanga to bash.
Farm so full))