Recreate策略将删除您的Pod，然后添加新的Pod-您将获得短暂的停机时间，但另一方面，您将不会在升级过程中使用太多额外的资源。
您通常需要RollingUpgrade，因为它一次需要几个Pod，并且您可以在不停机的情况下部署无状态应用程序。

我假设 “只是卸载和安装应用程序” 您的意思是完全删除您的部署，例如：

kubectl delete deployment nginx-deployment

字符串
并再次创建它：

kubectl apply -f nginx-deployment.yaml

型
请注意，使用Recreate策略时，不会完全删除部署，因此这里有根本的区别。选择此策略时，您只会通知kubernetes，您的部署管理的所有pod都应该在更新时删除并重新创建（例如，您更新容器的映像版本）而不是像使用RollingUpdate策略时那样一次删除和重新创建一个新版本。这样，您可以确保在更新发生并且具有新版本的图像的pod出现。
当您删除部署并创建新部署时，新部署与旧部署无关。换句话说，将创建全新的Deployment资源，并且不会保留您所做更改的历史记录。
我相信解释事物的最好方法总是一个例子。所以让我们继续下面的一个。
假设你已经基于yaml manifest创建了一个新的nginx部署：

kubectl apply -f nginx-deployment.yaml

型
然后你决定更新镜像版本，或者通过编辑nginx-deployment.yaml清单并重新应用它，或者这样：

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

型
在任何一种情况下，您都可以通过运行以下命令来检查卷展栏历史记录：

kubectl rollout history deployment nginx-deployment

型
你应该看到这样的东西：

$ 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

型
当你有展示历史记录时，你可以撤消你的最新更改并返回到以前的版本：

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

型
现在，此部署的部署历史记录可能如下所示：

$ 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

型
当您简单地删除部署并重新创建它时，您将在新创建的部署的推出历史记录中没有任何内容，并且您将无法以如此简单的方式将其回滚到某个较旧的版本。