Search code examples
kuberneteskubernetes-deployment

Difference between kubernetes recreate update strategy vs simply uninstall, install


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?


Solution

  • 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.