So far we scheduled our pods manually but this way we don't leverage any of the cool features of Kubernetes, like scaling up and down automatically or self-healing the system when needed.

A Deployment is an object that logically groups pods together according to our specifications. An example of specification is the number of desired pods that must run at any given time no matter what. If a pod dies, we want Kubernetes to bring another one up to replace it; if pods are more than we asked for, we want Kubernetes to kill as many as needed to match our request.

Exercise n.1: manage a deployment

Change directory into the folder definitions before running these commands.

Create a Deployment called nginx-prod:

$ kubectl apply -f nginx-prod.yaml
deployment.apps/nginx-prod created

Now let's ask kubectl to list all the objects present in the cluster to see what happened:

$ kubectl get all
NAME                             READY   STATUS    RESTARTS   AGE
pod/nginx-prod-d6fd669f4-8tng2   1/1     Running   0          102s
pod/nginx-prod-d6fd669f4-9x57t   1/1     Running   0          102s
pod/nginx-prod-d6fd669f4-fpxqw   1/1     Running   0          102s

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-prod   3/3     3            3           102s

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-prod-d6fd669f4   3         3         3       102s

As you can see there are now 3 pods, 1 deployment and 1 object we haven't seen yet, a Replicaset. A replicaset has the only responsibility to keep a certain number of pods running at any time; in this case, since our deployment specs defined 3 replicas for our pod, while creating the deployment Kubernetes also attached a replicaset to it.

If you run a kubectl describe on the replicaset, you'll notice that it is under the control of our deployment:

$ kubectl describe replicaset <the name of the replicaset>
Name:           nginx-prod-d6fd669f4
Namespace:      default
Controlled By:  Deployment/nginx-prod

Now let's see the replicaset in action: we're going to kill one pod and see if another one starts to take its place.

$ kubectl delete pod <the name of the pod>
pod "the name of the pod" deleted

Respawning a new pod is almost instantaneous, so by the time you run this command again:

kubectl get pods

you'll see that a new pod with a different name has started, bringing back the pod count to 3.