Difference between Docker ENTRYPOINT and Kubernetes container spec COMMAND?

Dockerfile has a parameter for ENTRYPOINT and while writing Kubernetes deployment YAML file, there is a parameter in Container spec for COMMAND.

I am not able to figure out what's the difference and how each is used?

Solution 1:

Kubernetes provides us with multiple options on how to use these commands:

When you override the default Entrypoint and Cmd in Kubernetes .yaml file, these rules apply:

• If you do not supply command or args for a Container, the defaults defined in the Docker image are used.
• If you supply only args for a Container, the default Entrypoint defined in the Docker image is run with the args that you supplied.
• If you supply a command for a Container, only the supplied command is used. The default EntryPoint and the default Cmd defined in the Docker image are ignored. Your command is run with the args supplied (or no args if none supplied).

Here is an example:

Dockerfile:

FROM alpine:latest
COPY "executable_file" /
ENTRYPOINT [ "./executable_file" ]

Kubernetes yaml file:

 spec:
    containers:
      - name: container_name
        image: image_name
        args: ["arg1", "arg2", "arg3"]

https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/

Solution 2:

The key difference is terminology. Kubernetes thought that the terms that Docker used to define the interface to a container were awkward, and so they used different, overlapping terms. Since the vast majority of containers Kubernetes orchestrates are Docker, confusion abounds.

Specifically, docker entrypoints are kubernetes commands, and docker commands are kubernetes args, as indicated here.

-------------------------------------------------------------------------------------
| Description                           | Docker field name | Kubernetes field name |
-------------------------------------------------------------------------------------
| The command run by the container      | Entrypoint        | command               |
| The arguments passed to the command   | Cmd               | args                  |
-------------------------------------------------------------------------------------

@Berk's description of how Kubernetes uses those runtime options is correct, but it's also correct for how docker run uses them, as long as you translate the terms. The key is to understand the interplay between image and run specifications in either system, and to translate terms whenever speaking of the other.

Solution 3:

The COMMAND in the YAML file overwrites anything mentioned in the ENTRYPOINT in the docker file.

Solution 4:

Basically the COMMAND can override what is mentioned in the docker ENTRYPOINT

Simple example:

To override the dockerfile ENTRYPOINT, just add these fields to your K8s template (Look at the command and args):

apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
  - name: command-demo-container
    image: debian
    command: ["/bin/sh"]
    args: ["-c", "printenv; #OR WHATEVER COMMAND YOU WANT"]
  restartPolicy: OnFailure

K8s docs:

command field corresponds to entrypoint in some container runtimes. Refer to the Notes below.

You can enter Notes link (K8s documentation for better understanding on how this command overrides the K8s ENTRYPOINT)