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

Table of Contents

• Using the Kubernetes Recreate Strategy
• Deployment Rollback

Using the Kubernetes Recreate Strategy

In my first post in this series, we created a Greeting Service using TIBCO BusinessWorks Container Edition and we created manifest files and deployed our Micro Service into Minikube.

In this post, we?re going to upgrade our original version of the Micro Service to version 1.1 and we?ll use the Recreate strategy to perform the upgrade.

To do this, I?ve created a new manifest file (here) that has 2 changes to it. The first is to point it to the newer version of the Docker Image that we created earlier (v1.1), and also to add in the definition of the Recreate Strategy. The extracts from the manifest file of importance are below ? but look at the full file to compare the difference:

To perform our update, all we need to do is to apply the new version of the manifest file using the following command:

The rollout will happen immediately and has the effect of killing the current pods, whilst starting up the new versions. Looking at the dashboard, we can see that there are 2 pods in Pending status, and none running. We can also use the command below to check the rollout status from the command line:

Our command line utility that checks the Application has also stopped responding ? this is because I haven?t built any error handling in the client, so I?ll just have to stop and restart the shell command, and we can now see that the app has been upgraded and using the latest version as well as the host names changing of course.

Because I had to stop my client and restart ? that introduces downtime and may not be what you want (especially given the title of the article!). So we want to look at one of the other strategies.

The next post in the series will focus on Rolling Updates ? so I hope you?ll come back and continue learning.