在决定Kubernetes应用程序的更新策略时,可以选择使用Recreate策略。这与卸载和安装应用程序有什么不同?
Recreate
ghhkc1vu1#
Recreate策略将删除您的Pod,然后添加新的Pod-您将获得短暂的停机时间,但另一方面,您将不会在升级过程中使用太多额外的资源。您通常需要RollingUpgrade,因为它一次需要几个Pod,并且您可以在不停机的情况下部署无状态应用程序。
RollingUpgrade
5us2dqdw2#
我假设 “只是卸载和安装应用程序” 您的意思是完全删除您的部署,例如:
kubectl delete deployment nginx-deployment
字符串并再次创建它:
kubectl apply -f nginx-deployment.yaml
型请注意,使用Recreate策略时,不会完全删除部署,因此这里有根本的区别。选择此策略时,您只会通知kubernetes,您的部署管理的所有pod都应该在更新时删除并重新创建(例如,您更新容器的映像版本)而不是像使用RollingUpdate策略时那样一次删除和重新创建一个新版本。这样,您可以确保在更新发生并且具有新版本的图像的pod出现。当您删除部署并创建新部署时,新部署与旧部署无关。换句话说,将创建全新的Deployment资源,并且不会保留您所做更改的历史记录。我相信解释事物的最好方法总是一个例子。所以让我们继续下面的一个。假设你已经基于yaml manifest创建了一个新的nginx部署:
RollingUpdate
Deployment
型然后你决定更新镜像版本,或者通过编辑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
型当您简单地删除部署并重新创建它时,您将在新创建的部署的推出历史记录中没有任何内容,并且您将无法以如此简单的方式将其回滚到某个较旧的版本。
2条答案
按热度按时间ghhkc1vu1#
Recreate
策略将删除您的Pod,然后添加新的Pod-您将获得短暂的停机时间,但另一方面,您将不会在升级过程中使用太多额外的资源。您通常需要
RollingUpgrade
,因为它一次需要几个Pod,并且您可以在不停机的情况下部署无状态应用程序。5us2dqdw2#
我假设 “只是卸载和安装应用程序” 您的意思是完全删除您的部署,例如:
字符串
并再次创建它:
型
请注意,使用
Recreate
策略时,不会完全删除部署,因此这里有根本的区别。选择此策略时,您只会通知kubernetes,您的部署管理的所有pod都应该在更新时删除并重新创建(例如,您更新容器的映像版本)而不是像使用RollingUpdate
策略时那样一次删除和重新创建一个新版本。这样,您可以确保在更新发生并且具有新版本的图像的pod出现。当您删除部署并创建新部署时,新部署与旧部署无关。换句话说,将创建全新的
Deployment
资源,并且不会保留您所做更改的历史记录。我相信解释事物的最好方法总是一个例子。所以让我们继续下面的一个。
假设你已经基于yaml manifest创建了一个新的nginx部署:
型
然后你决定更新镜像版本,或者通过编辑
nginx-deployment.yaml
清单并重新应用它,或者这样:型
在任何一种情况下,您都可以通过运行以下命令来检查卷展栏历史记录:
型
你应该看到这样的东西:
型
当你有展示历史记录时,你可以撤消你的最新更改并返回到以前的版本:
型
现在,此部署的部署历史记录可能如下所示:
型
当您简单地删除部署并重新创建它时,您将在新创建的部署的推出历史记录中没有任何内容,并且您将无法以如此简单的方式将其回滚到某个较旧的版本。