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.