Deploy a Kubernetes rolling update
Rolling updates allow you to deploy a different version of a currently running application without downtime. Kubernetes routes traffic to the current version until the one is up and running, eliminating downtime. This activity will demonstrate how this works.

The Red Hat OpenShift Container Platform allows you to perform rolling updates of existing running applications. This feature, which is native to Kubernetes, means you can spin up a different version of an application—newer or older—than the current one, and have the traffic automatically routed to it. When done correctly, this can be used to create a zero-downtime deployment.
Put more succinctly: Kubernetes (and OpenShift) allow you to update an application with one simple command.
This OpenShift Developer Sandbox activity will guide you through the process of deploying an application, actively using that application, and then initiating a rolling update to version 2 of the application.
Expected time to completion: 15 minutes
Prerequisites
- An OpenShift Sandbox account
- The OpenShift command line interface (CLI) installed on your local PC
- git installed on your local PC
- The code editor of your choice; you’ll need it to create a few files on your local PC.
Working environment for this activity
- This activity will require you to work at the command line, using either Bash or PowerShell.
- You will need access to a web browser in order to obtain your OpenShift login token.
What you’ll be doing
- Log in to your OpenShift Sandbox at the command line
- Spin up an application (“myboot”, version 1)
- Run a
curl
command loop to view the application output - Change deployment image to version 2
- Observe rolling deployment results
Part 0: Log in to your OpenShift Sandbox at the command line
Step 0.1
Log in to your OpenShift Sandbox by following these instructions.
Part 1: Spin up an application (“myboot”, version 1)
Step 1.1
Create a file on your local PC named myboot-deployment.yml
with the following contents:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: myboot
name: myboot
spec:
replicas: 1
selector:
matchLabels:
app: myboot
template:
metadata:
labels:
app: myboot
spec:
containers:
- name: myboot
image: quay.io/rhdevelopers/myboot:v1
ports:
- containerPort: 8080
Notice that the Deployment object references the image quay.io/rhdevelopers/myboot:v
1.
Step 1.2
Run the following command, using the file you just created, to create the Deployment
object and get the application running in your cluster:
oc create -f myboot-deployment.yml
Step 1.3
Create a file on your local PC named myboot-service.yml
with the following contents:
apiVersion: v1
kind: Service
metadata:
name: myboot
labels:
app: myboot
spec:
ports:
- name: http
port: 8080
selector:
app: myboot
type: LoadBalancer
Step 1.4
Run the following command, using the file you just created, to create a Service
object that references the myboot Deployment
:
oc create -f myboot-service.yml
Step 1.5
Run the following command to create a route to the service. This allows the application to be reached from outside of the OpenShift cluster:
oc expose service/myboot
Part 2: Run a curl
command loop to view the application output
Step 2.1
Run the following command to see the URL of the application. We will use this URL in the following curl
command loop:
oc get routes
You will see output similar to the following:
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
myboot myboot-rhn-engineering-dschenck-dev.apps.sandbox.x8i5.p1.openshiftapps.com myboot http None
Step 2.2
Run a curl loop against the URL to see the application output. Replace the URL in the following command with the you got from the previous (oc get routes
) command and run the command at a command line.
If you are using Bash:
for ((i=1;i<=10000;i++)); do curl http://myboot-rhn-engineering-foo-dev.apps.sandbox.x8i5.p1.openshiftapps.com; sleep .01; done;
If you are using PowerShell:
while ($true) { (curl myboot-rhn-engineering-foo-dev.apps.sandbox.x8i5.p1.openshiftapps.com).content;start-sleep -Milliseconds 200; }
Figure 1 is an example of the kind of output you can expect:
Part 3: Change deployment image to version 2
Step 3.1
Run the following command to switch to the version 2 image for the “myboot” application:
oc set image deploy/myboot myboot=quay.io/rhdevelopers/myboot:v2
Part 4: Observe rolling deployment results
As the command in step 3.1 is processed, you will see the output of the curl loop change. This is a result of the rolling update.
You will most likely see some output that is the result of your pods being in a “not ready” state. This behavior is not optimal and can easily be prevented by adding a readiness probe to your deployment.
Figure 2 illustrates both the rolling update and the error associated with not using a readiness probe:
- The sections labeled with a 1 show the results before and after the rolling update. Notice that the host name has changed, demonstrating that a new pod has replaced the old one.
- The section labeled with a 2 is an example of the error that may occur in the time during which the old pod has been removed from service and the new pod is not ready. This situation can be avoided by using a readiness probe.
Next step
Proceed to the next sandbox activity in this series, "Guarantee application availability with OpenShift readiness probes," to go through the process of setting up a readiness probe to ensure that your rolling updates are error-free.