Files

107 lines
4.1 KiB
Markdown

# Assignment
The Nautilus DevOps team is crafting jobs in the Kubernetes cluster. While they're developing actual scripts/commands, they're currently setting up templates and testing jobs with dummy commands. Please create a job template as per details given below:
Create a job named countdown-datacenter.
The spec template should be named countdown-datacenter (under metadata), and the container should be named container-countdown-datacenter
Utilize image ubuntu with latest tag (ensure to specify as ubuntu:latest), and set the restart policy to Never.
Execute the command sleep 5
Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.
# Solution
# Kubernetes Job — `countdown-datacenter`
A one-shot Job that runs `sleep 5` in an `ubuntu:latest` container. Applied inline via a
heredoc — no manifest file on disk.
## Apply (heredoc → kubectl)
```bash
kubectl apply -f - <<'EOF'
apiVersion: batch/v1
kind: Job
metadata:
name: countdown-datacenter
spec:
template:
metadata:
name: countdown-datacenter
spec:
containers:
- name: container-countdown-datacenter
image: ubuntu:latest
command:
- sleep
- "5"
restartPolicy: Never
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 the manifest literal —
the right default for Kubernetes YAML.
### Job vs. CronJob
A **Job** runs a pod to **completion** once (or a set number of times), unlike a CronJob
which spawns Jobs on a schedule. So there's no `schedule` or `jobTemplate` here — the pod
template sits directly under `spec.template`, one level shallower than a CronJob.
### Field by field
- **`apiVersion: batch/v1` / `kind: Job`** — Job is a `batch/v1` object.
- **`metadata.name: countdown-datacenter`** — the Job's name, exactly as required.
- **`spec.template.metadata.name: countdown-datacenter`** — the pod template name, as the
task explicitly requests. (Note: a template name is optional and normally ignored for
Jobs — the actual pod gets an auto-generated name like `countdown-datacenter-abcde` — but
the task asks for it, so it's set.)
- **`spec.template.spec.containers`** — one container:
- **`name: container-countdown-datacenter`** — the container name, exactly as required.
- **`image: ubuntu:latest`** — tag stated explicitly, as required.
- **`command: ["sleep", "5"]`** — the dummy command. The `"5"` is **quoted** so YAML
passes it as a string argument; command args must be strings, and an unquoted `5` would
be parsed as an integer and rejected.
- **`restartPolicy: Never`** — required. It sits at the **pod** level (inside
`template.spec`), not on the container. Jobs accept only `Never` or `OnFailure` (`Always`
is invalid for batch workloads). `Never` means if the pod fails, the Job creates a *new*
pod rather than restarting the existing one.
### `restartPolicy: Never` vs. `OnFailure` for Jobs
Both are valid for Jobs, and they differ in failure handling:
- **`Never`** — a failed pod is left as-is; the Job spins up a fresh pod for the next
attempt. You end up with visible failed pods (useful for debugging).
- **`OnFailure`** — the same pod's container is restarted in place.
The task specifies `Never`, so failed attempts (if any) appear as separate pods.
## Verify
```bash
# Job created and completing
kubectl get job countdown-datacenter
# Pod runs then completes
kubectl get pods -l job-name=countdown-datacenter
# Confirm image and command
kubectl get job countdown-datacenter \
-o jsonpath='{.spec.template.spec.containers[0].image}{" "}{.spec.template.spec.containers[0].command}{"\n"}'
```
Expected — `countdown-datacenter` showing `COMPLETIONS 1/1` after ~5 seconds, its pod
transitioning `Running``Completed`, and the jsonpath printing `ubuntu:latest [sleep 5]`.
> The pod runs `sleep 5` then exits 0, so the Job completes cleanly. If it shows `Error`,
> check `kubectl logs job/countdown-datacenter`.