Lab Center – Hands-on Lab

Session 2003

Working with Microservice applications using

Kubernetes, Helm, and IBM Cloud Private

Kevin Postreich, IBM

Yi Tang, IBM

Page 1
Table of Contents
Disclaimer ................................................................................................................................................................ 3
LAB: Working with Microservice applications using Kubernetes, Helm, and IBM Cloud Private ..... 5
1. Introduction ................................................................................................................................... 5
1.1 About the sample application ................................................................................................................. 5
2. Prerequisites ................................................................................................................................. 7
3. What is Already Completed ....................................................................................................... 8
4. Part 1: Deploy and manages microservices using Kubernetes & IBM Cloud Private . 9
4.1 Log in to the workstation VM and get started ...................................................................................... 9
4.2 Setup Kubernetes client .......................................................................................................................... 13
4.3 Push the local Docker images to IBM Cloud Private (ICP) image repository ............................ 17
4.4 Deploy microservices to ICP Kubernetes cluster using Kubernetes CLI (kubectl) ................. 21
4.5 Rollout and rollback versions of the Catalog microservice ........................................................... 28
5. Part 2: Working with Helm to deploy microservices to IBM Cloud Private ................................. 35
5.1 What is Helm .............................................................................................................................................. 35
5.1.1 Helm components and terminology: ............................................................................................. 35
5.2 Setup Kubernetes client (optional) ....................................................................................................... 36
5.3 Review the orders chart files.................................................................................................................. 39
5.3.1 Review the orders chart files .......................................................................................................... 39
5.4 Using HTTP Server as a chart repository ............................................................................................ 43
5.5 Package the orders chart and move to HTTP server chart repository ......................................... 46
5.6 Add the orders chart repository to the IBM Helm Repository ........................................................ 49
5.7 Deploy the orders service using the Helm chart ............................................................................... 52
5.8 Test the orders service ............................................................................................................................ 57
5.9 Delete the Order Helm release ............................................................................................................... 59
We Value Your Feedback! .................................................................................................................................. 62

Page 2
Disclaimer
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at
IBM’s sole discretion. Information regarding potential future products is intended to outline our general product
direction and it should not be relied on in making a purchasing decision.

The information mentioned regarding potential future products is not a commitment, promise, or legal obligation
to deliver any material, code or functionality. Information about potential future products may not be
incorporated into any contract.

The development, release, and timing of any future features or functionality described for our products remains
at our sole discretion I/O configuration, the storage configuration, and the workload processed. Therefore, no
assurance can be given that an individual user will achieve results like those stated here.

Information in these presentations (including information relating to products that have not yet been announced
by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional
technical or typographical errors. IBM shall have no responsibility to update this information. This document is
distributed “as is” without any warranty, either express or implied. In no event, shall IBM be liable for any
damage arising from the use of this information, including but not limited to, loss of data, business
interruption, loss of profit or loss of opportunity. IBM products and services are warranted per the terms and
conditions of the agreements under which they are provided.

IBM products are manufactured from new parts or new and used parts.
In some cases, a product may not be new and may have been previously installed. Regardless, our warranty terms
apply.”

Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal
without notice.

Performance data contained herein was generally obtained in controlled,

isolated environments. Customer examples are presented as illustrations of how those
customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or
other results in other operating environments may vary.

References in this document to IBM products, programs, or services does not imply that IBM intends to
make such products, programs or services available in all countries in which IBM operates or does business.

Workshops, sessions and associated materials may have been prepared by independent session speakers, and do
not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes
only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual
participant or their specific situation.

It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of
competent legal counsel as to the identification and interpretation of any relevant laws and regulatory
requirements that may affect the customer’s business and any actions the customer may need to take to comply
with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure
that the customer follows any law.

Page 3
Information concerning non-IBM products was obtained from the suppliers of those products, their
published announcements or other publicly available sources. IBM has not tested those products about this
publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those
products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party
products to interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied,
including but not limited to, the implied warranties of merchantability and fitness for a purpose.

The provision of the information contained herein is not intended to, and does not, grant any right or
license under any IBM patents, copyrights, trademarks or other intellectual property right.

IBM, the IBM logo, ibm.com and [names of other referenced IBM products and services used in the presentation]
are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other
product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is
available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.

© 2019 International Business Machines Corporation. No part of this document may be reproduced or
transmitted in any form without written permission from IBM.

U.S. Government Users Restricted Rights — use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM.

Page 4
LAB: Working with Microservice applications using Kubernetes,
Helm, and IBM Cloud Private

1. Introduction
In this lab you will work with microservices in IBM Cloud Private (ICP) v3.1.0 environment using
Kubernetes CLI and Helm. The sample microservices used in the lab are written in JavaScript and PHP,
illustrating that the collection of microservices do not have to be developed using a single programming
language.
The lab has two main parts.

Part 1:

Approximately 60 minutes

In Part 1 of the lab, you will work with the Kubernetes CLI (kubectl) to deploy, manage, scales, rollout
and roll back service versions in an uninterrupted manner. You will use Kubernetes commands to view
and introspect your configuration and changes to the environment. The Kubernetes cluster in IM Cloud
Private (ICP) 3.1 environment is used throughout the lab.

Part 2:

Approximately 45 minutes

In part 2 of the lab, you will work with Helm and the Helm repository in ICP to deploy an orders
microservice that adds ordering capability to the catalog service used in part 1 of the lab.

With Helm, we can package up the required microservice resources such as deployment, service,
configmap, secrets, ingress, etc, and deploy everything with a click of a button in IBM Cloud Private.

1.1 About the sample application

The sample application used in the lab is a mock online store application with some basic functionality to
demonstrate microservice concepts with Kubernetes in IBM Cloud Private. The store is a web application
that neatly shows a catalog of items to an online shopper. The shopper is able to pick an item and place
an order.

The application consists of three microservices; a Catalog system, an Ordering system and a User
Interface.

The Orders microservice receives the individual orders and keeps a list of them.

The Catalog service contains a list of items which are available for purchase. It has a rest endpoint
/items which returns the list of items as a JSON object.

Page 5
The UI Service is a PHP application that calls the catalog service to get the list of items available for sale,
and uses the orders service to submit the orders for processing.

Page 6
2. Prerequisites
The following prerequisites must be completed prior to beginning this lab:
 Familiarity with basic Linux commands

The following symbols appear in this document at places where additional guidance is available.

Icon Purpose Explanation

This symbol calls attention to a particular step or command.

Important! For example, it might alert you to type a command carefully
because it is case sensitive.

This symbol indicates information that might not be

Information
necessary to complete a step, but is helpful or good to know.

Trouble- This symbol indicates that you can fix a specific problem by
shooting completing the associated troubleshooting information.

Page 7
3. What is Already Completed

Three Ubuntu Linux VMs have been provided for this lab. The ICP cluster is deployed to ICP3100-
Master VM with ICP master node, work node and proxy node and ICP3100-Mgmt VM with ICP
management node. The Workstation VM is the one you will use to access and work with the ICP cluster.

The login credentials for the Workstation VM are:

User ID: ibmdemo

Password: passw0rd

Note: Use the Password above in the Workstation VM Ubuntu Terminal for sudo in the Lab.

On the Workstation VM, the following lab components have been installed:

 Kubernetes client – Kubectl

 Kubernetes deployment manager - Helm
 Docker images for the three microservices for the Online Store: UI, Catalog and Orders services
 Helm chart for the orders microservice

Page 8
4. Part 1: Deploy and manages microservices using Kubernetes & IBM
Cloud Private

In Part 1 of the lab, you will work with the Kubernetes CLI (kubectl) to deploy, manage, scales, rollout
and roll back service versions in an uninterrupted manner. You will use Kubernetes commands to view
and introspect your configuration and changes to the environment. The Kubernetes cluster in IBM Cloud
Private (ICP) 3.1 environment is used throughout the lab.

4.1 Log in to the workstation VM and get started

__1. Launch the three lab VMs by clicking the start button.

__2. After the VMs are start, click the Workstation VM icon to access it.

Page 9
 The Workstation Ubuntu Desktop will be displayed.

__3. In the Workstation Ubuntu Desktop, launch the Chrome web browser.

__4. In the web browser page, click the IBM Cloud Private bookmark.

Page 10
__5. You see the IBM Cloud Private (ICP) login page, accept the default User ID and Password as:
admin/admin and click Login.

__6. You will see the ICP Welcome page, click the menu icon on the top left corner.

Page 11
__7. Select Dashboard.

The ICP dashboard is shown as followings.

Page 12
 Please Read!

Note: If you see the following error message, ICP is still not started yet. Just wait for a few
minutes and refresh the page and you will get the login page.

4.2 Setup Kubernetes client

You are going to use the Kubernetes client command (kubectl) to deploy the microservice app to ICP
through command line. To do that, we need to configure the kubectl in order to create a secure
connection to the Kubernetes Cluster (IBM Cloud Private Environment).
__1. Setup the Kubernetes client

Page 13
__a. In the ICP dashboard page, click admin on the top right corner and select Configure
client from the dropdown menu.

__b. Click the copy icon to copy all kubectl commands in the box.

Page 14
 __c. Open a terminal window by clicking the terminal window icon.

__d. In the terminal window, right click and select Paste to paste and run the kubectl
commands.

__2. Now the kubectl is configured, you can issue the following kubectl command to see the current
cluster info:

kubectl cluster-info

Page 15
 You can see that several components are created automatically for you in ICP: the master, the
Heapster, the image-manager, the CoreDNS server, the metrics-server and the platform-ui.

__3. List the nodes in the ICP Kubernetes cluster by running the following command. In this lab, there
should be only one node running.

A node represents the VM or Server in which your applications will run in the
Kubernetes cluster. A Kubernetes cluster can have thousands of nodes.

In the lab configuration, the Kubernetes master, proxy, etcd, and worker are all
on the same node (10.0.0.1). This is fine for development, but not for a highly
available production environment.

kubectl get nodes

Noticed that the master node IP address is 10.0.0.1 which you are going to use later in the lab.

Page 16
4.3 Push the local Docker images to IBM Cloud Private (ICP) image repository

In order to deploy the microservices to Kubernetes cluster in ICP, you will push your local microservice
Docker images to an image repository. ICP comes with an image repository which serves as a secured
image repository to store container images.

In this lab, our microservice app consists of three microservices: UI, Catalog, and Orders. These three
local Docker images are already created and are available for use.

__1. List the Docker images using the following command:

docker images | grep -e ui -e catalog -e orders

The command above displays only the Docker images that are relevant to the microservices
used in the lab.

 The ui microservice has a single version, v1

 The orders microservice has a single version: v1
 The catalog microservice has two versions: v1 and v2
During the lab, you will use the Kubernetes CLI (kubectl) to deploy and manage the
microservices.

During the lab, you will explore Kubernetes capabilities such as creating new deployments, and
services, scaling a deployment, perform uninterrupted rollout and rollback of versions of the
catalog. You will view rollout history and details of your microservice deployments.

You will now push the Docker images to the ICP image repository. All activities in the lab will use
the lab namespace, which is the image namespace pre-created in the ICP environment.

Kubernetes Namespaces are a way to divide cluster resources between multiple users or
teams.

You can think of a Namespace as a virtual cluster inside your Kubernetes cluster. You
can have multiple namespaces inside a single Kubernetes cluster, and they are all
logically isolated from each other. They can help you and your teams with organization,
security, and even performance!

Page 17
 Kubernetes creates a default namespace called “default”. If a namespace is not specified
when executing Kubernetes commands, the command will run in the default namespace
for the cluster.

__2. To prepare the Docker images for the ICP image repository, you need to create tags for each of
these four images. To do this, issue the following Docker commands from the command terminal
from which you setup the Kubernetes client :

Docker tags convey useful information about a specific image version/variant. They
are aliases to the ID of your image which often look like this: f1477ec11d12. It’s just a
way of referring to your image.

An image name is made up of slash-separated name components, optionally prefixed

by a registry hostname. The hostname must comply with standard DNS rules, but may
not contain underscores. If a hostname is present, it may optionally be followed by a
port number in the format :8080.

To push an image to a private registry like the private registry in ICP, and not the
central Docker registry, you must tag it with the registry hostname and port (if needed).

In our lab, the ICP private registry host is mycluster.icp. The port is 8500.

docker tag ui:v1 mycluster.icp:8500/lab/ui:v1

docker tag catalog:v1 mycluster.icp:8500/lab/catalog:v1

docker tag catalog:v2 mycluster.icp:8500/lab/catalog:v2

docker tag orders:v1 mycluster.icp:8500/lab/orders:v1

__3. View the new Docker images to see the images have been tagged for ICP private registry

docker images | grep -e ui -e catalog -e orders

Page 18
__4. Now we are ready to push the images to the ICP image repository. Enter commands:

__a. First, login to the Docker private registry in ICP

docker login mycluster.icp:8500

when prompted, enter username / password as: admin / admin

__b. Push the Docker images to the private registry in ICP

docker push mycluster.icp:8500/lab/ui:v1

docker push mycluster.icp:8500/lab/catalog:v1

docker push mycluster.icp:8500/lab/catalog:v2

docker push mycluster.icp:8500/lab/orders:v1

__5. After the images are successfully pushed to ICP image repository, you can go to ICP dashboard
web page to verify they have been loaded

__a. From the ICP dashboard, click menu->Container Images

Page 19
__b. From the “Search” field, type lab/ in order to narrow the search to the images that are in
the lab namespace

You can see all three of the images you just pushed to the image repository. However, you
pushed two versions of the catalog image.

Next, you will view the details of the catalog image to verify both versions are loaded.

__c. Click the lab/catalog image link to view its detail. Ignore the Security scan failed message
because it is not the focus area of this lab. You can see two versions of the catalog
images are listed.

Page 20
 Your microservice images are now stored in the ICP private image repository.

4.4 Deploy microservices to ICP Kubernetes cluster using Kubernetes CLI (kubectl)

When you deploy the microservices to Kubernetes cluster in ICP, you will deploy their Docker
containers. In Kubernetes, that is done by using Kubernetes Deployments. A deployment creates and
updates the instance. The containerized microservice runs inside a Node, which is controlled by the
Kubernetes Master. The Deployment Controller will take care of starting up another instance of the
container if a node goes down.

4.4.1 Deploy the UI microservice

You will now deploy and start with the UI service app – even though it can’t work properly without the
other services. The UI app will attempt to reach the catalog service, and show a message saying

Page 21
“Loading…” until it succeeds. Once the other services are deployed, you will see the UI app working
correctly, without making any changes or restarts to the UI service.

__1. In your terminal window where kubectl is configured, deploy version 1 of the ui microservice to
ICP cluster, using the following command:

kubectl run ui --image=mycluster.icp:8500/lab/ui:v1 --port=80 -n lab

Note: Notice that we specify the -n parameter. This specifies the command is to be executed in
the namespace named lab.

__2. Check that the deployment has been created and is up and running in ICP:

kubectl get deployments -n lab

Notice that the ui deployment has the DESIRED number of pods as 1, and the
number of AVAILALE pods is 1. This indicates the target state of the deployment
was SUCCESSFUL

__3. You can also view your ui deployment through ICP dashboard by clicking menu > Workloads >
Deployments to see the UI app listed under deployments

__a. Enter ui in the Search bar to narrow the search.

__4. When the container is started in the Kubernetes deployment, Kubernetes also creates a construct
called a Pod. For the same app there may be one or more Pods inside a Node. We will look at
scaling later in the lab, and see how to create multiple pods. Right now there is only one pod for
the ui app, which is the one where the ui deployment is running.

__a. Run the following command to view the pods in the lab namespace

Page 22
 kubectl get pods -n lab

Note: You may see several pods listed in the lab namespace, but only one pod for the UI
deployment

Next, the deployment needs to be exposed as Kubernetes Service so it can be available for
service consumers. A Kubernetes Service is an abstraction layer which defines a logical set of
Pods and enables external traffic exposure, load balancing and service discovery for those Pods.
It also provides an interface to the service with a fixed URL and a port.

__5. Create and expose the service for the ui microservice.

kubectl expose deployment ui --type=NodePort -n lab

The NodePort service serves as the external entry point for incoming requests for
your app. The assigned NodePort is publicly exposed in the kube proxy settings of
each worker node in the cluster.

When you expose your app by creating a Kubernetes service of type NodePort, a
NodePort in the range of 30000 - 32767 and an internal cluster IP address is
assigned to the service.

NodePort is for use in development and test environments. However in production

use in ICP, it is recommended to use Ingress and Ingress rules to route traffic to
the services. An external load balance can also be configured, if the cloud
provider supports the underlying load balance infrastructure.

__6. You can see the new service by listing them using the following command:

kubectl get services -n lab | grep ui

Page 23
 Noticed that a TCP port is assigned to the ui service and this is 30941 in the screenshot, but you
might get a different port number, as it is randomly assigned.

__a. Write down the port number in the Cheatsheet which is located on the Desktop. You will
use it later in the lab:

UI TCP Port: _____________________________________

__7. You can also view your ui service through ICP dashboard by clicking menu > Network Access
> Services.

__a. Type ui in the Search field to narrow the search

The ui microservice has a separate URL which can be accessed in the browser. The URL is an
end point on the Master, which translates the exposed URL to the (hidden) real URL for the
service.

In Kubernetes, the URL is composed of the Kubernetes Cluster Node IP address with the service
TCP port: http://<Node IP Address>:<ui service TCP Port #>.

Since we already know our Node IP address and the ui service port number, the ui service URL
should be: http://10.0.0.1:<your ui service TCP port>.

For example: http://10.0.0.1:30941

__8. Launch the UI microservice

__a. From the Services page in ICP, click on the ui service to access its overview page

__b. Scroll down and locate the NodePort property

__c. Click on the NodePort link next to the NodePort property. This will launch the ui service
in the web browser.

Page 24
__d. The ui service will be displayed in a new Web Browser tab.

The ui app shows that it is Loading… which is expected at this point. The app is getting all the
items for sale from the Catalog microservice. We have not deployed the Catalog service yet, so
the ui app continues to retry to get to the catalog service, and once that service is published, it
should show all the items in the catalog.

Page 25
 Kubernetes uses its own DNS server (see the output from kubectl cluster-
info) where the services are registered when you expose the deployments.
In the code, in order to get to a service called servicename and REST end
point called endpoint, you can connect using http://servicename/endpoint

The UI calls the REST service /items on the catalog service using
http://catalog/items

4.4.2 Deploy the Catalog microservice – version 1

In this section you will create the catalog deployment and expose the service. This is done the
same way as for the UI, by creating a deployment for Docker image for the catalog microservice,
and exposing it. By exposing the service, the DNS server is updated, and the UI microservice,
which is using the DNS server to look up the Catalog service, will be able to find it and invoke the
rest call to catalog/items.

__1. In your terminal window, enter the following two commands to create the deployment and service
resources in Kubernetes.

kubectl run catalog --image=mycluster.icp:8500/lab/catalog:v1 --port=80 -n lab

kubectl expose deployment catalog --type=NodePort -n lab

Kubernetes has now created a deployment for the catalog microservice, and exposed it as a
service and updated the DNS server so others can locate it.

__2. Return to the web browser tab that has the UI application running

After approximately 10 to 15 seconds, the UI microservice will yet again have tried to reach the
catalog service, and succeed. You should see this in the browser.

Page 26
__3. If you click on the Buy button for any of the items in the catalog, you will be notified that the order
service is not running. This is because we have not deployed it yet. Click OK to get rid of the
message box.

Note: Later in this lab, you will deploy the orders service using Helm. We have provided the helm
chart for the deployment, but you will learn how to add the helm repository to ICP, and deploy
applications using Helm from ICP.

Page 27
4.5 Rollout and rollback versions of the Catalog microservice

4.5.1 Rollout a new version of the Catalog microservice and view resources that can be used
for introspection and troubleshooting

We have provided a second version of the catalog service, which you will deploy. There may be
a lot of business reasons why microservices change, so just to demonstrate how uninterrupted
rollout works, we have provided a version of the catalog where footballs are no longer offered
for sale.

Kubernetes allows for rolling deployment of apps, and you will deploy the new version of the
catalog microservice.

__1. Return to the terminal window, then update the image to be used by the catalog deployment to
the new version, v2.

kubectl set image deployment/catalog catalog=mycluster.icp:8500/lab/catalog:v2 -n lab --

record=true

 The command specifies catalog:v2. This is the version 2 image that you previously
pushed to the ICP private registry.

 The –record=true flag is used to write the command executed in the resource annotation
kubernetes.io/change-cause. It is useful for future introspection.

__2. Wait a few seconds for the deployment to complete

__3. Then, in your web browser, refresh the UI page to see the new version of the catalog, which no
longer includes footballs.

You should see that the football is no longer there. If you still see the football, wait a few seconds
and reload the page.

Page 28
 Again, no changes were made to the ui microservice. Development, testing, and deployment of
each microservice is independent of each other, but with the requirement that the interface/API is
backwards compatible.

__4. View the catalog deployment using the following command. The deployment should be available.

kubectl get deployments -n lab | grep catalog

__5. View the deployment resource configuration

You can view the actual catalog deployment configuration. This is useful in debugging situations
when you are seeing unexpected results from your deployments. In this case, we can ensure that
version 2 of the catalog is deployed.

__a. Run the following command to display the catalog deployment configuration to the
command terminal as json output. You can alternatively specify “yaml” output.

kubectl get deploy catalog -o=json -n lab

Note: you can scroll through the output to view the configuration

__b. One way to quickly see the version of the image running in the container, is to grep for
image when running the command.

kubectl get deploy catalog -o=json -n lab | grep image

__6. View the rollout status of the catalog deployment

kubectl get rs -n lab

The rollout status will watch the status of the latest rollout. When complete, the rollout status will
show that one deployment is inactive, and another is active for the “catalog” service.

Page 29
__7. View the details of the active rollout status using the following command

kubectl describe rs catalog-<Identifier> -n lab

where your rollout status <Identifier> from your active rollout status resource

Example:

kubectl describe rs catalog-759cbbc69b -n lab

Because we included the --record=true flag when we rolled out the new version of the catalog
service, you will see the new Annotation – Kubernetes.io/change-cause which provides
information on what change triggered the update of the resource. In this case, we deployed v2 of
the catalog.

__8. Look at the rollout history for the catalog deployment, using the following command

kubectl rollout history deployment catalog -n lab

Notice there are two revisions.

[1]The initial v1 deployment

[2] The rollout of v2

Page 30
 Note: Kubernetes allows you to undo a rollout (rollback). You can rollback to the previous
revision, or specify a revision that you want to rollback to. We will undo the rollout in just a few
minutes.

__9. Now look at the details of the deployment

Here you will see the Events of the catalog deployment, showing the old version of the
deployment being scaled to 0, and the new version being scaled up to 1, thereby rolling out the
new version in an uninterrupted manner.

You will see additional details such as the number of replicas, the image that is used, and other
resources such as volumes, mounts, etc that are configured for the catalog deployment.

kubectl describe deployment catalog -n lab

Note: In the screen shot below, I just focused on the events that occurred during the rollout.
Notice that Kubernetes scaled up the new version, before tearing down the old version, in order
to deliver uninterrupted update of the catalog service.

4.5.2 Undo the rollout (Rollback to the previous version) of the catalog service

If for some reason the new version has issues or did not rollout successfully, you can roll back to
the previous version, or to a specified version using the --revision=x flag on the rollout undo
command.

Note: The revision number is from one of the revisions listed from the Kubernetes rollout history
command, as shown below.

kubectl rollout history deployment catalog -n lab

__1. Run the following command to undo the rollout, and revert back to the previous version of the
catalog service (version 1)

Page 31
 kubectl rollout undo deployment catalog -n lab

Note: Alternatively, you can roll back to a specified revision, as mentioned above.

__2. Now you can rerun a few of the commands earlier to see the results of the rollback.

#View the events from the follow command to see how the replicSet scaled down the current
version and reverts back to the old version.

kubectl describe deployment catalog -n lab

__a. Now there should be a revision #3

kubectl rollout history deployment catalog -n lab

__b. Look at the history of revision #3, and see that it is now back to image catalog:v1

kubectl rollout history deployment catalog -n lab --revision=3

__3. Return to the Web Browser where the UI application is running. Then refresh the web browser
page.

Page 32
 The version one of the catalog should be displayed, and the football is back in the catalog.

4.5.3 Scale the Catalog microservice

The catalog microservice may be used by other clients than the browser ui, for instance, mobile apps,
and third party apps. This may create a need to scale that service independent of the other two that are
deployed. Scaling can be done manually or automatically. In this lab we will demonstrate how to scale
the microservice manually.

__1. In the terminal window, list the deployments and look at the number of instances of each.

kubectl get deployments -n lab

__2. To scale the Catalog service manually to 3 replicas, use the following command.

kubectl scale deployment/catalog --replicas=3 -n lab

__3. List the deployments again and look at the number of instances of each. You should now see that
the Catalog microservice has 3 instances and should be able to take more traffic than before.

Page 33
 kubectl get deployments -n lab

As you have seen, using Kubernetes allows you to deploy and scale microservices
independently.

Kubernetes allows for high availability of the microservices in your app through scaling instances
and automatically restarting instance if they fail, and enables new releases to be deployed without
downtime.

Microservices can be developed and deployed independent of each other, without having to
deploy a large monolithic app each time there is a change to a small part of the app.

Congratulations! You have successfully completed Part 1 of the lab, working with Kubernetes CLI
and IBM Cloud Private.

In Part 2 of the lab, you will work with Helm and IBM Cloud Private to easily and quickly deploy all of the
resources for the order microservice.

Using Helm, we can package up the resources such as deployments, services, configmaps, secrets, etc,
and deploy everything with a click of a button in ICP.

Page 34
5. Part 2: Working with Helm to deploy microservices to IBM Cloud Private
In Part 2 of this lab, you will learn how to deploy Microservice applications to Kubernetes cluster in IBM
Cloud private (ICP) using Helm charts. Helm is the package manager for Kubernetes, it helps manage
Kubernetes application deployments and can be used to define, install, and upgrade application in
Kubernetes environment.

This part of the lab continues to use the catalog application that was introduced in Part 1 of the lab. For
this exercise you will deploy the new “orders” microservice to add ordering capabilities to your catalog
application.

5.1 What is Helm

Deploying applications to Kubernetes can be complex. A single application can involve creating multiple
microservices, each with their own interdependent Kubernetes resources such as pods, services,
deployments, replicaSets, configMaps, secrets, ingress, etc; each requiring you to develop a detailed
YAML manifest file.

Helm is the package manager for Kubernetes. It allows describing the application structure through
convenient helm-charts and managing it with simple commands. Helm Charts helps you define, install,
and upgrade even the most complex Kubernetes application onto Kubernetes clusters.

5.1.1 Helm components and terminology:

• Helm – The CLI

– Helm installs charts into Kubernetes, creating a new release for each installation
– To find new charts, search Helm chart repositories
• Tiller – The server-side engine
– Helm templating engine, runs in a pod in a Kubernetes cluster
– Tiller processes the chart to generate the resource manifests, then installs the release into
the cluster
• Chart – The application package
– Templates for a set of resources necessary to run an application
– The chart includes a values file that configures the resources
• Repository – The library
– Storage for Helm charts
– stable – The namespace of the hub for official charts
• Release – The application runtime
– An instance of a chart running in a Kubernetes cluster

Page 35
 This part of the lab assumes you have completed Part 1. If you have not completed part 1
of the lab, you may continue with part 2 to become familiar with deploying applications
using Helm in ICP. However the application will not function if the microservices from Part
1 of the lab are not deployed.

5.2 Setup Kubernetes client (optional)

Note: You are only required to do this section 5.2 – Setup Kubernetes Client if you did
not perform the steps from Part 1 of the lab, or if you have closed the terminal window that
you had previously setup the Kubernetes client

You are going to use the Kubernetes client command kubectl in this section of the lab. Consequently,
you need to configure the kubectl in order to create a secure connection to the Kubernetes Cluster (IBM
Cloud Private Environment).
__1. Setup the Kubernetes client

__a. In the ICP dashboard page, click admin on the top right corner and select Configure
client from the dropdown menu.

Page 36
__b. Click the copy icon to copy all kubectl commands in the box.

__c. Open a terminal window by clicking the terminal window icon.

Page 37
 __d. In the terminal window, right click and select Paste to paste and run the kubectl
commands.

__2. Now the kubectl is configured, you can issue the following kubectl command to see the current
cluster info:

kubectl cluster-info

Page 38
5.3 Review the orders chart files

The orders Helm chart for this lab has already been created for you. However, it is important to
understand the basic structure of files that are created when you create a new helm chart, using the helm
commands.
order-chart/ # The content of this directory is the chart
|- Chart.yaml # Information about the chart
|- values.yaml # The default configuration values for this chart
|- charts/ # Charts that this chart depends on
|- templates/ # This chart's template files
|- NOTES.txt # OPTIONAL: A plain text file containing short usage notes
|- _helpers.tpl # OPTIONAL: The default location for template partials
|- deployment.yaml # Sample template for a deployment resource
|- service.yaml # Sample template for a service resource
|- configmap.yaml # Binds configurations to Kubernetes components at runtime

5.3.1 Review the orders chart files

__1. From the terminal window, change to the order-chart directory, using the following command:

cd /home/ibmdemo/orderchart/order-chart

Page 39
__2. List the files in the charts directory structure

ls -LR

Here, you see the Chart,yaml, README,md, and the values.yaml files at the root of the file
structure.

In the templates folder, you find the deploy.yaml and the configmap.yaml files

Note: Since this chart does not include nay sub-charts, the Charts folder is empty.

__3. Review the Chart.yaml file using the following command

cat Chart.yaml

The Chart.yaml file includes the name and version if the order chart that we have created

__4. Review the values.yaml file using the following command

cat values.yaml

The values.yaml file include parameters that will be passed in when you deploy the chart. In this
case, we simply created a myvalue parameter, with the default value of “order chart”. The default
value can be overridden when the user deploys the chart.

Often times, charts have many parameters which allows for high degree of flexibility in the
deployment of the application by different users.

Page 40
__5. Review the configmap.yaml file using the following commands

cd templates

cat configmap.yaml

ConfigMaps bind configuration files, command-line arguments, environment variables, port

numbers, and other configuration artifacts to your Pods' containers and system components at
runtime.

ConfigMaps allow you to separate your configurations from your Pods and components, which
helps keep your workloads portable, makes their configurations easier to change and manage,
and prevents hardcoding configuration data to Pod specifications.

In this case, we are binding the myvalue property from the values.yaml file to the application at
runtime.

__6. Review the deploy.yaml file using the following command

The depoloy.yaml file for the orders service includes configuration for the following Kubernetes
resources:
 Deployment
 Service
 Ingress

Use the following three commands to view the specific range of lines in the deploy.yaml
pertaining to each of the resource configurations.

Page 41
__a. Display the deployment resource configuration
cat -n deploy.yaml | sed -ne 1,19p

The deployment name is orders. One replica is specified, so Kubernetes will always
enforce one pod to be running. If it fails, Kubernetes will restart it.

The image used for this version of the service is mycluster.icp:8500/lab/orders:v1 and will
be pulled from the ICP private registry when the application is deployed.

__b. Display the service resource configuration

cat -n deploy.yaml | sed -ne 20,34p

The service name is orders. Notice that the service type is NodePort. In this case, a
random port number will be assigned by Kubernetes. Using NodePort, the service is
exposed to external traffic. The service fronts he orders app, as defined in the selector.

Page 42
 __c. Display the ingress resource configuration
cat -n deploy.yaml | sed -ne 35,49p

The ingress provides the routing rules for accessing the service. Ingress is the preferred
way to access and load balance services in IBM Cloud Private. In this service, the ingress
rule applied is to route based on the path “/orders”.

5.4 Using HTTP Server as a chart repository

A Helm chart repository is a place where packaged Helm charts can be stored and shared. It is a web
server that houses an index.yaml file and packaged Helm chart artifacts. It allows you to share your
charts with your team, your enterprise or public. Once you have created your Helm chart, you can upload
it to the repository so you and others can access it from the web.

When you setup your Helm chart repository, its security, user authentication and authorization should be
take into consideration. In this lab, we will use IBM HTTP Server as our Helm chart repository. The IBM
HTTP server is deployed in ICP environment as a container and is configured to serve as Helm chart
repository

__1. To verify the deployment of the IBM HTTP Server in ICP, go back to ICP page, click the
menu icon and select Workloads -> Deployment

Note: If asked to login, use the following credentials:

Username: admin
Password: admin

Page 43
__2. From the Deployments list, type http-server in the Search box. Then click the http-server link

__3. In the http-server page, scroll down to the Pods section, verify its status is READY (1/1)
then go to step 5.

__4. If the pod is in not ready status (0/1), do the follows:

__a. Click the Action icon and select Remove.

Page 44
 __b. Click Remove Pod.

The pod will get deleted and regenerated. Once it is ready, the HTTP Server should be up and
running.
__5. In the http-server page, click on the Launch link, which will open the HTTP Server in a new
web browser tab.

The HTTP Server URL should be: http://10.0.0.1:<HTTP Server TCP NodePort>/

Example: http://10.0.0.1:30941/

Page 45
 The Helm Chart repository URL is the http://<HTTP Server URL>/helmcharts

Example:

http://10.0.0.1:30941/helmcharts

Note: You will not be able to access this HTTP Server URL until later in the lab, when you publish
the helm charts to the HTTP Server. This URL is for your reference and will be used later in the
lab.

Write down the Helm chart repository URL, in the Cheatsheet located on the Desktop

Helm Chart Repository url: ________________________________

__6. Later in the lab, you will need to copy the helm charts to the HTTP Server. In order to that, you
need to know the HTTP Server container that the files will be copied into.
__a. Return to the terminal window where the kubectl is configured and issue the command
to get the pod name:
kubectl get pods -n lab | grep http-server

Write down the HTTP Server pod name, in the Cheatsheet located on the Desktop

HTTP Server Pod Name: ________________________________

5.5 Package the orders chart and move to HTTP server chart repository

As you have explored, the orders chart files have already been created for you. You only need to use the
helm commands (CLI) to package the helm chart and generate the helm chart repository index yaml file.

__1. Package the orders helm chart

__a. From the terminal window, navigate back to the /home/ibmdemo/mycharts directory and
create the order-chart package

cd /home/ibmdemo/orderchart

helm package order-chart

This will create a chart package called order-chart-0.1.0.tgz. for the order-chart version 0.1.0
which is defined in its Chart.yaml file.

Page 46
 __b. Verify the order-chart-0.1.0.tgz file was created in the orderchart directory

ls -l

__2. Move the order-chart-0.1.0.tgz package to the docs directory

Note: We will stage the charts files in the docs directory. When complete, we will copy the docs
directory to the HTTP Server, where the helm chart repository located.

cd /home/ibmdemo/orderchart/

mv order-chart-0.1.0.tgz docs

__3. Verify the order-chart-0.1.0.tgz file is now copied to the docs directory

ls -l docs

__4. Generate a Helm chart repository index file with the chart package info

A chart repository consists of packaged charts and a special file called index.yaml which
contains an index of all of the charts in the repository. Use the helm repo index command to
generate the index.yaml file. It will contain the repository index for the orders chart.

cd /home/ibmdemo/orderchart/

helm repo index docs --url <Helm Chart Repository url>

where <Helm Chart Repository url> you wrote down in the Cheatsheet.

Example:

helm repo index docs --url http://10.0.0.1:30941/helmcharts

The index.yaml file is created in the orderchart/docs directory.

Page 47
__5. Verify and review the index.yaml file that was generated for the orders chart

ls -l docs

cat docs/index.yaml

Notice the index.yaml file contains the URL to the chart, which is the URL where the chart will be
located in the HTTP server. It also contains the versions of the charts. The index.yaml file may
contain many charts, and multiple versions of the charts.

__6. Now you will upload the Helm chart contents to the IBM HTTP server by executing the following
commands:
cd /home/ibmdemo/orderchart

kubectl cp docs/. lab/<HTTP Server Pod

Name>:/opt/IBM/HTTPServer/helmcharts/.

Where <HTTP Server Pod Name> is the http server pod you documented in the Cheatsheet.

Note: You can obtain the http-server pod name by using the following
command:
Kubectl get pods -n lab | grep http-server

Your order chart is now ready to be used.

Page 48
__7. Validate that the helm charts index.yaml is available from the http server

Note: The URL to the helmchart repository in the HTTP Server should now be available.

__a. From the web browser, enter the URL to your <Helm Chart Repository URL> that you
documented in the Cheatsheet, and append /index.yaml to the URL., as illustrated below.

<Helm Chart Repository URL>/index.yaml

Example:

http://10.0.0.1:30941/helmcharts/index.yaml

If you were not able to see the index.yaml from the web browser, contact the instructor.
Your helm chart did not get deployed properly.

5.6 Add the orders chart repository to the IBM Helm Repository

In this section, you will add your custom helm chart repository to the set of repositories in IBM Cloud
Private. This will provide users the ability to see and deploy your chart from the ICP catalog.

ICP allows the administrator to configure access controls for helm charts in the catalog.
It is common for admins to limit the helm repositories and helm charts that are
accessible in the various namespaces and teams defined in IBM Cloud Private.
As the administrator of the cluster in this lab, you have access to all resources.

Page 49
__1. Return to your ICP console in the web browser

If asked to login, use the following credentials:

Username: admin
password: admin

__2. Click the menu icon on the top left corner and select Manage -> Helm Repositories

Note: The IBM Cloud Private environment may have several helm chart repositories already
loaded. That is expected. Adding your custom repository will result in being added to the list of
available chart repositories.

__3. Click Add repository button

__4. Enter your repository information into the Add repository dialog
__a. Enter a name for your repository. You can name it mycharts
__b. Enter your HTTP Server Helm chart repository URL that you recorded earlier in the URL
field.
__c. Then click Add

Page 50
__5. Synch the repositories
__a. Click the Synch repositories button

__b. In the confirmation dialog, click the OK to confirm you want to synch the repositories

Your repository will show in the repository list.

Page 51
 If you get an error when trying to add the repository, it means that something is wrong
with your chart or something missing in the HTTP Server.
Please contact the instructor if you get an error adding the repository

5.7 Deploy the orders service using the Helm chart

Now that the order chart is stored in the helm repository, you can very easily deploy the orders
microservice application from the IBM Cloud Private catalog, which leverages the helm chart you just
provisioned.

__1. Locate the orders microservice in the ICP catalog

__a. Return to the ICP dashboard
__b. Click on the Catalog link, located at the top of the page

__c. From the Catalog page, use the search box to search for the order-chart application

Your order-chart application will be shown in the list.

Page 52
__2. Deploy the order-chart application using your helm chart (From the ICP UI)
__a. Click on the order-chart

__b. Review the order-chart overview page.

The information on this page comes directly from the helm chart. Notice that the chart
version is V 0.1.0, which was defined in the Chart.yaml. The documentation comes from
the README.md that we packaged in the order-chart.

Page 53
__c. Click the button, located at the bottom of the page.

__d. From the Configuration page, Enter the required values for the deployment

Helm Release Name: orders

Target Namespace: lab (Select lab from the drop-down menu)

__e. Click on the link to view the custom parameters.

Note: These properties, and their default values come from the values.yaml file that we
packaged in the helm chart.

Page 54
__f. You do not need to modify the value of the myvalue property. But you may if you like.

__g. Click the button located on the bottom right portion of the page.

This will install the orders application, and create all of the Kubernetes resources defined
in the deploy.yaml file that we provided in the helm chart. (Deployment, Service, Ingress)

__h. After a few seconds, your helm release will be successfully deployed

__i. Close the deployment confirmation dialog, once the deployment is successful

Page 55
__3. View the Kubernetes resources that were deployed in the helm release
__a. Navigate to Workloads > Helm releases page and search for orders

The orders release should be in the Deployed status, and Up To Date with version 0.1.0

__b. Click on the orders release to view the details of the release deployment

__c. Scroll through the details page, and see the Kubernetes resources that were created
during the Helm release deployment

Page 56
 Now you have completed your first application deployment with Helm charts and successfully
deployed the orders microservice to IBM Cloud Private.

As you can see, using Helm to package up complex applications make it very easy for your users
to deploy and consume your applications and microservices.
You can create Helm charts that contain sub-charts, where several microservices which from the
application are deployed from a single Helm chart.

5.8 Test the orders service

It is time to test the new orders microservice from the catalog application.

__1. If you already have the catalog application running in a browser, you can simply click on the
button for any of the catalog items.

Page 57
Now that the orders service is deployed, you should get an order confirmation.

TIP: If you have previously closed the catalog application from the web
browser, and do not recall the ULR, please follow these high level steps, or
review the earlier section of the lab, and see how we obtained the URL to the
catalog application.

 From ICP, locate the ui application under Workload > Deployments

 Click on the Launch button next to the ui deployment. This will launch
the application in the web browser.

Page 58
5.9 Delete the Order Helm release

Helm provides easy management of the helm releases, such as:

 Deploy a version of the application
 Upgrade to a new version of the application
 Rollback to previous versions of the application
 Delete the application

We only have provisioned one version of the orders service. And as you saw, it created
many Kubernetes resources that were required for the service.
Now, let’s delete the helm release. Doing so, will automatically remove all of the related
Kubernetes resources such as the deployment, service, configmap, ingress, etc

__1. Delete the orders helm release

__a. Return to the ICP Dashboard

__b. Click the menu icon on the top left corner and select Workloads > Helm Releases

__c. Use the search box and search for order

Page 59
__d. Click on next from the orders Helm Release. Then select the Delete option

__e. Click the button Confirm that you want to Remove the “Orders” Helm
Release

__f. After a few seconds, the “orders” helm release and all of the associated Kubernetes
resources are removed

Page 60
__2. Optional – You can use the kubectl CLI to verify the resources have been removes, using the
following commands:

kubectl get deployments -n lab | grep orders

kubectl get services -n lab | grep orders

kubectl get pods -n lab | grep orders

kubectl get ingress -n lab | grep orders

You should not see any resources listed for the previous commands

========= Congratulations! You have completed the lab ==========

Page 61
 We Value Your Feedback!

 Don’t forget to submit your Think 2019 session and speaker feedback! Your feedback
is very important to us – we use it to continually improve the conference.
 Access the Think 2019 agenda tool to quickly submit your surveys from your
smartphone, laptop or conference kiosk.
63