Last updated
Last updated
In this lab, you'll learn how to update the number of instances a deployment has and how to safely roll out an update of your application on Kubernetes.
For this lab, you need a running deployment of the guestbook application from the previous lab. If you deleted it, recreate it using:
A replica is a copy of a pod that contains a running service. By having multiple replicas of a pod, you can ensure your deployment has the available resources to handle increasing load on your application.
kubectl provides a scale subcommand to change the size of an existing deployment. Let's increase our capacity from a single running instance of guestbook up to 10 instances:
Kubernetes will now try to make reality match the desired state of 10 replicas by starting 9 new pods with the same configuration as the first.
To see your changes being rolled out, you can run:
The rollout might occur so quickly that the following messages might not display:
Once the rollout has finished, ensure your pods are running by using:
You should see output listing 10 replicas of your deployment:
Kubernetes allows you to do rolling upgrade of your application to a new container image. This allows you to easily update the running image and also allows you to easily undo a rollout if a problem is discovered during or after deployment.
In the previous lab, we used an image with a v1 tag. For our upgrade we'll use the image with the v2 tag.
To update and roll back:
Using kubectl, you can now update your deployment to use the v2 image. kubectl allows you to change details about existing resources with the set subcommand. We can use it to change the image being used.
To check the status of the rollout, run:
The rollout might occur so quickly that the following messages might not display:
Test the application as before, by accessing <public-IP>:<nodeport> in the browser to confirm your new code is active.
Remember, to get the "nodeport" and "public-ip" use the following commands. Replace $CLUSTER_NAME with the name of your cluster if the environment variable is not set.:
and
To verify that you're running "v2" of guestbook, look at the title of the page, it should now be Guestbook - v2. If you are using a browser, make sure you force refresh (invalidating your cache).
If you want to undo your latest rollout, use:
You can then use this command to see the status:
When doing a rollout, you see references to old replicas and new replicas. The old replicas are the original 10 pods deployed when we scaled the application. The new replicas come from the newly created pods with the different image. All of these pods are owned by the Deployment. The deployment manages these two sets of pods with a resource called a ReplicaSet. We can see the guestbook ReplicaSets with:
Before we continue, let's delete the application so we can learn about a different way to achieve the same results:
To remove the deployment, use
To remove the service, use:
Tip: Another way to improve availability is to to your deployment, as shown in the following diagram:
Note that a pod could have multiple containers, each with its own name. Each image can be changed individually or all at once by referring to the name. In the case of our guestbook Deployment, the container name is also guestbook. Multiple containers can be updated at the same time. (.)
Congratulations! You deployed the second version of the app. Lab 2 is now complete. Continue to the .
