# 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)

```bash
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:

1. **`CronJob.spec`** — the schedule and how to spawn jobs.
2. **`jobTemplate.spec`** — the **Job** created on each tick.
3. **`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

```bash
# 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`