Microservices with Docker & Kubernetes a Complete Guide

Kubernetes is an open-source orchestrator for containers. Basically, it helps automate tasks that help in the deployment, management, and scaling of containerized applications. It is a major tool as containers have now evolved to be a part in every system of a continuous delivery pipeline. In this article we attempt to explain how to deploy and scale up Kubernetes microservices in the cloud.

Why should we use Kubernetes?

It is not an easy job to manage individual containers. It may be easy to manage a small number of containers, even with a small team in place, but managing hundreds of containers can be a real challenge, even for experienced developers.

Kubernetes helps in deployment, scheduling, mass deletion and creation of containers. It is also easy to roll out updates on a large scale and other such jobs that are otherwise very tedious. As an example, imagine that you have to send a Docker image to about two dozen different containers. You can do this by destroying and redesigning these containers. However, another method is to run a short command of just one line that will get Kubernetes to do it for you. This is only a small example that reveals the power of Kubernetes.

Learn about Kubernetes Architecture

When you deploy an application to Kubernetes, it means that you are deploying the application to a Kubernetes cluster. This cluster is a collection of either physical/virtual machines known as nodes that run containerized applications. A cluster has one master node that manages the whole cluster, and many other worker nodes running the actual application instances inside Kubernetes objects referred to as pods.

A pod is the basic building block of a Kubernetes cluster. It is usually a single running process encapsulating a container or, sometimes, many closely coupled containers. Pods are usually replicated when applications have to be scaled up to handle more traffic.

Download Ebook for FREE "How to choose the best microservices vendor and trim the cost"

From the viewpoint of a cluster, a set of replicated pods constitute a single application instance, although this may actually mean dozens of instances of itself. A single pod/group of replicated pods is managed by controllers which are Kubernetes objects. A controller is engaged in handling replication, rollout of updates, self-healing, as well as general management of pods.

A pod/group of replicated pods is abstracted through services (Kubernetes objects). These services define a set of rules using which the pods can be accessed. In a basic setup, a Kubernetes service exposes a node port which is used together with the cluster IP address in order to access the service-encapsulated pods.

What is Docker?

Docker is a platform for developers and sysadmins to develop, deploy, and run applications with containers. It uses OS-level virtualization to deliver software in packages called containers. These containers are isolated from each other and bundle their own software, libraries, and configuration files; they can communicate with each other through well-defined channels.

Docker to the rescue for Microservices

Docker is the perfect solution for running microservices. It provides an isolated and secure environment for quickly deploying and running applications. This makes it ideal for quickly spinning up multiple microservices in parallel, allowing for rapid development and deployment of new features. Additionally, Docker simplifies the management and deployment of microservices, making it easier for developers to maintain and scale their applications. Finally, it provides a consistent environment for running and deploying microservices across multiple platforms and devices, allowing developers to work with the same tools and technologies regardless of their hardware. 

How to Get a Kubernetes Cluster Going

Different services around the globe provide Kubernetes implementations. Some of the very popular services are:

• You can install Minikube on your local machine to use Kubernetes locally. It is an open-source tool. It uses virtualization (VirtualBox or something similar) to set up a local Kubernetes cluster.
• Amazon’s Elastic Kubernetes Service (EKS) helps to manage production-ready Kubernetes.
• Google Kubernetes Engine (GKE) is Google's solution using which you can manage production-ready Kubernetes clusters.
• OpenShift Kubernetes by Red Hat handles Kubernetes clusters for you.
• Azure Kubernetes Service (AKS) provides managed, production-ready Kubernetes clusters.

Before spinning up a Kubernetes cluster, it is important that you have to use a command-line interface tool (kubect1) that helps you manage a Kubernetes cluster easily from the terminal. You will have to install kubect1 according to the specific OS that you are using (Linux, macOS, Windows). A command-line version statement can confirm its presence. This is the primary tool for communicating with the Kubernetes cluster and managing it.

Planning to shift to microservices? Talk to us today!

In this example, you will deploy two microservices, system and inventory. The system microservice returns JVM system properties (of running container) and the pod’s name in the HTTP header, which makes it easy to differentiate replicas from each other. The job of the inventory microservice is to add the properties from system microservice to inventory. This process is used to demonstrate the way in which communication can be established between pods inside one cluster.

In this example, a local single-node Kubernetes cluster is used. The containerization software used Docker. The Docker desktop allows a pre-installed and enabled local Kubernetes environment.  Once the Docker setup for your specific OS is done, ensure that Kubernetes is chosen as the orchestrator.

Kubernetes Microservices-Cluster Deployment

Ensure that you have the project that you will build upon (the starting project) and the finished project which you will build ready for use. The next step is to start your Docker Desktop environment.  Also ensure that Kubernetes is running on the Docker Desktop (bears the default name, localhost). The context should be set to ‘docker-desktop’.

The next command ensures the health of the Kubernetes environment can be checked using the statement, ‘kubect1 get nodes’. This command should elicit a ‘Ready’ status for the master node.

Building and Containerizing Microservices

The first step requires you to build the microservices and containerize them using Docker. In this case, the start directory would have both the system and inventory microservices. They reside in the start/system and start/inventory directories.

Each of the directories also contains a Docker file that is required for building Docker images.  The next step is to navigate to the directory and build the applications. Running the ‘docker build’ commands helps build the container images for the application.

Download and read our eBook, “Porting from Monoliths to Microservices - Is the shift worth it” 

You can label the images by using the –t flag while using the ‘docker build’ command. Using this tag helps to give the image version. A ‘latest’ tag is created in the absence of the –t flag.

At the time of the ‘build’, Docker messages pertaining to what images are downloaded and built are displayed. At the end of the process, the command, "docker images", helps to list all the local Docker images. Make sure that the ‘inventory: 1.0-SNAPSHOT’ and the ‘system: 1.0-SNAPSHOT’ appear on the list. The absence of the snapshots could indicate some error.

Deploying microservices using Kubernetes

As the next step, you can deploy the Docker images using a Kubernetes resource definition. This is a yaml file containing a description of all the services, deployments, or any other resources that you may want to deploy. The yaml file also helps you to delete any and all of the resources from the cluster.

Kubernetes Configuration File Creation

The Kubernetes.yaml file contains four Kubernetes resources that include two deployments and two services. The deployment resource is the one that helps to create and manage pods. A service is a resource that helps to expose a deployment and helps you to make a request to the containers. It is vital to check ‘image, labels, and containerPort’ fields when creating deployments.

Whereas the 'image' is the name and tag of the Docker image to use for this container, 'labels' is a specific method for a Kubernetes service to reference specific deployments (it is a binding between services and deployments).  The 'containerPort' is one that your container exposes to access the application (you can access these services from outside of the cluster).

The next step involves issuing commands that will help you to deploy resources as defined in the kubernetes.yaml file.  Once the apps are deployed, you can also check the pods’ status and get the outputs that report about their health and how well they are running (command: ‘kubectl get pods’).

Read our latest blog, “How Kubernetes Works to Support Microservices Architecture”   

Inspecting individual pods in more detail is possible by issuing the following command: ‘kubectl describe pods’. The ‘kubectl get’ and ‘kubectl describe’ commands can be issued on other Kubernetes resources to inspect them.

Running the ‘curl’ command or visiting specific URLs can help you access your different microservices by replacing the specific host names.

Scaling deployments

In order to use load balancing, the deployments have to be scaled. This is done by replicating the pods of the deployment. This eventually creates more running instances of the applications. Kubernetes enables easy scaling of applications to accommodate traffic surges. You can even descale when the traffic reduces.

A sample command to replicate pods of the system microservice: ‘kubectl scale deployment/system-deployment --replicas=3’, helps you to scale the microservice by 3 pods. The following command ‘kubectl get pods’ helps you confirm that only 2 extra pods have been created.

Redeploying Kubernetes Microservices

When you’re testing/running the application, there may be times to test a change. This involves rebuilding the Docker images and then deleting and re-creating your Kubernetes resources. There will be only one system pod after you redeploy as you will be deleting all of the pods that currently exist.

There are also tests available to test the functionalities of the microservices.  These are basically integration tests.

At the end, if you do not need the microservices that have been deployed, you can use the ‘kubectl delete -f kubernetes.yaml’ to delete all the Kubernetes resources. 

End Thoughts

Do you want to scale up your Kubernetes microservices applications in the cloud? Call us today!