Deploying new Releases
Learn Kubernetes deployment definition and create a deployment.
We'll cover the following
Just as we are not supposed to create Pods directly but using other controllers like ReplicaSet, we are not supposed to create ReplicaSets either. Kubernetes Deployments will create them for us. If you’re wondering why is this so? You’ll have to wait a little while longer to find out.
First, we’ll create a few Deployments and, once we are familiar with the process and the outcomes, it’ll become obvious why they are better at managing ReplicaSets than we are.
Looking into the definition#
Let’s take a look at a Deployment specification for the database ReplicaSet we’ve been using thus far.
If you compare this Deployment with the ReplicaSet we created in the previous chapter, you’ll probably have a hard time finding a difference. Apart from the kind
field, they are the same.
Since, in this case, both the Deployment and the ReplicaSet are the same, you might be wondering what the advantage of using one over the other is.
ℹ️ We will regularly add
--record
to thekubectl create
commands. This allows us to track each change to our resources such as a Deployments.
Creating the deployment#
Let’s create the Deployment and explore what it offers.
The output of the latter command is as follows.
Describing the Deployment#
The Deployment was created. However, get
does not provide us much info, so let’s describe
it.
The output, limited to the last few lines, is as follows.
From the Events
section, we can observe that the Deployment created a ReplicaSet. Or, to be more precise, that it scaled it. That is interesting.
It shows that Deployments control ReplicaSets. The Deployment created the ReplicaSet which, in turn, created Pods.
Let’s confirm that by retrieving the list of all the objects.
The output is as follows.
All three objects were created, and you might be wondering why we created the Deployment at all. You might think that we’d have the same result if we created a ReplicaSet directly. You’d be right.
So far, from the functional point of view, there is no difference between a ReplicaSet created directly or using a Deployment.
The real advantage of Deployments becomes evident if we try to change some of its aspects. For example, we might choose to upgrade MongoDB to version 3.4.
The following figure summarizes the cascading effect of deployments resulting in the creation of pods, containers, and replicaSets.
Try it yourself#
The list of all the commands used in this lesson is given below.
You can practice the commands in the following code playground by pressing the Run button and waiting for the cluster to set up.
/
- go-demo-2-db.yml