Skip to content

Rolling Update

This is Part 3 of a multi-part, self-paced quick start exercise.

What Will You Do

In part 2, you will test how the "Rolling Update" deployment pattern works. A deployment defined with a strategy of type "Rolling Update" updates pods in a rolling fashion i.e. a secondary ReplicaSet is created with the new version of the application, then the number of replicas of the old version is decreased and the new version is increased until the correct number of replicas is reached.

The rolling update strategy ensures there are some pods available to continue serving traffic during the update, so there is no downtime. However, both the old and new pods run side by side while the update is taking place, meaning any data stores or clients must be able to interact with both versions.

Rolling Update Strategy

Advantages

  • Low/No application downtime
  • The new version is released gradually
  • Well suited for stateful applications that can handle rebalancing of the data

Disadvantages

  • Rollout/rollback can take time
  • Supporting multiple APIs is hard
  • No control over traffic

Estimated Time

Estimated time burden for this part is 5 minutes.

Background

This part assumes you completed Part-2 and are continuing from that point onwards.

Step 1: Setup

  • Open Terminal
  • Copy the following command, enter the External-IP for your Load Balancer and execute it. 
while true; do sleep 1; curl http://<External-IP from above>;done

This will execute cURL against the configured IP every second. You should see something like the following. 

Blue v2
Blue v2
Blue v2....

Step 2: Update Strategy

  • Navigate to your Git repo -> echo.yaml file and Edit
  • Copy the following and replace the "strategy" section with this
  • Commit the file in your Git repository
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2       
      maxUnavailable: 1

When using the RollingUpdate strategy, there are options that allow us to fine-tune the update process:

  • maxSurge: The number of pods that can be created above the desired amount of pods during an update. This can be an absolute number or percentage of the replicas count. The default is 25%.

  • maxUnavailable: The number of pods that can be unavailable during the update process. This can be an absolute number or a percentage of the replicas count; the default is 25%.

Step 3: Update Message

  • Navigate to your Git repo -> echo.yaml file and Edit
  • Update the text for "args" from "-text=Blue v2" to "-text=Blue v3"
  • Commit the changes to your Git repository

The update will trigger the Gitops pipeline and it will automatically update the workload on the cluster. You should see something like the following in a few minutes. Notice that the new pods (based on v3) are created in parallel to the existing pods and that there is "zero downtime" for the application

Blue v2
Blue v2
Blue v2
Blue v3
Blue v3
Blue v3
Blue v3

Recap

In this part, you tested and experienced how the "Rolling Update" deployment pattern/strategy works.