Difference between kubernetes recreate update strategy vs simply uninstall, install

Question

When deciding on update strategy for a kubernetes application, there is an option to use Recreate strategy.

How would this be different from just uninstalling and installing the app?

Mattox

Answer 1

I assume that by "just uninstalling and installing the app" you mean complete deletion of your deployment e.g.:

kubectl delete deployment nginx-deployment

and creating it again:

kubectl apply -f nginx-deployment.yaml

Note that when using Recreate strategy there is no complete deletion of the deployment so there is fundamental difference here. By choosing this strategy you only inform kubernetes that all the pods managed by your deployment should be deleted and recreated when you update them (e.g. you update the image version of the container) rather than deleting and recreating their new versions one at a time what takes place when using RollingUpdate strategy. This way you make sure that certain number of pods serving an old version of the application are still available when the update occurs and pods with a new version of the image appear.

When you delete your deployment and create a new one, your new deployment has nothing to do with the old one. In other words, completely new Deployment resource is created and no history of the changes you made is preserved.

I believe the best way of explaining things is always an example. So let's move on to the following one.

Let's say you've created a new nginx deployment based on your yaml manifest:

kubectl apply -f nginx-deployment.yaml

and then you decided to update the image version, either by editing nginx-deployment.yaml manifest and re-applying it or this way:

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true

In either case you will be able to check rollout history by running:

kubectl rollout history deployment nginx-deployment

and you should see something like this:

$ kubectl rollout history deployment nginx-deployment 
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=nginx-deployment.yaml --record=true
2         kubectl set image deployment nginx-deployment nginx=nginx:1.16.1 --record=true

When you have rollout history you're able to undo your latest change and go back to the previous revision:

kubectl rollout undo deployment.v1.apps/nginx-deployment

Now your rollout history for this deployment may look like this:

$ kubectl rollout history deployment nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
2         kubectl set image deployment nginx-deployment nginx=nginx:1.16.1 --record=true
3         kubectl apply --filename=nginx-deployment.yaml --record=true

When you simply delete your deployment and recreate it again you will have nothing in rollout history for newly created deployment and you won't be able to roll it back to some older revision in such an easy way.

Raddie

so the only difference is "recreate" will maintain a rollout history and uninstall/install will not. is that correct ? – Mattox

Answer 2

Recreate strategy will delete your Pods and then add new Pods - you will get short downtime, but on the other side you will not use much extra resources during upgrade.

You typically want RollingUpgrade since that takes a few Pods at a time and you can deploy stateless applications without downtime.

Spectre