[No Audio]
To avoid any confusion, let's start with a list of
the pods, by running kubectl get pods. We have
three Pods from our previous replica set. Let them
be where they are, and let's open our deployment.yaml file.
Let's start from the top. Just like
replica sets, deployments also use API version,
apps/v1. Their kind, or object type is
obviously Deployment, we have given it the name of
deploy -nginx. Let's go to the specs field.
We are using matchLabels strategy as selectors,
and we will be looking for Pods with label app: nginx.
Deployments are higher level
orchestration objects compared to replica sets.
So, if we are creating a deployment, a deployment
itself is capable of creating the replica set it
needs. By providing replicas field, we can instruct
the resultant replica to create a certain number
of Pods. Now let's go to the Pod template and fill
out the data. We will provide the labels app: nginx
to avoid any conflicts, and we will
provide the container information which include
name, which is deploy-container and container
image, which is nginx 1.7.9. We are back
to using images from Docker's registry, because well
they are just simple to write. After mentioning
the port, let's save and exit this file. As usual,
let's write kubetl create -f followed by
the name of the file which is deployment.yaml.
And our deployment is created. Let's have a list
of Pods again. And we have two new Pods here,
the top two Pods are nginx Pods created by deployment
deploy-nginx..
First of all, apart from
the label which we have provided, which is app: nginx,
the pod contains another label
which is for the Pod template it is using.
This label has been provided by Kubernetes itself.
Next up we have Controlled By. As you can see, this Pod
is not directly controlled by a deployment, it is
controlled by a replica set, which is controlled
by deployment. Next, we have container details
including Image name, Image, ID, and Status which is READY.
We also have the normal events of images
being pulled and the container being created, etc.
Let's clear out our terminal
[No Audio]
and describe our deployment.
The deployment description provides a
lot of details, starting with the obvious ones, like
Name, Namespaces, and Labels. We have description
about ReplicaSet, which indicates that this
ReplicaSet is supposed to keep two Pods up and
running. Below that, we have StrategyType.
You might be wondering what kind of strategy?
Well, we are talking about update strategy of the
deployment. One of the most well known use cases
of deployments is without taking it down. Here the
StrategyType is RollingUpdate. If you are
wondering what RollingUpdate strategy means, just
go a couple of steps below. And we have RollingUpdateStrategy details.
It says 25% max unavailable
and 25% max surge. It means that when this
deployment is being updated, only 25% of its total
Pods can be unavailable, and the cluster is only
allowed to deploy 25% of extra Pods while updating
the deployment. Take this example if a deployment
has 4 Pods, and we are trying to update it,
then 25% max unavailability means, the deployment
needs to keep at least 3 Pods up and running
all the time. And 25% max surge means that the
deployment can only create up to 5 Pods at max.
Going below we have details about Pod Template,
which is quite common. But if you go even below
that, we have the name of the replica set which
has been created under this deployment. And if you
look at the events, only one event is directly
linked to the deployment, which is scaling up the
replica set to 2, rest all of the events regarding
Pod and containers are handled by either ReplicaSets
which work under the deployment
or Pods which are governed by ReplicaSets.