Using RollingUpdate Strategy with Standard Kubernetes Deployments

We explored one of the only two strategies we can use with Kubernetes Deployment resources. As we saw, the non-default Recreate is meant to serve legacy applications that are typically stateful and often do not scale. Next, we’ll see what the Kubernetes community thinks is the default way we should deploy our software.

🔍 Please bear in mind that, both in the previous and in this section, we are focused on what Kubernetes Deployments offer. We could have just as well used StatefulSet for stateful applications or DeamonSet for those that should be running in each node of the cluster. However, even though those behave differently, they are still based on similar principles. We’ll ignore those and focus only on Kubernetes Deployment resources, given that I do not want to convert this chapter into a neverending flow of rambling. Later on, we’ll go yet again outside of what Kubernetes offers out-of-the-box.

Now, let’s get back to the topic.

Changing deployment strategy to RollingUpdate strategy

To make our Deployment use the RollingUpdate strategy, we can either remove the whole strategy entry given that is the default, or we can change the type. We’ll go with the latter since the command to accomplish that is easier.

All we did was to change the strategy.type to RollingUpdate. You should see the full definition of the Deployment on the screen.

Changing return message and pushing changes

Next, we’ll change the application’s return message so that we can track the change easily from one release to the other.

We made the changes and pushed them to the GitHub repository.

Inspecting behavior before and after the new release is deployed

Now, all that’s left is to execute another loop. We’ll keep ...