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.
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.
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.
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.
Download Ebook for FREE "How to choose the best microservices vendor and trim the cost"
Download and read our eBook titled, “Porting from Monoliths to Microservices - Is the shift worth it” for a detailed account on the merits of shifting to microservices architecture.
Different services around the globe provide Kubernetes implementations. Some of the very popular services are:
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.
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.
Planning to shift to microservices? Talk to us today!
Read our latest blog, “How Kubernetes Works to Support Microservices Architecture” to understand the synergy between Kubernetes and Microservices.
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.
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.
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.
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.
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’).
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.
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.
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.
Do you want to scale up your Kubernetes microservices applications in the cloud? Call us today!
A majority of the big corporations in the world are going the microservices way. Microservices are small independent but interconnected services that make up an application. This is unlike the earlier approach, when companies functioned with a single larg
Monolith means ‘composed in just one single piece’. A monolith application with reference to software is today a single-tiered application package that has all the different components combined into one behemoth.
We collaborate with visionary leaders on projects that focus on quality and require the expertise of a highly-skilled and experienced team.