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)

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

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

4.1 KiB Raw Blame History