How to run a kubernetes cronjob in the same pod?-CodePudding

I have a cronjob that spins up a new pod every time it runs. This causes some clutter when looking through the list of pods. Is there a way to reuse the same pod everytime? Or define a statefulset for the cronjob to use? thanks

CodePudding user response：

You could use crond and setup a crontab in there. The pod would constantly be running though. But this is often better if you have a cron that has a very short scheduled -- i.e. every minute or every few minutes.

CodePudding user response：

A very simple approach is to use busybox crond, which can be run as deployment or even as a sidecar container beside your main app container (whatever fits your purpose the best).

Here is a simple pod definition. The image must contain busybox. It first creates the crontab file with the required one or more entries for the corresponding user and then runs busybox's crond:

apiVersion: v1
kind: Pod
metadata:
  name: busybox-crond-pod
spec:
  containers:
  # image must contain busybox
  - image: busybox:latest
    name: cron
    command:
    - sh
    - -c
    - |
      mkdir -p /var/spool/cron/crontabs
      # Example of job definition:
      #     .------------------ minute (0 - 59)
      #     |  .--------------- hour (0 - 23)
      #     |  |  .------------ day of month (1 - 31)
      #     |  |  |  .--------- month (1 - 12) OR jan,feb,mar,apr ...
      #     |  |  |  |  .------ day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
      #     |  |  |  |  |  .--- command to be executed
      #     |  |  |  |  |  |    user under which to run the command ---------------.
      #     |  |  |  |  |  |                                                       |
      echo '*  *  *  *  *  echo $(date) running my job' > /var/spool/cron/crontabs/root
      exec busybox crond -f -l 0 -L /dev/stdout -c /var/spool/cron/crontabs

CodePudding user response：

If you just want to get rid of the remaining pods after job execution you can configure your cronjob accordingly.

You can now set history limits, or disable history altogether, so that failed or successful CronJobs are not kept around indefinitely. See my answer here. Documentation is here.

To set the history limits:

The .spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish.