Kubernetes - Cron Jobs

Topic

In Kubernetes, you can create cron jobs that run on a scheduled interval. I want to dive a little bit more into how those are executed and maybe learn a bit more about what the Kubernetes execution model looks like.

Conjecture

Ok, so Kubernetes. I have a very shallow understanding of what Kubernetes is. My mental model is that it is an orchestration framework for running containerized software. (Side question: Is software containerized? Not quite — what gets containerized is the environment. A container is the app plus its dependencies and system libraries packaged together so it runs the same everywhere.) Essentially, when you want to run a set of containers Kubenetes allows you to set up a Cluster on a server. You then deploy your containers in Pods. The pods have useful properties when they are all discrete, so they can be created, updated, and restarted independently of each other.

The question is, where do these cron jobs fit into the broader execution model of Kubernetes? Essentially, a lot of the Kubernetes cluster is about configuration, so there are a lot of Helm charts and markdown files that describe exactly what containers or workloads should be executed. I would assume that a cron job is similar to a pod but has a different set of “workload instructions.” I assume that it is a set of instructions that can be run on an existing pod.

Research

Ok so my general mental model for Kubernetes is basically correct. According to its website Kubernetes, also known as K8s is a “system” for automating the deployment and scaling of containerized applications.

As I already mention the concept of a “pod” is very useful because it allows you to have a discrete execution context for your containerized application. When scaling, you can have multiple “pods” running of the same application, and then you can distribute requests between all of them. The abstractions behind “pods” and “workloads” allows you to group your the different parts of your application into logical units.

Here is another definition of K8s:

Kubernetes provides you with a framework to run distributed systems resiliently.

So the proper way to describe Kubernetes is as an execution framework for distributed systems.

The key features that K8s provide are:

• Service Discovery and load balancing

• Storage orchestration - Your containers can have many different data sources

• Automated Rollout and rollbacks - You can easily deploy new containers or roll back old ones

• Automatic bin packing - don’t know what this means - ah this has to do with defining how many resources a container can use and then K8s will efficiently pack the workloads appropriate to a specific node into it, given the capacity of the node.

• Self healing - this is what I was talking about earlier about automatically restarting pods that crash

• Secret and config management - Secure management of ssh, api keys for your pods.

• Batch execution - Can manage CI/CD and batch updates, I think this might be where cron jobs fit!

• IPv4/IPv6 dual-stack - Essentially you can control how your cluster is exposed to the open web

• Extensibility - You can add features to your cluster without changing the upstream source code

It is important to note. Kubernetes is a framework for running containers so it is hardware agnostic. It has a lot of built-in tools that users can use to deploy their applications but it doesn’t require you to use any of them.

Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration.

That line tripped me up, since I had just finished calling K8s an orchestration framework. The distinction being drawn is that orchestration implies a defined sequence — do A, then B, then C. Kubernetes doesn’t work that way. You declare the end state you want and independent controllers continuously drive the system toward it. There is no script to run, so there is nothing to orchestrate.

Ok but I am getting a little off track here. I think there are a lot more explorations to be written on the K8s; this one is focused on trying to understand how cron jobs fit into the general architecture.

Essentially my theory that a cron job is similar to a pod is correct. It is classified as a workload. It is a job that is executed on a repeating schedule. The most common uses are for backing up databases, generating reports, etc. When the “Control plane” (the components that actually run the cluster — API server, scheduler, etcd, controller manager; I take this apart properly in Setting up a K8 Cluster) creates a new job based on the CronJob configuration, it creates a short-lived pod to execute the job.

Here is an example of what a CronJob manifest looks like:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

Final Summary

You should think of K8s as a framework for automating the deployment of your application. You describe the containers of your application as workloads. K8s automate the orchestration of these workloads. One of the workloads you can define is a CronJob. Unlike a normal pod, it is deliberately ephemeral. A pod is spun up on a schedule to perform a specific job and then the pod is killed.