az login aroadmin@azure.opentlc.com / password

az version (show Azure version)

az version -o table (show Azure version in table format)

az aro list [arguments] (list ARO clusters)

az aro list -o table

az vm list (list all VMs in the Azure account)

az vm list -o table (list all VMs in a more human friendly format)

az vm list –query “[].{resource:resourceGroup, name:name}” -o table

az aro create [arguments] –help (create a cluster)

az aro delete [arguments] –help (delete a cluster)

az aro list-credentials [arguments] (list credentials of a cluster)

az aro show [arguments] (get details of a cluster)

az aro show -n

az aro update [arguments] (update a cluster)

az aro wait [arguments] (wait for a cluster to reach a desired state)

For a dynamic language like Ruby, the build-time and run-time environments are typically the same. Starting with a builder image that describes this environment - with Ruby, Bundler, Rake, Apache, GCC, and other packages needed to set up and run a Ruby application installed - source-to-image performs the following steps:

1. Start a container from the builder image with the application source injected into a known directory

2. The container process transforms that source code into the appropriate runnable setup - in this case, by installing dependencies with Bundler and moving the source code into a directory where Apache has been preconfigured to look for the Ruby config.ru file.

3. Commit the new container and set the image entrypoint to be a script (provided by the builder image) that will start Apache to host the Ruby application.

For compiled languages like C, C++, Go, or Java, the dependencies necessary for compilation might dramatically outweigh the size of the actual runtime artifacts. To keep runtime images slim, S2I enables a multiple-step build processes, where a binary artifact such as an executable or Java WAR file is created in the first builder image, extracted, and injected into a second runtime image that simply places the executable in the correct location for execution.

For example, to create a reproducible build pipeline for Tomcat (the popular Java webserver) and Maven:

1. Create a builder image containing OpenJDK and Tomcat that expects to have a WAR file injected

2. Create a second image that layers on top of the first image Maven and any other standard dependencies, and expects to have a Maven project injected

3. Invoke source-to-image using the Java application source and the Maven image to create the desired application WAR

4. Invoke source-to-image a second time using the WAR file from the previous step and the initial Tomcat image to create the runtime image

By placing our build logic inside of images, and by combining the images into multiple steps, we can keep our runtime environment close to our build environment (same JDK, same Tomcat JARs) without requiring build tools to be deployed to production.

Reproducibility

Allow build environments to be tightly versioned by encapsulating them within a container image and defining a simple interface (injected source code) for callers. Reproducible builds are a key requirement to enabling security updates and continuous integration in containerized infrastructure, and builder images help ensure repeatability as well as the ability to swap runtimes.

Flexibility

Any existing build system that can run on Linux can be run inside of a container, and each individual builder can also be part of a larger pipeline. In addition, the scripts that process the application source code can be injected into the builder image, allowing authors to adapt existing images to enable source handling.

Speed

Instead of building multiple layers in a single Dockerfile, S2I encourages authors to represent an application in a single image layer. This saves time during creation and deployment, and allows for better control over the output of the final image.

Security

Dockerfiles are run without many of the normal operational controls of containers, usually running as root and having access to the container network. S2I can be used to control what permissions and privileges are available to the builder image since the build is launched in a single container. In concert with platforms like OpenShift, source-to-image can enable admins to tightly control what privileges developers have at build time.

Using an ImageStream makes it easy to change a tag for a container image. Otherwise to change a tag you need to download the whole image, change it locally, then push it all back. Also promoting applications by having to do that to change the tag and then update the deployment object entails many steps. With ImageStreams you upload a container image once and then you manage it’s virtual tags internally in OpenShift. In one project you may use the dev tag and only change reference to it internally, in prod you may use a prod tag and also manage it internally. You don’t really have to deal with the registry!

You can also use ImageStreams in conjuction with DeploymentConfigs to set a trigger that will start a deployment as soon as a new image appears or a tag changes its reference.

Using console URL link provided, you will be directed to the login page. Enter your login details that have also been provided by the instructor.

From here you will be taken to the OpenShift web console landing page.

Once you’re logged into the Web Console, click on the Web Terminal icon at the top right. This will open a panel at the bottom prompting you to create your first project. In the Project name field, enter workshop<student#> using your student number as the suffix.

Note For example, if you are student 15, the entry would be workshop15

Once you click start, the Web Terminal will automatically be connected to the project you just created. You’ll notice the Web Console updates with that project as well.

Azure Red Hat OpenShift provides many container images and templates to make creating new applications & services easy. The template provides parameter fields to define all the mandatory environment variables (user, password, database name, etc) with predefined defaults including auto-generation of password values. It will also define both a deployment configuration and a service.

For this exercise we will use the following template:

• mongodb-persistent uses a persistent volume store for the database data which means the data will survive a pod restart. Using persistent volumes requires a persistent volume pool be defined in the Azure Red Hat OpenShift deployment.

Hint You can retrieve a list of templates using the command below. The templates are preinstalled in the openshift namespace.

oc get templates -n openshift

Create a MongoDB deployment using the mongodb-persistent template. You’re passing in the values to be replaced (username, password and database) which generates a YAML/JSON file. You then pipe it to the oc create command.

oc process openshift//mongodb-persistent \
    -p MONGODB_USER=ratingsuser \
    -p MONGODB_PASSWORD=ratingspassword \
    -p MONGODB_DATABASE=ratingsdb \
    -p MONGODB_ADMIN_PASSWORD=ratingspassword | oc create -f -

This is what you should see in your console:

If you now head back to the web console and make sure you are in the workshop<student#> project, you should see a new entry for MongoDB.

Run the oc get all command to view the status of the new application and verify if the deployment of the MongoDB template was successful.

oc get all

Find the MongoDB service.

oc get svc mongodb

The service will be accessible at the following DNS name: mongodb.workshop<student#>.svc.cluster.local which is formed of [service name].[project name].svc.cluster.local. This resolves only within the cluster.

You can also retrieve this from the web console by toggling to the Administrator view, then navigating to Networking -> Services and selecting the mongodb service. You’ll need this hostname to configure the rating-api.

We’ll now deploy the rating-api app. Don’t miss the entry in the following command where we need you to add your GitHub username.

oc new-app nodejs:14-ubi8~https://github.com/<yourgithubusername>/rating-api --strategy=source

First we’ll need to get to the correct screen. Ensure you’re in the Administrator view, then navigate to Workloads -> Deployments, selecting rating-api, and move to the Environment tab.

We can now create the environment variable using the NAME MONGODB_URI. The VALUE should look like mongodb://[username]:[password]@[endpoint]:27017/ratingsdb. You’ll need to replace the [username] and [password] with the ones you used when creating the database. You’ll also need to replace the [endpoint] with the hostname acquired in the previous step.

Note Don’t miss replacing your student number in the following VALUE entry.

The VALUE should look something like this: mongodb://ratingsuser:ratingspassword@mongodb.workshop<student#>.svc.cluster.local:27017/ratingsdb

Hit Save when done.

It can also be done with an OC command.

oc set env deploy/rating-api MONGODB_URI=mongodb://ratingsuser:ratingspassword@mongodb.workshop<student#>.svc.cluster.local:27017/ratingsdb

You can navigate to the logs of the rating-api deployment by going Workloads -> Pods and selecting the rating-api pod that is currently running,

If you move to the Logs tab, you should see a log message confirming the code can successfully connect to the MongoDB.

Find the rating-api service.

oc get svc rating-api

Once you replace your student name in the following, the service will be accessible at this DNS name over port 8080: rating-api.workshop<student#>.svc.cluster.local:8080 which is formed of [service name].[project name].svc.cluster.local. This resolves only within the cluster.

The easiest way to access the URL needed to create the webhook in GitHub is through the web console. If you navigate to Builds -> Build Configs and selecting rating-api, you will see the copy option for the GitHub webhook URL near the bottom of the page. You’ll use this copied URL to setup the webhook on your GitHub repository.

If you prefer to use the command line, start by retrieving the GitHub webhook trigger secret. This is incldued if you copy from the web console, but you’ll need to gather it separately for use the GitHub webhook URL if you use the command line.

oc get bc/rating-api -o=jsonpath='{.spec.triggers..github.secret}'

You’ll get back something similar to the below. Make note the secret key in the red box as you’ll need it in a few steps.

Retrieve the GitHub webhook trigger URL from the build configuration.

oc describe bc/rating-api

Replace the <secret> placeholder with the secret you retrieved in the previous step to have a URL similar to https://api.qv4g35sq.westeurope.aroapp.io:6443/apis/build.openshift.io/v1/namespaces/workshop01/buildconfigs/rating-api/webhooks/zLKX0A_0CQs6qWNwQqpV/github. You’ll use this URL to setup the webhook on your GitHub repository.

In your GitHub repository (e.g. https://github.com/<your GitHub username>/rating-api), navigate to Settings -> Webhooks and select Add Webhook.

Paste the URL output (similar to above) into the Payload URL field.

Change the Content Type from GitHub’s default application/x-www-form-urlencoded to application/json.

Click Add webhook.

You will likely see a warning message appear about the effect of disabling SSL verification and its implications. Confirm the setting change, as this is a non-production environment.

If you click back into the newly created webhook, you should see a new tab called Recent Deliveries showing a green tick.

Note Because GitHub changes its UI regularly, you might see Recent Deliveries in a different location than shown in the screenshot above, such as at the bottom. You can also refresh the browser a few moments after saving the newly created webhook and you’ll see the green tick beside it.

Now whenever you push a change to your GitHub repository a new build will automatically start in OpenShift. After a successful build, a new deployment will be triggered as well.

We’ll now deploy the rating-web app. Don’t miss the entry in the following command where we need you to add your GitHub username.

oc new-app nodejs:14-ubi8~https://github.com/<yourgithubusername>/rating-web --strategy=source

Create the API environment variable for rating-web Deployment. The value of this variable is going to be the hostname/port of the rating-api service.

Instead of setting the environment variable through the web console, we’ll set it through the OpenShift CLI.

oc set env deploy/rating-web API=http://rating-api:8080

Expose the service.

oc expose svc/rating-web

Find out the created route hostname

oc get route rating-web

You should get a response similar to the below.

Note Certain browsers are configured to default to HTTPS. Please note that the web app we are creating uses HTTP for simplicity. You may need to manually force the non-secure HTTP usage.

Please also note that the fully qualified domain name (FQDN) is comprised of the application name and project name by default. The remainder of the FQDN, the subdomain, is your Azure Red Hat OpenShift cluster specific apps subdomain.

You can also retrieve this from the web console by toggling to the Developer view, then navigating to Topology and selecting the “Open URL” icon at the top right of the Deployment. Alternatively, you can select the rating-web Deployment and find the route in the lower right corner (you may need to scroll down).

Open the hostname in your browser, you should see the rating app page. Play around, submit a few votes and check the leaderboard.

As before, the fastest way in through the web console navigating to Builds -> Build Configs and selecting rating-web, then using the copy option for the GitHub webhook URL near the bottom of the page. You’ll once again use this copied URL to setup the webhook on your GitHub repository.

The process at the command line is also the same as before. Retrieve the GitHub webhook trigger secret you’ll need need in the GitHub webhook URL using the command below:

oc get bc/rating-web -o=jsonpath='{.spec.triggers..github.secret}'

You’ll get back something similar to the below. Make note the secret key in the red box as you’ll need it in a few steps.

Retrieve the GitHub webhook trigger URL from the build configuration.

oc describe bc/rating-web

Replace the <secret> placeholder with the secret you retrieved in the previous step to have a URL similar to https://api.qv4g35sq.westeurope.aroapp.io:6443/apis/build.openshift.io/v1/namespaces/workshop01/buildconfigs/rating-web/webhooks/VZJewR0m1E65dBAv1IYM/github. You’ll use this URL to setup the webhook on your GitHub repository.

In your GitHub repository (e.g. https://github.com/<your GitHub username>/rating-web), navigate to Settings -> Webhooks and select Add Webhook.

Paste the URL output (similar to above) into the Payload URL field.

Change the Content Type from GitHub’s default application/x-www-form-urlencoded to application/json.

Click Add webhook.

Again, you will likely see a warning message appear about the effect of disabling SSL verification and its implications. Confirm the setting change, as this is a non-production environment.

If you click back into the newly created webhook, you should see a new tab called Recent Deliveries showing a green tick.

Note Because GitHub changes its UI regularly, you might see Recent Deliveries in a different location than shown in the screenshot above, such as at the bottom. You can also refresh the browser a few moments after saving the newly created webhook and you’ll see the green tick beside it.

Now whenever you push a change to your GitHub repository a new build will automatically start in OpenShift. After a successful build, a new deployment will be triggered as well.

Go to the https://github.com/<your GitHub username>/rating-web/blob/master/src/App.vue file in your repository on GitHub.

Edit the file, and change the background-color: #999; line to be background-color: #0071c5.

Commit the changes to the file into the master branch.

Immediately head to the Builds screen in the web console. You’ll see a new build queued up which was triggered by the push. Once this is done, it will trigger a new deployment that you can track in the Workloads -> Deployments screen. Once this completes by creating a new pod, you should see the new website color updated.

Navigate to Networking -> Network Policies and click Create Network Policy.

You will create a policy that applies to any pod matching the app=rating-api label. The policy will allow ingress only from pods matching the app=rating-web label.

Use the YAML below in the editor, and make sure you’re targeting your project by changing the namespace to workshop<student#>.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-from-web
  namespace: workshop<student#>
spec:
  podSelector:
    matchLabels:
      app: rating-api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: rating-web

Click Create.

Use the following command

oc new-project ostoy<student#>

You should receive the following response

$ oc new-project ostoy<student#>
Now using project "ostoy<student#>" on server "https://api.gz49n8jb.westeurope.aroapp.io:6443".

Hint You can add applications to this project with the ‘new-app’ command. For example, try:

oc new-app rails-postgresql-example

To build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:

kubectl create deployment hello-node --image=k8s.gcr.io/serve_hostname

Equivalently, you can also create this new project using the web UI by selecting Home -> Projects, then clicking on the Create Project button on the right.

Feel free to open them up and take a look at what we will be deploying. For simplicity of this lab we have placed all the Kubernetes objects we are deploying in one “all-in-one” yaml file. Though in reality there are benefits to separating these out into individual yaml files.

ostoy-fe-deployment.yaml

ostoy-microservice-deployment.yaml

In your command line deploy the microservice using the following command:

oc apply -f ostoy-microservice-deployment.yaml

You should see the following response:

$ oc apply -f ostoy-microservice-deployment.yaml
deployment.apps/ostoy-microservice created
service/ostoy-microservice-svc created

If you open the ostoy-fe-deployment.yaml you will see we are defining:

• Persistent Volume Claim
• Deployment Object
• Service
• Route
• Configmaps
• Secrets

In your command line deploy the frontend along with creating all objects mentioned above by entering:

oc apply -f ostoy-fe-deployment.yaml

You should see all objects created successfully

$ oc apply -f ostoy-fe-deployment.yaml
persistentvolumeclaim/ostoy-pvc created
deployment.apps/ostoy-frontend created
service/ostoy-frontend-svc created
route.route.openshift.io/ostoy-route created
configmap/ostoy-configmap-env created
secret/ostoy-secret-env created
configmap/ostoy-configmap-files created
secret/ostoy-secret created

You should see the following response:

NAME          HOST/PORT                                                      PATH      SERVICES              PORT      TERMINATION   WILDCARD
ostoy-route   ostoy-route-ostoy01.apps.qv4g35sq.westeurope.aroapp.io                   ostoy-frontend-svc    <all>                   None

Copy ostoy-route-ostoy<student#>.apps.qv4g35sq.westeurope.aroapp.io from the command line and paste it into your browser and press enter. You should see the homepage of our application.

Go to the CLI and enter the following command to retrieve the name of your frontend pod which we will use to view the pod logs:

$ oc get pods -o name
pod/ostoy-frontend-679cb85695-5cn7x
pod/ostoy-microservice-86b4c6f559-p594d

So the pod name in this case is ostoy-frontend-679cb85695-5cn7x. Then run oc logs ostoy-frontend-679cb85695-5cn7x and you should see your messages:

$ oc logs ostoy-frontend-679cb85695-5cn7x
[...]
ostoy-frontend-679cb85695-5cn7x: server starting on port 8080
Redirecting to /home
stdout: All is well!
stderr: Oh no! Error!

You should see both the stdout and stderr messages.

It would be best to prepare by splitting your screen between the OpenShift Web UI and the OSToy application so that you can see the results of our actions immediately.

But if your screen is too small or that just won’t work, then open the OSToy application in another tab so you can quickly switch to the OpenShift console once you click the button. To get to this deployment in the OpenShift Web Console go to:

Workloads -> Deployments and select ostoy-frontend.

Go to the OSToy app, click on Home in the left menu, and enter a message in the “Crash Pod” tile (e.g. “This is goodbye!”) and press the “Crash Pod” button. This will cause the pod to crash and Kubernetes will restart the pod. After you press the button you will see:

Quickly switch to the Deployment screen. You will see that the pod is yellow meaning it is recovering the fallen pad and scaling back to 1. It should quickly come back up and show blue.

You can also check in the pod events and further verify that the container has crashed and been restarted.

Keep the page from the pod events still open from the previous step. Then in the OSToy app click on the “Toggle Health” button, in the “Toggle Health Status” tile. You will see the “Current Health” switch to “I’m not feeling all that well”.

This will cause the app to stop responding with a “200 HTTP code”. After 3 such consecutive failures, Kubernetes will kill the pod and restart it. Quickly switch back to the pod events tab and you will see that the liveness probe failed and the pod as being restarted.

Inside the OpenShift web UI click on Storage -> PersistentVolumeClaims in the left menu. You will then see a list of all persistent volume claims that our application has made. In this case there is just one called “ostoy-pvc”. You will also see other pertinent information such as whether it is bound or not, size, and storage class.

If you drill into ostoy-pvc, you will see ReadWriteOnce under Access Modes, which means that the volume can only be mounted to one node but the pod(s) can both read and write to that volume. The default in ARO is for Persistent Volumes to be backed by Azure Disk, but it is possible to chose Azure Files so that you can use the RWX (Read-Write-Many) access mode. (See here for more info on access modes)

In the OSToy app click on Persistent Storage in the left menu. In the “Filename” area enter a filename for the file you will create. (ie: “test-pv.txt”)

Underneath that, in the “File Contents” box, enter text to be stored in the file. (ie: “Azure Red Hat OpenShift is the greatest thing since sliced bread!” or “test” :) ). Then click “Create file”.

You will then see the file you created appear above under “Existing files”. Click on the file and you will see the filename and the contents you entered.

We now want to kill the pod and ensure that the new pod that spins up will be able to see the file we created. Exactly like we did in the previous section. Click on Home in the left menu.

Click on the “Crash pod” button. (You can enter a message if you’d like).

Click on Persistent Storage in the left menu

You will see the file you created is still there and you can open it to view its contents to confirm.

Now let’s confirm that it’s actually there by using the CLI and checking if it is available to the container. If you remember we mounted the directory /var/demo_files to our PVC. So get the name of your frontend pod

oc get pods

then get an SSH session into the container

oc rsh <podname>

then cd /var/demo_files

if you enter ls you can see all the files you created. Next, let’s open the file we created and see the contents

cat test-pv.txt

You should see the text you entered in the UI.

$ oc get pods
NAME                                  READY     STATUS    RESTARTS   AGE
ostoy-frontend-5fc8d486dc-wsw24       1/1       Running   0          18m
ostoy-microservice-6cf764974f-hx4qm   1/1       Running   0          18m

$ oc rsh ostoy-frontend-5fc8d486dc-wsw24
/ $ cd /var/demo_files/

/var/demo_files $ ls
lost+found   test-pv.txt

/var/demo_files $ cat test-pv.txt 
Azure Red Hat OpenShift is the greatest thing since sliced bread!

Then exit the SSH session by typing exit. You will then be in your CLI.

Click on Config Maps in the left menu.

This will display the contents of the configmap available to the OSToy application. We defined this in the ostoy-fe-deployment.yaml here:

kind: ConfigMap
apiVersion: v1
metadata:
  name: ostoy-configmap-files
data:
  config.json:  '{ "default": "123" }'

We can dig a bit deeper into this in the OpenShift UI by navigating to Workloads -> ConfigMaps and selecting the “ostoy-configmap-files” link.

Click on Secrets in the left menu.

This will display the contents of the secrets available to the OSToy application. We defined this in the ostoy-fe-deployment.yaml here:

apiVersion: v1
kind: Secret
metadata:
  name: ostoy-secret
data:
  secret.txt: VVNFUk5BTUU9bXlfdXNlcgpQQVNTV09SRD1AT3RCbCVYQXAhIzYzMlk1RndDQE1UUWsKU01UUD1sb2NhbGhvc3QKU01UUF9QT1JUPTI1
type: Opaque

If you plug the contents of secret.txt from above into the Base64 decoder at the bottom of the Secrets section in OSToy, we can see it matches the output further up that page.

Click on ENV Variables in the left menu.

This will display the environment variables available to the OSToy application. We added three as defined in the deployment spec of ostoy-fe-deployment.yaml here:

  env:
  - name: ENV_TOY_CONFIGMAP
    valueFrom:
      configMapKeyRef:
        name: ostoy-configmap-env
        key: ENV_TOY_CONFIGMAP
  - name: ENV_TOY_SECRET
    valueFrom:
      secretKeyRef:
        name: ostoy-secret-env
        key: ENV_TOY_SECRET
  - name: MICROSERVICE_NAME
    value: OSTOY_MICROSERVICE_SVC

The last one, MICROSERVICE_NAME is used for the intra-cluster communications between pods for this application. The application looks for this environment variable to know how to access the microservice in order to get the colors.

The right tile titled “Hostname Lookup” illustrates how the service name created for a pod can be used to translate into an internal ClusterIP address. Enter the name of the microservice following the format of my-svc.my-namespace.svc.cluster.local which we created in our ostoy-microservice.yaml which can be seen here:

apiVersion: v1
kind: Service
metadata:
  name: ostoy-microservice-svc
  labels:
    app: ostoy-microservice
spec:
  type: ClusterIP
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  selector:
    app: ostoy-microservice

In this case we will enter: ostoy-microservice-svc.ostoy<student#>.svc.cluster.local

We will see an IP address returned. In our example it is 172.30.165.246. This is the intra-cluster IP address; only accessible from within the cluster.

If we look at the tile on the left we should see one box randomly changing colors. This box displays the randomly generated color sent to the frontend by our microservice along with the pod name that sent it. Since we see only one box that means there is only one microservice pod. We will now scale up our microservice pods and will see the number of boxes change.

To confirm that we only have one pod running for our microservice, run the following command, or use the web UI.

[okashi@ok-vm ostoy]# oc get pods
NAME                                   READY     STATUS    RESTARTS   AGE
ostoy-frontend-679cb85695-5cn7x       1/1       Running   0          1h
ostoy-microservice-86b4c6f559-p594d   1/1       Running   0          1h

Let’s change our microservice definition yaml to reflect that we want 3 pods instead of the one we see. Download the ostoy-microservice-deployment.yaml and save it on your local machine.

Open the file using your favorite editor. Ex: vi ostoy-microservice-deployment.yaml.

Find the line that states replicas: 1 and change that to replicas: 3. Then save and quit.

It will look like this

spec:
    selector:
      matchLabels:
        app: ostoy-microservice
    replicas: 3

Assuming you are still logged in via the CLI, execute the following command:

oc apply -f ostoy-microservice-deployment.yaml

Confirm that there are now 3 pods via the CLI (oc get pods) or the web UI (Overview > expand “ostoy-microservice”).

See this visually by visiting the OSToy app and seeing how many boxes you now see. It should be three.

Now we will scale the pods down using the command line. Execute the following command from the CLI:

oc scale deployment ostoy-microservice --replicas=2

Confirm that there are indeed 2 pods, via the CLI (oc get pods) or the web UI.

See this visually by visiting the OSToy App and seeing how many boxes you now see. It should be two.

Lastly let’s use the web UI to scale back down to one pod. In the project you created for this app (ie: “ostoy”) in the left menu click Overview > expand “ostoy-microservice”. On the right you will see a blue circle with the number 2 in the middle. Click on the down arrow to the right of that to scale the number of pods down to 1.

See this visually by visiting the OSToy app and seeing how many boxes you now see. It should be one. You can also confirm this via the CLI or the web UI

1. Create the Horizontal Pod Autoscaler

Run the following command to create the autoscaler. This will create an HPA that maintains between 1 and 10 replicas of the Pods controlled by the ostoy-microservice DeploymentConfig created. Roughly speaking, the HPA will increase and decrease the number of replicas (via the deployment) to maintain an average CPU utilization across all Pods of 80% (since each pod requests 50 millicores, this means average CPU usage of 40 millicores)

oc autoscale deployment/ostoy-microservice --cpu-percent=80 --min=1 --max=10

2. View the current number of pods

In the OSToy app in the left menu click on “Autoscaling” to access this portion of the workshop.

As was in the networking section you will see the total number of pods available for the microservice by counting the number of colored boxes. In this case we have only one. This can be verified through the web UI or from the CLI.

You can use the following command to see the running microservice pods only: oc get pods --field-selector=status.phase=Running | grep microservice

3. Increase the load

Now that we know that we only have one pod let’s increase the workload that the pod needs to perform. Click the link in the center of the card that says “increase the load”. Please click only ONCE!

This will generate some CPU intensive calculations. (If you are curious about what it is doing you can click here).

Note: The page may become slightly unresponsive. This is normal; so be patient while the new pods spin up.

4. See the pods scale up

After about a minute the new pods will show up on the page (represented by the colored rectangles). Confirm that the pods did indeed scale up through the OpenShift Web Console or the CLI (you can use the command above).

Note: The page may still lag a bit which is normal.