Assignment

The Nautilus DevOps team is setting up recurring tasks on different schedules. Currently, they're developing scripts to be executed periodically. To kickstart the process, they're creating cron jobs in the Kubernetes cluster with placeholder commands. Follow the instructions below:

Create a cronjob named datacenter.

Set Its schedule to something like */12 * * * *. You can set any schedule for now.

Name the container cron-datacenter.

Utilize the httpd image with latest tag (specify as httpd:latest).

Execute the dummy command echo Welcome to xfusioncorp!.

Ensure the restart policy is OnFailure.

Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.

Solution

Kubernetes CronJob — `datacenter`

A CronJob that runs echo Welcome to xfusioncorp! in an httpd:latest container on a schedule. Applied inline via a heredoc — no manifest file on disk.

Apply (heredoc → kubectl)

kubectl apply -f - <<'EOF'
apiVersion: batch/v1
kind: CronJob
metadata:
  name: datacenter
spec:
  schedule: "*/12 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: cron-datacenter
              image: httpd:latest
              command:
                - /bin/sh
                - -c
                - echo Welcome to xfusioncorp!
          restartPolicy: OnFailure
EOF

How it works

The heredoc apply pattern

kubectl apply -f - reads from stdin; the heredoc feeds the YAML in, nothing on disk.
<<'EOF' (delimiter quoted) disables shell expansion, keeping $VAR/backticks literal — important here so echo Welcome to xfusioncorp! is stored verbatim rather than evaluated by the jump-host's shell.

The nested structure — the part that trips people up

A CronJob wraps three levels deep. From outside in:

CronJob.spec — the schedule and how to spawn jobs.
jobTemplate.spec — the Job created on each tick.
template.spec — the Pod the Job runs.

So the container and restart policy live at spec.jobTemplate.spec.template.spec, not directly under the CronJob. Getting the nesting wrong is the most common CronJob error.

Field by field

apiVersion: batch/v1 / kind: CronJob — CronJob is a batch/v1 object (stable since Kubernetes 1.21; the old batch/v1beta1 is removed in modern clusters — use batch/v1).
metadata.name: datacenter — the CronJob name, exactly as required.
spec.schedule: "*/12 * * * *" — standard cron syntax (minute hour day-of-month month day-of-week). */12 * * * * = every 12 minutes. The task allows any schedule; quote the string so YAML doesn't choke on the *.
jobTemplate.spec.template.spec.containers — one container:
- name: cron-datacenter — the container name, exactly as required.
- image: httpd:latest — tag stated explicitly, as required.
- command — the dummy command. Written as ["/bin/sh","-c","echo Welcome to xfusioncorp!"] so the shell handles the phrase as one command. command overrides the image's default entrypoint (httpd's web server), which is what we want — this is a one-shot echo, not a running server.
restartPolicy: OnFailure — required. It sits at the pod level (inside template.spec), not on the container. For Jobs/CronJobs only OnFailure and Never are valid (Always is rejected, since a batch job is meant to complete, not run forever). OnFailure restarts the pod if the command exits non-zero.

Why `command` uses `/bin/sh -c`

Passing the echo through sh -c runs it as a shell command, so the full phrase (with its spaces and !) is handled correctly as a single string. Listing bare args instead would also work for a simple echo, but the sh -c form is robust and the common pattern for dummy commands.

Verify

# CronJob registered with the schedule
kubectl get cronjob datacenter

# After a scheduled tick, a Job (and its pod) appears
kubectl get jobs -l job-name --watch      # Ctrl-C once one shows
kubectl get pods -l job-name

# Check the output of a completed run
kubectl logs job/<job-name-from-above>

Expected — datacenter listed with schedule */12 * * * *; after a tick, a Job runs to completion and its pod's logs show Welcome to xfusioncorp!.

To trigger a run immediately instead of waiting for the schedule: kubectl create job --from=cronjob/datacenter datacenter-manual

4.4 KiB Raw Blame History