Lab 7 summary
This lab teaches how to use the oc CLI to scale an OpenShift application up and down by changing the number of pod replicas in a Kubernetes/OpenShift Deployment. The sample app used is Parksmap, deployed from the container image:
quay.io/openshiftroadshow/parksmap
The lab first logs into Developer Sandbox using an oc login --token=... --server=... command copied from the OpenShift web console, then deploys the app, exposes it, checks the deployment, scales it to 3 replicas, and scales it back to 1 replica.
Main commands from the lab
# Login using token copied from OpenShift web console
oc login --token=<token> --server=<api-server>
# Deploy Parksmap from container image
oc new-app quay.io/openshiftroadshow/parksmap
# Expose the service
oc expose service/parksmap
# Check deployment
oc get deployment
# Scale up to 3 pods
oc scale deployment parksmap --replicas=3
# Verify scale-up
oc get deployment -l app=parksmap
# Scale down to 1 pod
oc scale deployment parksmap --replicas=1
# Verify scale-down
oc get deployment -l app=parksmap
Code language: PHP (php)
Expected outputs shown in the lab
After oc new-app quay.io/openshiftroadshow/parksmap, the lab shows output like:
imagestream.image.openshift.io "parksmap" created
deployment.apps "parksmap" created
service "parksmap" created
Code language: CSS (css)
Then OpenShift suggests exposing the app:
oc expose service/parksmap
Expected output:
route.route.openshift.io/parksmap exposed
For scale-up:
oc scale deployment parksmap --replicas=3
Expected output:
deployment.apps/parksmap scaled
Then:
NAME READY UP-TO-DATE AVAILABLE AGE
parksmap 3/3 3 3 43m
For scale-down:
oc scale deployment parksmap --replicas=1
Expected output:
deployment.apps/parksmap scaled
Then:
NAME READY UP-TO-DATE AVAILABLE AGE
parksmap 1/1 1 1 43m
Clean corrected version of Lab 7
There are two copy-paste wording issues in the PDF:
- It says “Install an application from source code using
oc new-app”, but the actual command uses a container image, not source code. - It says the following sections describe using the web console, but this lab is actually about using the
ocCLI.
The corrected lab flow should be:
# 1. Log in with token copied from OpenShift web console
oc login --token=<your-token> --server=<your-api-server>
# 2. Confirm user
oc whoami
# 3. Check current project
oc project
# 4. Deploy Parksmap from container image
oc new-app quay.io/openshiftroadshow/parksmap
# 5. Check created resources
oc get all
# 6. Expose the service as a route
oc expose service/parksmap
# 7. Get the route
oc get route parksmap
# 8. Check current deployment replica count
oc get deployment parksmap
# 9. Scale up to 3 pods
oc scale deployment parksmap --replicas=3
# 10. Verify scale-up
oc get deployment -l app=parksmap
oc get pods -l app=parksmap
# 11. Scale down to 1 pod
oc scale deployment parksmap --replicas=1
# 12. Verify scale-down
oc get deployment -l app=parksmap
oc get pods -l app=parksmap
# 13. Optional cleanup
oc delete all -l app=parksmap
oc delete route parksmap
Code language: PHP (php)
Difference from Lab 6
| Lab | Tool | Main Skill |
|---|---|---|
| Lab 6 | OpenShift web console | Scale app using Topology UI |
| Lab 7 | oc CLI | Scale app using oc scale deployment |
So yes: Lab 7 is the CLI version of Lab 6, using the same Parksmap-style scaling concept.
I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I have worked at Cotocus. I share tech blog at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow , and SEO strategies at Wizbrand.
Do you want to learn Quantum Computing?
Please find my social handles as below;
Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at WIZBRAND
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals
The lab demonstrates application scaling with the
ocCLI effectively, but it could also discuss how scaling decisions are influenced by workload behavior in production. Simply increasing replica counts does not always improve performance, especially for stateful services or applications with external dependencies. Including topics such as autoscaling policies, resource requests and limits, and monitoring key metrics would give readers a better understanding of how to scale applications efficiently while controlling infrastructure costs and maintaining reliability.