One of the reasons I stood up a Kubernetes cluster on Raspberry Pis[1] in my house was because I wanted to gain savings by not running high-available, redundant infrastructure in the cloud. Kubernetes provides high availability by design. The possibilities that this capability offers are pretty awesome. Need a web server to run constantly? Build a container and throw it in the Kubernetes cluster. Need a service available all the time? Package it and ship it to the Kubernetes cluster.
Legacy systems
I have four old Raspberry Pi boxes doing various things here in the office. They do a single task fine, but I have over-extended one of the first-generation Raspberry Pis. I’d like to deprecate the older Raspberry Pis as they are no longer effective. To do that, I need to move the workloads (like a cloud migration). One thing I have no shortage of running on these Raspberry Pi boxes are cron jobs. I have a cron for almost everything I do: Monitoring, updating web apps, detecting changes in domain name configurations, etc.
k8s jobs and cron jobs
Kubernetes has the concept of jobs. To quote the official jobs documentation[2], "A job creates one or more pods and ensures that a specified number of them successfully terminate." If you have a pod that needs to run until completion, no matter what, a Kubernetes job is for you. Think of a job as a batch processor.Kubernetes cron jobs[3] are a relatively new thing. But I am ecstatic that this is a standard feature in modern Kubernetes clusters. It means that I can tell the cluster one time that I want a job to run at certain times. Since cron jobs build on top of