<p>Kubernetes provides us two deployment strategies. One is <strong><a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment" rel="nofollow noreferrer">Rolling Update</a></strong> and another one is <strong><a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment" rel="nofollow noreferrer">Recreate</a></strong>. I should use Rolling Update when I don't want go off air. But when should I be using Recreate?</p>

Aditya Bhuyan
<p>+1 to <a href="https://stackoverflow.com/a/67606389/11714114">F1ko's answer</a>, however let me also add a few more details and some real world examples to what was already said.</p>
<p>In a perfect world, where every application could be easily updated with <strong>no downtime</strong> we would be fully satisfied having only <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment" rel="nofollow noreferrer">Rolling Update</a> strategy.</p>
<p>But as the world isn't a perfect place and all things don't go always so smoothly as we could wish, in certain situations there is also a need for using <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment" rel="nofollow noreferrer">Recreate</a> strategy.</p>
<p>Suppose we have a <strong>stateful application</strong>, running in a <strong>cluster</strong>, where individual instances need to comunicate with each other. Imagine our aplication has recently undergone a <strong>major refactoring</strong> and this new version can't talk any more to instances running the old version. Moreover, we may not even want them to be able to form a cluster together as we can expect that it may cause some unpredicteble mess and in consequence neither old instances nor new ones will work properly when they become available at the same time. So sometimes it's in our best interest to be able to first shutdown every old replica and only once we make sure none of them is runnig, spawn a replica that runs a new version.</p>
<p>It can be the case when there is a major migration, let's say a major change in database structure etc. and we want to make sure that no pod, running the old version of our app is able to write any new data to the db during the migration.</p>
<p>So I would say, that in majority of cases it is very application-specific, individual scenario involving major migrations, legacy applications etc which would require accepting a certain downtime and <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment" rel="nofollow noreferrer">Recreate</a> all the pods at once, rather then updating them one-by-one like in <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment" rel="nofollow noreferrer">Rolling Update</a> strategy.</p>
<p>Another example which comes to my mind. Let's say you have an extremely old version of Mongodb running in a replicaset consisting of 3 members and you need to migrate it to a modern, currently supported version. As far as I remember, individual members of the replicaset can form a cluster only if there is 1 major version difference between them. So, if the difference is of 2 or more major versions, old and new instances won't be able to keep running in the same cluster anyway. Imagine that you have enough resources to run only 4 replicas at the same time. So rolling update won't help you much in such case. To have a quorum, so that the master can be elected, you need at least 2 members out of 3 available. If the new one won't be able to form a cluster with the old replicas, it's much better to schedule a maintanance window, shut down all the old replicas and have enough resources to start 3 replicas with a new version once the old ones are removed.</p>
