restart

While recently looking to creating Kubernetes manifests quickly for pods and deployments, I came across a really effective way of making either a job , deployment or pod manifest using the kubectl command.
The pivot on which type of resource is created is based around the "restart" value passed to kubectl command.

Lets me show you what I mean.

The kubectl run function is described in the kubernetes.io documentation  as "Run a specified image on the cluster". 

Check this command out first using the help function

	kubectl run --help
	Options:
	--allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in
	the template. Only applies to golang and jsonpath output formats.
	--attach=false: If true, wait for the Pod to start running, and then attach to the Pod as if 'kubectl attach ...'
	were called. Default false, unless '-i/--stdin' is set, in which case the default is true. With '--restart=Never' the
	exit code of the container process is returned.
	--cascade=true: If true, cascade the deletion of the resources managed by this resource (e.g. Pods created by a
	ReplicationController). Default true.
	--command=false: If true and extra arguments are present, use them as the 'command' field in the container, rather
	than the 'args' field which is the default.
	--dry-run=false: If true, only print the object that would be sent, without sending it.
	--env=[]: Environment variables to set in the container
	--expose=false: If true, a public, external service is created for the container(s) which are run
	-f, --filename=[]: to use to replace the resource.

view raw kubectl_run hosted with ❤ by GitHub

This produces an extensive list of examples and options for running resources with kubectl, and so is a very useful way to remember kubectl commands.

But, lets specifically get information on the restart option. We can do this by filtering the output related to this using grep.

	kubectl run --help | grep restart
	# Start a pod of busybox and keep it in the foreground, don't restart it if it exits.
	kubectl run -i -t busybox --image=busybox --restart=Never
	kubectl run pi --image=perl --restart=OnFailure -- perl -Mbignum=bpi -wle 'print bpi(2000)'
	kubectl run pi --schedule="0/5 * * * ?" --image=perl --restart=OnFailure -- perl -Mbignum=bpi -wle 'print bpi(2000)'
	--attach=false: If true, wait for the Pod to start running, and then attach to the Pod as if 'kubectl attach ...' were called. Default false, unless '-i/--stdin' is set, in which case the default is true. With '--restart=Never' the exit code of the container process is returned.
	--restart='Always': The restart policy for this Pod. Legal values [Always, OnFailure, Never]. If set to 'Always' a deployment is created, if set to 'OnFailure' a job is created, if set to 'Never', a regular pod is created. For the latter two --replicas must be 1. Default 'Always', for CronJobs `Never`.

view raw gistfile1.txt hosted with ❤ by GitHub

Now we can see the information related to the "restart" option and how different parameters for this will give us very different outcomes. The three options are:

1. Always
2. OnFailure
3. Never

As we can see from the kubectl --help output:
If set to 'Always' a deployment is created, if set to 'OnFailure' a job is created, if set to 'Never', a regular pod is created.

This is great news for speedily creating these very different resources by just changing the "restart" option

Let summarise these options and their sample use:

1. kubectl run optest --image=nginx  ---> creates a deployment called "optest" with 1 pod called "optest-<uniqueID>" , running an nginx container. Default restart=Always

2. kubectl run optest --image=nginx --restart=OnFailure  ---> creates a job called "optest" with 1 pod called "optest-<uniqueID>" , running an nginx container.

3. kubectl run optest --image=nginx --restart=Never  ---> creates a pod called "optest", running an nginx container. Default restart=Always


So, with a small bit of magic with the right options for the kubectl run command, we can create very different Kubernetes resources, at speed. Handy to know.