Zero Downtime Deployment of BusinessWorks Container Edition with Kubernetes ? Part 3

Table of Contents

• Ramped/Rolling Update Strategy
• Starting the Rolling Upgrade

Ramped/Rolling Update Strategy

In my previous two posts (Part 1 and Part 2)we created and deployed a Micro Service using TIBCO BusinessWorks Container Edition into Kubernetes (I used Minikube), and then upgraded it using the Recreate strategy.

In this post, we?re going to take the original deployment of Version 1.0 (which we rolled back to at the end of the second post) and upgrade it again to 1.1, but this time using the Rolling Update strategy.

Rolling Updates, also known as Ramped Updates are actually the default deployment strategy in Kubernetes, so if you don?t make any changes to your manifest file ? this is the strategy that would be used.

Of course ? you can make changes so that you have a little more control over how the deployment strategy is employed.

In the extract above from my yaml manifest file, maxSurge defines how many new Pods will be created at any one time, whilst maxUnavailable defines how many Pods can be unavailable during the update. The full manifest file is here.

To execute the Rolling Update ? all we need to do is to execute the following:

As our replica count is set to 2, this means that when we start the update, 1 new Pod will be created, whilst the original 2 are still running. When the new Pod is ready (discovered through the ReadinessProbe), then 1 of the original Pods will be killed.

Actually ? I did the entire recording in a single take and split the recording into 5 videos to make it more consumable ? I hope you like the idea!

In the next post, we?ll be looking at using the Blue/Green update strategy with TIBCO BusinessWorks.