> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Lab Solution Commands and Arguments Optional > Guide on using Kubernetes pod command and args to control container processes, inspect Pods, fix YAML type errors, update immutable fields, and understand Docker ENTRYPOINT CMD interactions 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: * [Kubernetes Pods](https://kubernetes.io/docs/concepts/workloads/pods/) * [Kubernetes Container Lifecycle and Commands](https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/) * [Docker ENTRYPOINT and CMD](https://docs.docker.com/engine/reference/builder/#entrypoint) *** ## 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: ```bash theme={null} kubectl describe pod ubuntu-sleeper ``` Excerpt from the output: ```text theme={null} Name: ubuntu-sleeper Namespace: default Status: Running IP: 10.42.0.9 Containers: ubuntu: Image: ubuntu Command: sleep 4800 State: Running Ready: True Restart Count: 0 ``` 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: ```yaml theme={null} apiVersion: v1 kind: Pod metadata: name: ubuntu-sleeper-2 spec: containers: - name: ubuntu image: ubuntu ``` Modified manifest using `command` + `args`: ```yaml theme={null} apiVersion: v1 kind: Pod metadata: name: ubuntu-sleeper-2 spec: containers: - name: ubuntu image: ubuntu command: ["sleep"] args: ["5000"] ``` Create the Pod: ```bash theme={null} kubectl create -f ubuntu-sleeper-2.yaml ``` Expected output: ```text theme={null} pod/ubuntu-sleeper-2 created ``` Verify with `kubectl describe` — you should see `Command: sleep` and `Args: 5000`: ```text theme={null} Containers: ubuntu: Image: ubuntu Command: sleep Args: 5000 State: Running Ready: True ``` 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: ```yaml theme={null} apiVersion: v1 kind: Pod metadata: name: ubuntu-sleeper-3 spec: containers: - name: ubuntu image: ubuntu command: - "sleep" - 1200 ``` 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: ```text theme={null} Error from server (BadRequest): error when creating "ubuntu-sleeper-3.yaml": Pod in version "v1" cannot be handled as a Pod: json: cannot unmarshal number into Go struct field Container.spec.containers.command of type string ``` Fix by quoting the numeric element: ```yaml theme={null} apiVersion: v1 kind: Pod metadata: name: ubuntu-sleeper-3 spec: containers: - name: ubuntu image: ubuntu command: - "sleep" - "1200" ``` Create the fixed Pod: ```bash theme={null} kubectl create -f ubuntu-sleeper-3.yaml ``` Expected: ```text theme={null} pod/ubuntu-sleeper-3 created ``` *** ## 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 `, which deletes and recreates the Pod from the provided file. Example workflow: 1. Update local manifest to set `args` to `2000`: ```yaml theme={null} # ubuntu-sleeper-3.yaml (updated) apiVersion: v1 kind: Pod metadata: name: ubuntu-sleeper-3 spec: containers: - name: ubuntu image: ubuntu command: ["sleep"] args: ["2000"] ``` 2. Replace the Pod by deleting and recreating (force replace): ```bash theme={null} kubectl replace --force -f ubuntu-sleeper-3.yaml ``` Sample output: ```text theme={null} pod "ubuntu-sleeper-3" deleted pod/ubuntu-sleeper-3 replaced ``` 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`: ```dockerfile theme={null} FROM python:3.6-alpine RUN pip install flask COPY . /opt/ EXPOSE 8080 WORKDIR /opt ENTRYPOINT ["python", "app.py"] ``` 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): ```dockerfile theme={null} FROM python:3.6-alpine RUN pip install flask COPY . /opt/ EXPOSE 8080 WORKDIR /opt ENTRYPOINT ["python", "app.py"] CMD ["--color", "red"] ``` If you run a container from this image with no overrides, the final executed command is: ```text theme={null} python app.py --color red ``` 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`: ```yaml theme={null} apiVersion: v1 kind: Pod metadata: name: webapp-green labels: name: webapp-green spec: containers: - name: simple-webapp image: kodekloud/webapp-color command: ["--color", "green"] ``` 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: ```yaml theme={null} spec: containers: - name: simple-webapp image: kodekloud/webapp-color args: ["--color", "green"] ``` This will result in the container running: ```text theme={null} python app.py --color green ``` 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 | Context | Docker | Kubernetes | Result | | -: | - | - | - | | Executable | `ENTRYPOINT` | `spec.containers.command` | Replaces the image entrypoint | | Default arguments | `CMD` | `spec.containers.args` | Passed as arguments to the entrypoint | | Common use | `ENTRYPOINT ["python","app.py"]` + `CMD ["--color","red"]` | `args: ["--color","green"]` | Runs `python app.py --color green` | *** 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`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.