This is part 3 of the series on Managing Microservices with Kubernetes. You can read part 1 here    and part 2 here

In part 1, we understood how Kubernetes is used to deploy a Microservice. In that blog, I mentioned that a couple of Kubernetes objects are used to deploy the voting application – Namespaces, Labels and Selectors, Pods, ReplicaSets, Deployment, and Service Objects.   In part 2 we explored some of the Kubernetes objects used in building the microservice application. We also explored scaling a microservices application using the ReplicaSet Controller object.

In this blog, I will show you how to use the Deployment Object to scale the microservice. I will mention the additional features that a deployment has that are not present in a replicaset object. We will explore the additional features in the next couple of blogs.

The Deployment Object

Here is the flow when a  deployment object is created:

Deployment-->ReplicaSet-->Pod-->Container

This means that each time you create a deployment, it will create a ReplicaSet, a Pod, and a Container.

The deployment object provides features not available to Replicaset. It can do everything a ReplicaSet can do and even more such that we don’t have a need to use the Replicaset directly. With Replicaset, you can update your images on the fly with configurations such as,  rolling updates, Blue-Green deployment as well as Canary deployments. In production environments, developers typically just stick to using deployment objects. 

 Creating A Deployment Object

Firstly, let us explore the YAML file provided by the vote-app project. Unlike before where we had to create the YAML files for the Pod and the Replicaset, here we will use the YAML file provided. In working with microservices applications you will typically create  2 files for each microservice: the deployment object YAML  file and the service object YAML file as you can see in this listing. Here, each deployment file has a corresponding service object file.

[email protected]:~/example-voting-app/k8s-specifications$ ls -al
total 44
drwxrwxr-x 2 cloudexperts cloudexperts 4096 Jun  9 12:02 .
drwxrwxr-x 8 cloudexperts cloudexperts 4096 Jun  8 14:52 ..
-rw-rw-r-- 1 cloudexperts cloudexperts  646 Jun  4 17:57 db-deployment.yaml
-rw-rw-r-- 1 cloudexperts cloudexperts  209 Jun  4 17:57 db-service.yaml
-rw-rw-r-- 1 cloudexperts cloudexperts  510 Jun  4 17:57 redis-deployment.yaml
-rw-rw-r-- 1 cloudexperts cloudexperts  221 Jun  4 17:57 redis-service.yaml
-rw-rw-r-- 1 cloudexperts cloudexperts  408 Jun  4 17:57 result-deployment.yaml
-rw-rw-r-- 1 cloudexperts cloudexperts  239 Jun  4 17:57 result-service.yaml
-rw-rw-r-- 1 cloudexperts cloudexperts  394 Jun  4 17:57 vote-deployment.yaml
-rw-rw-r-- 1 cloudexperts cloudexperts  234 Jun  4 18:06 vote-service.yaml
-rw-rw-r-- 1 cloudexperts cloudexperts  335 Jun  4 17:57 worker-deployment.yaml

Here is the file for the Deployment object.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: vote
  name: vote
  namespace: vote
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vote
  template:
    metadata:
      labels:
        app: vote
    spec:
      containers:
      - image: dockersamples/examplevotingapp_vote:before
        name: vote
        ports:
        - containerPort: 80
          name: vote

Comparing this file to the ReplicaSet file (in part 2 here), observe that there is just no difference apart from specifying that the Kind is Deployment rather than   ReplicaSet. Like the RelicaSet, it has  4 sections:

• Metadata section
• A selector that specifies how to identify Pods it can acquire
• A number of replicas
• A pod template specifying the data of new Pods it should create

We can create the Deployment object using kubectl command

Kubectl create -f vote-deployment.yaml

But we had it running from the previous sessions so let’s delete it and then create it again

c[email protected]:~/example-voting-app/k8s-specifications$ kubectl get deploy -n vote
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
db       1/1     1            1           16h
redis    1/1     1            1           16h
result   1/1     1            1           16h
vote     5/5     5            5           16h
worker   1/1     1            1           16h

[email protected]:~/example-voting-app/k8s-specifications$ kubectl delete -f vote-deployment.yaml
deployment.apps "vote" deleted
[email protected]:~/example-voting-app/k8s-specifications$ kubectl create -f vote-deployment.yaml
deployment.apps/vote created
[email protected]:~/example-voting-app/k8s-specifications$ kubectl get deploy -n vote
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
db       1/1     1            1           16h
redis    1/1     1            1           16h
result   1/1     1            1           16h
vote     1/1     1            1           13s
worker   1/1     1            1           16h

Just as we did with the Replicaset, let’s scale it:

[email protected]:~/example-voting-app/k8s-specifications$kubectl scale deploy vote --replicas=5 -n vote
deployment.apps/vote scaled
[email protected]:~/example-voting-app/k8s-specifications$ kubectl get deploy -n vote
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
db       1/1     1            1           16h
redis    1/1     1            1           16h
result   1/1     1            1           16h
vote     5/5     5            5           108s
worker   1/1     1            1           16h
[email protected]:~/example-voting-app/k8s-specifications$ kubectl get rs -n vote
NAME                DESIRED   CURRENT   READY   AGE
db-6789fcc76c       1         1         1       16h
redis-554668f9bf    1         1         1       16h
result-79bf6bc748   1         1         1       16h
vote-7478984bfb     5         5         5       2m30s
worker-dd46d7584    1         1         1       16h
[email protected]:~/example-voting-app/k8s-specifications$ kubectl get pods -n vote
NAME                      READY   STATUS    RESTARTS   AGE
db-6789fcc76c-kkfnk       1/1     Running   0          16h
redis-554668f9bf-7qt2x    1/1     Running   0          16h
result-79bf6bc748-rhrv8   1/1     Running   58         16h
vote-7478984bfb-2vhdz     1/1     Running   0          30s
vote-7478984bfb-9cd48     1/1     Running   0          30s
vote-7478984bfb-bmm2w     1/1     Running   0          30s
vote-7478984bfb-wwcv5     1/1     Running   0          30s
vote-7478984bfb-xps5h     1/1     Running   0          2m1s
worker-dd46d7584-4dzzx    1/1     Running   1          16h

As we scaled the deployment, the ReplicaSet is used to perform the actual scaling so RelicaSet also reflects 5 replicas. When we check the pods, the Pods also reflect 5 Pods running. This shows us that as we scale the deployment, ReplicaSets and the Pods are being controlled by the Deployment object. If you look carefully, you will see a resemblance of the objects:

Name of Deployment object: vote

Name of ReplicaSet: vote-7478984bfb

Name of Pod: vote-7478984bfb-2vhdz

Deployment:

vote     5/5     5            5           108s

ReplicaSet:

vote-7478984bfb     5         5         5       2m30s

Pods:

vote-7478984bfb-2vhdz     1/1     Running   0          30s
vote-7478984bfb-9cd48     1/1     Running   0          30s
vote-7478984bfb-bmm2w     1/1     Running   0          30s
vote-7478984bfb-wwcv5     1/1     Running   0          30s
vote-7478984bfb-xps5h     1/1     Running   0          2m1s

Summary of  Features of the Deployment object:

• It can do everything a replicaset object can do and much more therefore better to use the Deployment object rather than the ReplicaSet object.
• It can perform the rolling update and can rollback to the previous version of the application
• It can do Blue/Green Deployment and Canary Deployment strategies (will be discussed after the service object)
• This is the go-to object for developers when managing their applications

Conclusion

With the Deployment object, we no longer need to use the ReplicaSet object directly. Instead, we can use the Deployment object to control the ReplicaSet and the Pod. The features of the deployment object mentioned in the summary will be addressed in other blogs.   Before we do that we need to understand the service object. This will be addressed in the next blog.