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.
If you supply a command but no args for a Container, only the supplied command is used. The default EntryPoint and the default Cmd defined in the Docker image are ignored. If you supply only args for a Container, the default Entrypoint defined in the Docker image is run with the args that you supplied.
kubectl run − Run command has the capability to run an image on the Kubernetes cluster. kubectl scale − It will scale the size of Kubernetes Deployments, ReplicaSet, Replication Controller, or job. kubectl set image − It updates the image of a pod template.
The key difference between kubectl apply and create is that apply creates Kubernetes objects through a declarative syntax, while the create command is imperative. The command set kubectl apply is used at a terminal's command-line window to create or modify Kubernetes resources defined in a manifest file.
kubectl rollout − It is capable of managing the rollout of deployment. kubectl run − Run command has the capability to run an image on the Kubernetes cluster. kubectl scale − It will scale the size of Kubernetes Deployments, ReplicaSet, Replication Controller, or job.
This allows to directly edit a resource which one can receive via the command line tool. kubectl exec − This helps to execute a command in the container. kubectl expose − This is used to expose the Kubernetes objects such as pod, replication controller, and service as a new Kubernetes service.
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: So it would be same in the end. Show activity on this post.
If --resource-version is specified and does not match the current resource version on the server the command will fail. Use "kubectl api-resources" for a complete list of supported resources. $ kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]
When working with containers in Kubernetes, you should be careful not to mix up Kubenetes command
and Docker Cmd
.
command
field in Kubernetes corresponds to the EntryPoint
field in Dockerargs
field in Kubernetes corresponds to the Cmd
field in DockerFrom Kubernets documentation:
When you override the default
Entrypoint
andCmd
, these rules apply:
If you do not supply
command
orargs
for a Container, the defaults defined in the Docker image are used.If you supply a
command
but noargs
for a Container, only the suppliedcommand
is used. The defaultEntryPoint
and the defaultCmd
defined in the Docker image are ignored.If you supply only
args
for a Container, the defaultEntrypoint
defined in the Docker image is run with theargs
that you supplied.If you supply a
command
andargs
, the defaultEntrypoint
and the defaultCmd
defined in the Docker image are ignored. Yourcommand
is run with yourargs
.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With