kubectl run --command vs -- arguments

12/9/2019

I was a little confused with below command:

kubectl run busybox --image=busybox --restart=Never -o yaml --dry-run -- /bin/sh -c 'echo hello;sleep 3600'

YAML:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: busybox
  name: busybox
spec:
  containers:
  - args:
    - /bin/sh
    - -c
    - echo hello;sleep 3600
    image: busybox
    name: busybox
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

I know if we don't specify parameter --command, then parameters after -- will be treated as arguments.

But I wanted to know, how /bin/sh -c "echo hello;sleep 3600" was working in case of arguments? According to Kubernetes documentation(https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#notes), If we specify only arguments in a POD then docker EntryPoint will be used as EntryPoint command. So the resultant command which will be executed in the docker image will be Docker EntryPoint + kubectl arguments.

As Busybox DockerFile does not contain any EntryPoint(https://github.com/docker-library/busybox/blob/master/musl/Dockerfile), so arguments specified in the kubectl command will only be used, so the command will look like:

/bin/sh -c 'echo hello;sleep 3600'

And if we specify --command, then according to Kubernetes documentation, DockerFile arguments(CMD) and command(EntryPoint) both will be overridden with command specified in the kubectl command, so it will look similar to above:

/bin/sh -c 'echo hello;sleep 3600'

So it would be same in the end.

-- Amit Thakkar
arguments
busybox
command
kubectl
kubernetes

1 Answer

12/10/2019

In this example, yes both are same. Lets say if an entry point (command) is set as sleep 1000 but if your args are set as sleep 3000 then container command is ignored and sleep 3000 is executed.

Args takes precedence over command, and overrides command values if args exists

-- ARU
Source: StackOverflow