1

I am just learning containers and kubernetes and everything around it. There has been a use case to build a reliable setup, where we can store all our python scripts(small, usecase defined scripts that do one only job each). There are some scripts in other languages like perl too.

Not sure if this is the correct place to ask, but I will ask anyway.

The requirement is to build a solution that will have less to no dependency on the underlying operating system so even if we were to switch operating systems/servers in the future, the scripts can remain/run as it is.

Was thinking if I can build a 2 node kubernetes cluster and run each script in a container and trigger them using a cron job. Not sure if this is an optimal and efficient approach. The python virtual environments is not our way to go given the python version is symmlinked back to the python version on the server, causing a server/os dependency.

Appreciate any ideas and advice if someone else has done something similar. I've google enough for such usecases. Didn't find solutions that match specifically to my need. But please feel free to share, ideas, thoughts any good reads too. Thanks!

Note: The server operating system is RHEL 8 and above

Sudhi
  • 421
  • 1
  • 8
  • 19
  • 1
    The python version for a virtualenv isn't necessarily linked to your system python version. The `pyenv` tool for example lets you have multiple pythons and switch between them at will. You can of course do this in containers too – Richard Huxton Mar 15 '23 at 09:57

1 Answers1

1

The idea of ​​containerizing your scripts allows you to have a highly customized "environment" that doesn't change wherever you deploy it.

For the management of these containers then, you decide according to your needs... If they are management scripts, you can think of creating a management Pod that always stays up&running (I'll link you below a couple of examples on how Do).

How can I keep a container running on Kubernetes?

Otherwise, it may be a good idea to prepare a Job and run it as needed.

In case of PROD, remember to have at least 3 nodes (HA), do a pre-assessment to understand how many resources you can assign to your Pods (assuming that the resource consumption of these scripts has already been tested), think about the roles assigned to Worker nodes, so as to avoid Pods being randomly scheduled everywhere (perhaps where there is a business critical workload that risks saturating resources), autoscaling, etc.

glv
  • 994
  • 1
  • 1
  • 15