[music]
-Hello, and welcome to this lecture.
My name is Mumshad Mannambeth.
In this lecture, we will discuss about Kubernetes deployments.
For a minute, let us forget about pods and replica sets
and other Kubernetes concepts
and talk about how you might want to deploy your application
in a production environment.
Say, for example, you have a web server that needs to be deployed
in a production environment,
you need not one but many such instances
of the web server running for obvious reasons.
Secondly, whenever newer versions of application builds become
available on the Docker registry,
you would like to upgrade your Docker instances seamlessly.
However, when you upgrade your instances,
you do not want to upgrade all of them at once as we just did.
This may impact users accessing our applications.
So you might want to upgrade them one after the other.
That kind of upgrade is known as rolling updates.
Suppose one of the upgrades you performed resulted
in an unexpected error
and you're asked to undo the recent change.
You would like to be able to roll back the changes
that were recently carried out.
Finally, say, for example, you would like to make
multiple changes to your environment such as upgrading
the underlying web server versions,
as well as scaling your environment and also modifying
the resource allocations, et cetera,
you do not want to apply each change immediately
after the command is run.
Instead, you would like to apply a pause to your environment,
make the changes, and then resume, so that all the changes
are rolled out together.
All of these capabilities are available
with the Kubernetes deployments.
So far in this course, we discussed about pods,
which deploy single instances of our application
such as the web application in this case.
Each container is encapsulated in pods.
Multiple sites pods are deployed using replication controllers
or replica sets.
Then comes deployment, which is a Kubernetes object
that comes higher in the hierarchy.
The deployment provides us with the capability
to upgrade the underlying instances seamlessly
using rolling updates,
undo changes, and pause and resume changes as required.
How do we create a deployment?
As with the previous components, we first create
a deployment definition file.
The contents of the deployment definition file are exactly similar
to the replica set definition file, except for the kind
which is now going to be deployment.
If we walk through the contents of the file, it has an API version
which is apps/v1,
metadata which has name and labels, and a spec that has template,
replicas, and selector.
The template has a pod definition inside it.
Once the file is ready, run the kubectl create command
and specify the deployment definition file.
Then run the kubectl get deployments command
to see the newly created deployment.
The deployment automatically creates a replica set.
So if you run the kubectl get replica set command,
you will be able to see a new replica set in the name of the deployment.
The replica sets ultimately create pods.
If you run the kubectl get pods command,
you will be able to see the pods with the name
of the deployment and the replica set.
So far, there hasn't been much of a difference between replica set
and deployments, except for the fact that deployment
created a new Kubernetes object called deployments.
We will see how to take advantage of the deployment using
the use cases we discussed in the previous slide
in the upcoming lectures.
One more note before we end this lecture.
To see all the created objects at once, run the kubectl
get all command.
In this case, we can see that the deployment was created,
and then we have the replica set,
followed by three pods that we created
as part of the deployment.
That's it for this lecture.