Commands and Arguments in Kubernetes

In this lesson we focus on how container commands and arguments (ENTRYPOINT and CMD from a Dockerfile) map into Kubernetes Pod manifests using the command and args fields. Understanding this mapping helps you control how containers start and what parameters they receive when running in a cluster.

A presentation slide titled "Application – Commands and Arguments" with the text on the left and a white list/icon set against a dark blue curved panel on the right. The slide includes a small "© Copyright KodeKloud" notice in the bottom-left.

Earlier we built a simple Docker image named ubuntu-sleeper. That image runs a sleep command for a default number of seconds (5 seconds in the original example). When you run the image locally with Docker, any extra tokens you append to docker run are passed as arguments to the container process. Example Docker runs:

# Use the image's default behavior
docker run --name ubuntu-sleeper ubuntu-sleeper

# Override the default CMD by passing "10" as a runtime argument
docker run --name ubuntu-sleeper ubuntu-sleeper 10

Anything appended after the image name on docker run becomes the container’s command-line arguments. In Kubernetes Pod manifests, the equivalent is the args field (an array of strings). Example Pod manifest that overrides the image’s default CMD by providing an argument of 10:

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper-pod
spec:
  containers:
    - name: ubuntu-sleeper
      image: ubuntu-sleeper
      args: ["10"]

How Dockerfile instructions relate to Kubernetes fields

In a Dockerfile:
- ENTRYPOINT defines the executable that runs when the container starts.
- CMD defines default parameters for the ENTRYPOINT (or, if no ENTRYPOINT is set, CMD can be a command to run).
In a Kubernetes Pod manifest:
- command corresponds to Dockerfile ENTRYPOINT. Setting command in the manifest replaces the image’s ENTRYPOINT.
- args corresponds to Dockerfile CMD. Setting args in the manifest replaces the image’s CMD.

You can also view this mapping in a compact table:

Dockerfile	Kubernetes field	Effect
`ENTRYPOINT`	`command`	Replaces image ENTRYPOINT; defines the container executable
`CMD`	`args`	Replaces image CMD; provides default arguments to the ENTRYPOINT

Tip: Use arrays for command and args (e.g. ["sleep", "10"]) to avoid shell interpretation differences. Kubernetes expects lists of strings for these fields and will not perform shell expansion unless you intentionally run a shell executable like ["/bin/sh", "-c", "echo hello"].

If you need to override both ENTRYPOINT and CMD (for example, replace the ENTRYPOINT with a hypothetical sleep2.0 command and pass 10 as its argument), include both command and args:

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper-pod
spec:
  containers:
    - name: ubuntu-sleeper
      image: ubuntu-sleeper
      command: ["sleep2.0"]
      args: ["10"]

Mapping summary:

Pod command overrides Dockerfile ENTRYPOINT.
Pod args overrides Dockerfile CMD.

Resources and further reading:

Kubernetes: Pod lifecycle and containers — https://kubernetes.io/docs/concepts/workloads/pods/
Docker: ENTRYPOINT vs CMD — https://docs.docker.com/engine/reference/builder/#entrypoint

Practice by inspecting Pod YAMLs and experimenting with different command and args combinations to see how they change container startup behavior.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Commands and Arguments in Kubernetes

Watch Video

Practice Lab