Deploying microservices to IBM Cloud Kubernetes Service

Log in to IBM Cloud by using the ibmcloud command line. When you are prompted to select a region, for example, choose us-south. This allows you to create a free cluster, which is limited to specific regions. Note that if you are using a federated user ID, you will have to use the --sso flag to get a one-time code for single sign-on.

To create a Kubernetes cluster, you need Administrator access to IBM Cloud Kubernetes Service. To confirm that you have Administrator access, navigate to the IBM Cloud Dashboard. Then, navigate to Manage > Access (IAM) > Users > [Your Username] > Access Policies and confirm that Administrator is listed as a policy for all resources in the account or for the Kubernetes service.

Once you have confirmed that you have appropriate permissions, use the following command to provision a cluster.

This command provisions a free cluster that expires in a month if you do not delete it.

Check the current status of your cluster.

Wait until your cluster is in the normal state before proceeding. It will start off in the deploying state.

Next, it will transition to the pending state.

Finally, it will transition to the normal state. It may take a while for the IBM Cloud Kubernetes Service to prepare your cluster.

Once your cluster is ready, connect kubectl to the cluster.

Verify that you’re connected to the cluster by checking the cluster’s nodes.

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

The starting Java project, which you can find in the start directory, is a multi-module Maven project. It’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.

To build these microservices, navigate to the start directory and run the following command:

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.

Pushing the images to a registry enables the cluster to create pods by using your container images. It’s a private repository so only users with access to your IBM Cloud account will have access to these images.

The registry you will use is called IBM Cloud Container Registry. Use the container registry plug-in to create a namespace for your container images. The namespace must be unique within IBM Cloud for the region you selected, so choose something relevant that you’ll remember for the duration of the guide.

Use the plug-in again to log in to the container registry and find out your registry name, for example, us.icr.io.

Next, tag your container images with the relevant data about your registry. Remember to replace us.icr.io to your registry and [your-namespace] with the namespace you created earlier in the guide.

Finally, push your images to the registry. Remember to replace us.icr.io to your registry and [your-namespace] with the namespace you created earlier in the guide.

Now that your container 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. For this guide, the kubernetes.yaml resource definition file is provided for you. If you are interested in learning more about the Kubernetes resource definition, check out the Deploying microservices to Kubernetes guide.

kubernetes.yaml

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

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

If all the pods are healthy and running, you see an output similar to the following:

The service used to expose your deployments has a type of NodePort service that enables you to access these services from outside of your cluster through a specific port. In this case, nodePort is not specified and the ports are randomized so you must obtain the ports before you make requests to the services. You must also obtain the public IP address of your cluster. Other ways to expose your services are available, such as by using a LoadBalancer service type or an Ingress resource. In production, you typically use an Ingress resource.

First, find the public IP address of your cluster.

Take note of the Public IP in the command’s output. You will substitute this value as the hostname into commands later in this guide.

Get the node port of the system microservice.

Get the node port of the inventory microservice.

Take note of the IP address and ports. They are required to make the HTTP requests.

To make a request to the system and inventory microservices, curl or visit the following URLs to access your microservices, substituting the appropriate hostname and node ports:

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 can use the -I option in the curl when making a request to the http://[hostname]:[system-node-port]/system/properties URL. The second URL adds properties from system-service to the inventory.