Difference between Docker ENTRYPOINT and Kubernetes container spec COMMAND? Difference between Docker ENTRYPOINT and Kubernetes container spec COMMAND? kubernetes kubernetes

Difference between Docker ENTRYPOINT and Kubernetes container spec COMMAND?


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 defaultsdefined in the Docker image are used.
  • If you supply only args for a Container, the default Entrypointdefined in the Docker image is run with the args that you supplied.
  • If you supply a command for a Container, only thesupplied command is used. The default EntryPoint and the default Cmddefined in the Docker image are ignored. Your command isrun with the args supplied (or no args if none supplied).

Here is an example:

Dockerfile:

FROM alpine:latestCOPY "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/


The key difference is terminology. Kubernetes thought that the terms that Docker used to define the interface toa 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.


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