Deploying microservices to Kubernetes

Kubernetes is an open source container orchestrator that automates many tasks involved in deploying, managing, and scaling containerized applications.

Over the years, Kubernetes has become a major tool in containerized environments as containers are being further leveraged for all steps of a continuous delivery pipeline.

You will learn how to deploy two microservices in Open Liberty containers to a local Kubernetes cluster. You will then manage your deployed microservices using the kubectl command line interface for Kubernetes. The kubectl CLI is your primary tool for communicating with and managing your Kubernetes cluster.

The two microservices you will deploy are called system and inventory. The system microservice returns the JVM system properties of the running container and it returns the pod’s name in the HTTP header making replicas easy to distinguish from each other. The inventory microservice adds the properties from the system microservice to the inventory. This demonstrates how communication can be established between pods inside a cluster.

You will use a local single-node Kubernetes cluster.

The first step of deploying to Kubernetes is to build your microservices and containerize them with Docker.

The starting Java project, which you can find in the start directory, is a multi-module Maven project that’s made up of the system and inventory microservices. Each microservice resides in its own directory, start/system and start/inventory. Each of these directories also contains a Dockerfile, which is necessary for building Docker images. If you’re unfamiliar with Dockerfiles, check out the Containerizing Microservices guide, which covers Dockerfiles in depth.

Navigate to the start directory and build the applications by running the following commands:

Run the following command to download or update to the latest Open Liberty Docker image:

Next, run the docker build commands to build container images for your application:

The -t flag in the docker build command allows the Docker image to be labeled (tagged) in the name[:tag] format. The tag for an image describes the specific image version. If the optional [:tag] tag is not specified, the latest tag is created by default.

During the build, you’ll see various Docker messages describing what images are being downloaded and built. When the build finishes, run the following command to list all local Docker images:

Verify that the system:1.0-SNAPSHOT and inventory:1.0-SNAPSHOT images are listed among them, for example:

If you don’t see the system:1.0-SNAPSHOT and inventory:1.0-SNAPSHOT images, then check the Maven build log for any potential errors. In addition, if you are using Minikube, make sure your Docker CLI is configured to use Minikube’s Docker daemon and not your host’s as described in the previous section.

Now that your Docker images are built, deploy them using a Kubernetes resource definition.

A Kubernetes resource definition is a yaml file that contains a description of all your deployments, services, or any other resources that you want to deploy. All resources can also be deleted from the cluster by using the same yaml file that you used to deploy them.

kubernetes.yaml

This file defines four Kubernetes resources. It defines two deployments and two services. A Kubernetes deployment is a resource responsible for controlling the creation and management of pods. A service exposes your deployment so that you can make requests to your containers. Three key items to look at when creating the deployments are the labels, image, and containerPort fields. The labels is a way for a Kubernetes service to reference specific deployments. The image is the name and tag of the Docker image that you want to use for this container. Finally, the containerPort is the port that your container exposes for purposes of accessing your application. For the services, the key point to understand is that they expose your deployments. The binding between deployments and services is specified by the use of labels — in this case the app label. You will also notice the service has a type of NodePort. This means you can access these services from outside of your cluster via a specific port. In this case, the ports will be 31000 and 32000, but it can also be randomized if the nodePort field is not used.

Run the following commands to deploy the resources as defined in kubernetes.yaml:

When the apps are deployed, run the following command to check the status of your pods:

You’ll see an output similar to the following if all the pods are healthy and running:

You can also inspect individual pods in more detail by running the following command:

You can also issue the kubectl get and kubectl describe commands on other Kubernetes resources, so feel free to inspect all other resources.

Next you will make requests to your services.

Then curl or visit the following URLs to access your microservices, substituting the appropriate host name:

The first URL returns system properties and the name of the pod in an HTTP header called X-Pod-Name. To view the header, you may use the -I option in the curl when making a request to http://[hostname]:31000/system/properties. The second URL adds properties from system-service to the inventory Kubernetes Service. Visiting http://[hostname]:32000/inventory/systems/[kube-service] in general adds to the inventory depending on whether kube-service is a valid Kubernetes Service that can be accessed.

To use load balancing, you need to scale your deployments. When you scale a deployment, you replicate its pods, creating more running instances of your applications. Scaling is one of the primary advantages of Kubernetes because replicating your application allows it to accommodate more traffic, and then descale your deployments to free up resources when the traffic decreases.

As an example, scale the system deployment to three pods by running the following command:

Use the following command to verify that two new pods have been created.

Wait for your two new pods to be in the ready state, then curl -I or visit the http://[hostname]:31000/system/properties URL. You’ll notice that the X-Pod-Name header will have a different value when you call it multiple times. This is because there are now three pods running all serving the system application. Similarly, to descale your deployments you can use the same scale command with fewer replicas.

When you’re building your application, you may find that you want to quickly test a change. To do that, you can rebuild your Docker images then delete and re-create your Kubernetes resources. Note that there will only be one system pod after you redeploy since you’re deleting all of the existing pods.

This is not how you would want to update your applications when running in production, but in a development environment this is fine. If you want to deploy an updated image to a production cluster, you can update the container in your deployment with a new image. Then, Kubernetes will automate the creation of a new container and decommissioning of the old one once the new container is ready.

pom.xml

A few tests are included for you to test the basic functionality of the microservices. If a test failure occurs, then you might have introduced a bug into the code. To run the tests, wait for all pods to be in the ready state before proceeding further. The default properties defined in the pom.xml are:

Navigate back to the start directory.

If the tests pass, you’ll see an output similar to the following for each service respectively:

When you no longer need your deployed microservices, you can delete all Kubernetes resources by running the kubectl delete command:

You have just deployed two microservices running in Open Liberty to Kubernetes. You then scaled a microservice and ran integration tests against miroservices that are running in a Kubernetes cluster.

Deploying microservices to Kubernetes by Open Liberty is licensed under CC BY-ND 4.0