Should I run taskiq worker and scheduler as Kubernetes jobs?

[devraj]

I am more seeking some advice around best practices to use taskiq in a Kubernetes cluster. Kubernetes Jobs are defined as

A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created. Suspending a Job will delete its active Pods until the Job is resumed again.

So in theory if the worker and scheduler kept running then the Pods would stay up.

You can see an initial attempt using kubernetes_job provider running the perl script.

If there are any Kubernetes users here, I would love your input as to if jobs are the right approach to running worker and scheduler in a cluster?

[s3rius]

No, run them as usual deployments. Because you might want to scale up number of workers. There's only one constraint on schedulers, there should be only one instance running (per schedule source, actually). But this constraint can be achieved by setting number of replicas to one.

Personally I use helm charts for my applications and both taskiq workers and schedulers are declared using the same deployment template, but with different command.

Also, declaring them as deployments allows you to specify really fancy scaling policy using keda.

[devraj]

Thanks for writing back. I might try and put together a sample helm chart for anyone else out there to use. I'll post it on a repository when I get it working.