• AWS Cloud
  • DevOps
  • Kubernetes
  • Microservices
  • Terraform
  • Ansible
  • Blog
    Login

    Have a question?  1-800-690-2675  [email protected]

    CloudNative and MicroservicesCloudNative and Microservices
    • AWS Cloud
    • DevOps
    • Kubernetes
    • Microservices
    • Terraform
    • Ansible
    • Blog

      Public Cloud

      • Home
      • Blog
      • Public Cloud
      • Scaling Microservices with the Kubernetes Deployment Object

      Scaling Microservices with the Kubernetes Deployment Object

      • Posted by Damian Igbe
      • Categories Public Cloud
      • Date July 20, 2020

      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.

      • Share:
      author avatar
      Damian Igbe
      Damian holds a PhD in Computer Science and has decades of experience in Information Technology and Cloud services. Damian holds a couple of certifications including AWS Certified Solutions Architect- Associate, AWS Certified Developer-Associate and AWS Certified SysOp-Associate. He is the founder and CTO of Cloud Technology Experts. When not writing or teaching or consulting, Damian likes running and spending time with the family.

      Previous post

      Scaling a Microservice Application in Kubernetes
      July 20, 2020

      Next post

      Accessing Microservices with the Kubernetes Service Object
      July 22, 2020

      You may also like

      kubernetes-networking
      Understanding Networking of Microservices Applications
      29 August, 2020
      ci-cd-blog-5
      CI/CD of Microservices in Kubernetes
      9 August, 2020
      service-object-kubernetes
      Accessing Microservices with the Kubernetes Service Object
      22 July, 2020

      Leave A Reply Cancel reply

      Your email address will not be published. Required fields are marked *

      Search

      Categories

      • Cloud Automation
      • Cloud Security
      • Cloud-native
      • General
      • HA & Autoscaling
      • Kubernetes
      • Kubernetes Volumes
      • Monitoring
      • Public Cloud

      Latest Courses

      LPI Linux Essentials

      Free

      AWS Certified Cloud Practitioner

      $300.00 $275.00

      Kubernetes Certified Administrator

      $275.00

      Training, Consulting & Research
      © 2016-2020 CTE, All Rights Reserved.
      14330 Midway Rd, Suite 211, Farmers Branch, TX 75244

      No apps configured. Please contact your administrator.

      Login with your site account

      No apps configured. Please contact your administrator.

      Lost your password?