Practical Override Scenarios

The command override syntax is tested directly on the CKA exam. You will be asked to create a Pod that runs a specific command, often something like “run a container with the sleep command” or “create a Job that echoes a value”. This lesson builds muscle memory for the three most common patterns.

Pattern 1: Quick one-liner with kubectl run

The kubectl run command has a --command flag that sets the Pod’s command field, and any arguments after -- become the args:

kubectl run sleeper --image=busybox:1.36 --restart=Never --command -- sleep 3600

Check the result:

kubectl get pod sleeper -o yaml

Look at the container spec. You will see:

command:
  - sleep
args:
  - '3600'

kubectl run with --command and -- <args> produces the correct YAML structure. This is the fastest way to create an overriding Pod on the exam.

Pattern 2: Generating YAML with —dry-run

For multi-container Pods or when you need to add other fields, generate the YAML first and edit it:

kubectl run sleeper --image=busybox:1.36 --restart=Never --command --dry-run=client -o yaml -- sleep 3600 > sleeper.yaml

Open the file:

cat sleeper.yaml

Edit it to add additional containers or other fields, then apply:

kubectl apply -f sleeper.yaml

This is the exam workflow: generate a skeleton, edit, apply. Do not write the full YAML from scratch if kubectl run can produce the structure for you.

Pattern 3: Overriding command in a Job

Jobs often need a specific command to run the task. The pattern is the same as in a regular Pod:

nano hash-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: hash-job
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: hasher
          image: busybox:1.36
          command: ['sh', '-c', 'echo "data to hash" | sha256sum']

kubectl apply -f hash-job.yaml
kubectl logs job/hash-job

The Job runs the sha256sum command on a string and prints the result. The command field replaces whatever the busybox image would normally run.

Diagnosing command-related failures

A Pod stuck in CrashLoopBackOff immediately after creation often means the command failed to start. Two diagnostic steps:

kubectl describe pod <pod-name>

Look at State under the container section. If Reason: Error appears with Exit Code: 127, the executable was not found. Exit code 126 means found but not executable. Exit code 1 is a general runtime error.

kubectl logs <pod-name>

If the process started but crashed, the logs contain the error output. If the container fails before producing any output, the logs will be empty and the describe output is the primary signal.

kubectl delete pod sleeper
kubectl delete job hash-job

kubectl run --command for quick Pods, --dry-run=client -o yaml for editing before applying, and explicit command+args in Job templates: these three patterns cover the vast majority of command override scenarios you will encounter. The next module covers ConfigMaps, which provide a structured way to inject configuration into containers without baking it into the image.