Updating an application
Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. Rolling updates allow Deployments’ update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.
Let think, we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods). In Kubernetes, updates are versioned and any Deployment update can be reverted to previous (stable) version.
Step by Step
Demo
Step 1: Update the version of the app
To list your deployments use the get deployments command:
kubectl get deployments
To list the running Pods use the get pods
command:
kubectl get pods
To view the current image version of the app, run a describe
command against the Pods (look at the Image field):
kubectl describe pods
To update the image of the application to version 2, use the set image
command, followed by the deployment name and the new image version:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2
The command notified the Deployment to use a different image for your app and initiated a rolling update. Check the status of the new Pods, and view the old one terminating with the get pods
command:
kubectl get pods
Step 2: Verify an update
Create an environment variable called NODE_PORT that has the value of the Node port assigned:
export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}') echo NODE_PORT=$NODE_PORT
Next, we’ll do a curl
to the the exposed IP and port:
curl $(minikube ip):$NODE_PORT
We hit a different Pod with every request and we see that all Pods are running the latest version (v2).
The update can be confirmed also by running a rollout status command:
kubectl rollout status deployments/kubernetes-bootcamp
To view the current image version of the app, run a describe command against the Pods:
kubectl describe pods
We run now version 2 of the app (look at the Image field)
Step 3: Rollback an update
Let’s perform another update, and deploy image tagged as v10
:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10
And something is wrong… We do not have the desired number of Pods available. List the Pods again:
kubectl get pods
There is no image called v10
in the repository. Let’s roll back to our previously working version. We’ll use the rollout
undo command:
kubectl rollout undo deployments/kubernetes-bootcamp
We see that the deployment is using a stable version of the app (v2). The Rollback was successful.