Skip to main content
In this lab we examine how container processes are defined and overridden in Kubernetes Pods using command and args. You will learn how to inspect running Pods, write correct manifests, fix YAML type errors, replace immutable fields, and understand how Docker ENTRYPOINT/CMD interact with Kubernetes command/args. Related reading:

​
1) How many pods exist and what command runs the Pod?

There was one Pod on the cluster. Inspect the Pod ubuntu-sleeper to view the container and the command specified for it:
Excerpt from the output:
Explanation:
  • The container’s Command is shown as an array where the first element is the executable sleep and the second element is the argument 4800.
  • In effect, the container is running the process sleep 4800.

​
2) Create a Pod that sleeps for 5,000 seconds (ubuntu-sleeper-2)

You are given a basic manifest ubuntu-sleeper-2.yaml. Update it so the container runs sleep for 5000 seconds. Remember that Kubernetes expects command and args arrays to contain strings. Initial manifest:
Modified manifest using command + args:
Create the Pod:
Expected output:
Verify with kubectl describe — you should see Command: sleep and Args: 5000:
Tip: You can also place the executable and its argument together in command, e.g. command: ["sleep", "5000"]. Using command + args separately often makes intent clearer.

​
3) Fix the manifest ubuntu-sleeper-3.yaml (type errors in command elements)

A manifest attempted to set the container’s command like this:
Problem:
  • YAML parses unquoted numbers as numeric types. Kubernetes expects each element of the command array to be a string; non-string elements cause API server errors.
Observed error:
Fix by quoting the numeric element:
Create the fixed Pod:
Expected:

​
4) Update the Pod ubuntu-sleeper-3 to sleep for 2000 seconds

Some Pod fields are immutable after creation (for example, the container command/entrypoint). Editing the in-cluster object with kubectl edit pod to change the container command will typically be forbidden. Two safe ways to update an immutable field:
  • Edit your local manifest file (source YAML) and recreate the Pod.
  • Force replace the Pod using kubectl replace --force -f <file>, which deletes and recreates the Pod from the provided file.
Example workflow:
  1. Update local manifest to set args to 2000:
  1. Replace the Pod by deleting and recreating (force replace):
Sample output:
Note that deleting a Pod sends a termination signal to the process inside the container and the Pod may take some time to terminate gracefully depending on the process and termination grace period.
If you need to change immutable fields of a Pod, update the manifest and recreate the Pod. For production workloads, use controllers (Deployments, StatefulSets, etc.) that support rolling updates and avoid manual Pod replacements.

​
5) Inspecting Dockerfiles and how runtime commands are composed

Review the Dockerfile at /root/webapp-color/Dockerfile:
Key points:
  • ENTRYPOINT is ["python", "app.py"].
  • If the image also has a CMD, Docker will pass the CMD values as arguments to the ENTRYPOINT unless overriden at runtime.
Example variant with CMD (Dockerfile2):
If you run a container from this image with no overrides, the final executed command is:
Docker composes ENTRYPOINT (executable) + CMD (default arguments) by default.

​
6) Kubernetes manifest: overriding ENTRYPOINT vs. providing args

In the webapp-color-2 example, the files include:
  • Dockerfile2 (as above)
  • Kubernetes Pod manifest webapp-color-pod.yaml:
Behavior:
  • In Kubernetes, spec.containers.command maps to Docker’s ENTRYPOINT — it replaces the image’s ENTRYPOINT.
  • spec.containers.args maps to Docker’s CMD — it overrides or supplies arguments passed to the image’s ENTRYPOINT.
Because the manifest above sets command: ["--color", "green"], Kubernetes will attempt to run --color as the executable, which will fail (because --color is an argument, not a binary). If the intent is to run the image’s ENTRYPOINT (python app.py) and pass --color green, use args instead:
This will result in the container running:
Important: command replaces the container ENTRYPOINT. Use args to supply or override the CMD (i.e., arguments) while preserving the image’s ENTRYPOINT executable.

​
Quick Reference: ENTRYPOINT/CMD vs. Kubernetes command/args

This completes the walkthrough for: inspecting Pods, specifying command/args in manifests, correcting YAML type errors, updating immutable fields by recreating Pods, and understanding how Docker ENTRYPOINT/CMD interact with Kubernetes command/args.

Watch Video