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 on IBM Cloud, you need Administrator access to IBM Cloud Kubernetes Service. To verify your Administrator access, log in to the IBM Cloud Dashboard. Then, navigate to Manage > Access (IAM) > Users > [Your Username] > Access > Access Policies. Alternatively, if you are part of an access group, you also can check Manage > Access (IAM) > Access groups > [Your Access Group] > Access. Using these steps, you can confirm that Administrator is listed as a policy for all resources in the account or for the Kubernetes service.

Once you confirm that you have appropriate permissions, use the following commands to provision a cluster.

Retrieve the list of available Kubernetes zones for deploying the cluster within the IBM Cloud classic infrastructure

Use the following command to retrieve a list of the available flavors of Kubernetes worker nodes for a zone. Replace the [available_zone] value with a zone selected from the list you generated with previous command.

Look for the following output:

Use the following command to create a Kubernetes cluster. Replacing the [selected_flavor] value with a flavor selected from the output of the previous command and the [available_zone] with the previously used zone.

Look for the following output:

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 --platform flag in the docker build command specifies the target platform for the build output. Because IBM Cloud Kubernetes service supports both x86_64 and s390x architectures, the target platform is linux/amd64. Also, the -t flag in the 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.

To create, assign, and remove namespaces, you must have the Manager role in the Container Registry service at the account level. For more information, see User permissions for working with namespaces.

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.