In this step, you'll learn how to update the number of instances a pod has and how to safely roll out an update of your application on Kubernetes.
To proceed, you need a running deployment of the guestbook
application that you created in the previous step.
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 ascale
subcommand to change the size of an existing deployment. Let's increase our capacity from a single running instance ofguestbook
up to 10 instances:$ kubectl scale --replicas=10 deployment guestbook deployment "guestbook" scaled
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:
kubectl rollout status deployment guestbook
.The rollout might occur so quickly that the following messages might not display:
$ kubectl rollout status deployment guestbook Waiting for rollout to finish: 1 of 10 updated replicas are available... Waiting for rollout to finish: 2 of 10 updated replicas are available... Waiting for rollout to finish: 3 of 10 updated replicas are available... Waiting for rollout to finish: 4 of 10 updated replicas are available... Waiting for rollout to finish: 5 of 10 updated replicas are available... Waiting for rollout to finish: 6 of 10 updated replicas are available... Waiting for rollout to finish: 7 of 10 updated replicas are available... Waiting for rollout to finish: 8 of 10 updated replicas are available... Waiting for rollout to finish: 9 of 10 updated replicas are available... deployment "guestbook" successfully rolled out
-
Once the rollout has finished, ensure your pods are running by using:
kubectl get pods
.You should see output listing 10 replicas of your deployment:
$ kubectl get pods NAME READY STATUS RESTARTS AGE guestbook-562211614-1tqm7 1/1 Running 0 1d guestbook-562211614-1zqn4 1/1 Running 0 2m guestbook-562211614-5htdz 1/1 Running 0 2m guestbook-562211614-6h04h 1/1 Running 0 2m guestbook-562211614-ds9hb 1/1 Running 0 2m guestbook-562211614-nb5qp 1/1 Running 0 2m guestbook-562211614-vtfp2 1/1 Running 0 2m guestbook-562211614-vz5qw 1/1 Running 0 2m guestbook-562211614-zksw3 1/1 Running 0 2m guestbook-562211614-zsp0j 1/1 Running 0 2m
Traditionally, when scaling out applications you would need to setup a Load Balancer to route requests to one of the many instances. With Kubernetes, load balancers are built in! You can continue to use the IP and Port you used in the last step to access the application - the requests will get forwarded to one of the Pods automatically. Sweet, right?
{% hint style="info" %} Pro Tip: Another way to improve availability is to add clusters and regions to your deployment, as shown in the following diagram: {% endhint %}
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.
Using kubectl
, you can 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.
-
Run the following command to change the container image reference on the existing guestbook deployment.
$ kubectl set image deployment/guestbook guestbook=svennam92/guestbook:v2
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 ourguestbook
Deployment, the container name is alsoguestbook
. Multiple containers can be updated at the same time. (More information.) -
Run
kubectl rollout status deployment/guestbook
to check the status of the rollout. The rollout might occur so quickly that the following messages might not display:$ kubectl rollout status deployment/guestbook Waiting for rollout to finish: 2 out of 10 new replicas have been updated... Waiting for rollout to finish: 3 out of 10 new replicas have been updated... Waiting for rollout to finish: 3 out of 10 new replicas have been updated... Waiting for rollout to finish: 3 out of 10 new replicas have been updated... Waiting for rollout to finish: 4 out of 10 new replicas have been updated... Waiting for rollout to finish: 4 out of 10 new replicas have been updated... Waiting for rollout to finish: 4 out of 10 new replicas have been updated... Waiting for rollout to finish: 4 out of 10 new replicas have been updated... Waiting for rollout to finish: 4 out of 10 new replicas have been updated... Waiting for rollout to finish: 5 out of 10 new replicas have been updated... Waiting for rollout to finish: 5 out of 10 new replicas have been updated... Waiting for rollout to finish: 5 out of 10 new replicas have been updated... Waiting for rollout to finish: 6 out of 10 new replicas have been updated... Waiting for rollout to finish: 6 out of 10 new replicas have been updated... Waiting for rollout to finish: 6 out of 10 new replicas have been updated... Waiting for rollout to finish: 7 out of 10 new replicas have been updated... Waiting for rollout to finish: 7 out of 10 new replicas have been updated... Waiting for rollout to finish: 7 out of 10 new replicas have been updated... Waiting for rollout to finish: 7 out of 10 new replicas have been updated... Waiting for rollout to finish: 8 out of 10 new replicas have been updated... Waiting for rollout to finish: 8 out of 10 new replicas have been updated... Waiting for rollout to finish: 8 out of 10 new replicas have been updated... Waiting for rollout to finish: 8 out of 10 new replicas have been updated... Waiting for rollout to finish: 9 out of 10 new replicas have been updated... Waiting for rollout to finish: 9 out of 10 new replicas have been updated... Waiting for rollout to finish: 9 out of 10 new replicas have been updated... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 9 of 10 updated replicas are available... Waiting for rollout to finish: 9 of 10 updated replicas are available... Waiting for rollout to finish: 9 of 10 updated replicas are available... deployment "guestbook" successfully rolled out
-
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:
$ kubectl describe service guestbook
and$ ibmcloud ks workers <name-of-cluster>
To verify that you're running "v2" of guestbook, look at the title of the page, it should now be
Guestbook - V2
. You may have to do a cache-less reload, withCtrl+F5
orCmd+Shift+R
-
If you want to undo your latest rollout, use:
$ kubectl rollout undo deployment guestbook deployment "guestbook"
You can then use
kubectl rollout status deployment/guestbook
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:
$ kubectl get replicasets -l app=guestbook NAME DESIRED CURRENT READY AGE guestbook-5f5548d4f 10 10 10 21m guestbook-768cc55c78 0 0 0 3h
Congratulations! You've demonstrated how to scale and rollout deployments. You should have a firm understanding of a standard DevOps flow with Kubernetes. Next, we'll use Knative to show how it makes everything we've done so far even simpler.
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 kubectl delete deployment guestbook
.
To remove the service, use kubectl delete service guestbook
.