126 lines
4.4 KiB
Markdown
126 lines
4.4 KiB
Markdown
# 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` |