concept rolling update in category kubernetes

This is an excerpt from Manning's book Kubernetes in Action. Login to get full access to this book.

Performing a rolling update

Instead of bringing up all the new pods and deleting the old pods at once, you can also perform a rolling update, which replaces pods step by step. You do this by slowly scaling down the previous ReplicationController and scaling up the new one. In this case, you’ll want the Service’s pod selector to include both the old and the new pods, so it directs requests toward both sets of pods. See figure 9.4.

Figure 9.4. A rolling update of pods using two ReplicationControllers

Doing a rolling update manually is laborious and error-prone. Depending on the number of replicas, you’d need to run a dozen or more commands in the proper order to perform the update process. Luckily, Kubernetes allows you to perform the rolling update with a single command. You’ll learn how in the next section.

Keep the curl loop running and open another terminal, where you’ll get the rolling update started. To perform the update, you’ll run the kubectl rolling-update command. All you need to do is tell it which ReplicationController you’re replacing, give a name for the new ReplicationController, and specify the new image you’d like to replace the original one with. The following listing shows the full command for performing the rolling update.

Figure 9.5. The state of the system immediately after starting the rolling update

Listing 9.5. Describing the new ReplicationController created by the rolling update

$ kubectl describe rc kubia-v2
Name:       kubia-v2
Namespace:  default
Image(s):   luksa/kubia:v2                                           #1
Selector:   app=kubia,deployment=757d16a0f02f6a5c387f2b5edb62b155
Labels:     app=kubia
Replicas:   0 current / 0 desired                                    #2
...

copy