Kubernetes权威指南——深入掌握Pod（七）

深入掌握Pod11、Pod的升级和回滚11.1、Deployment的升级11.2、Deployment的回滚11.3、暂停和恢复Deployment的部署操作以完成复杂的修改11.4、使用kubectl rolling-update命令完成RC的滚动升级11.5、其他管理对象的更新策略11.5.1、DaemonSet的更新策略11.5.2、StatefulSet的更新策略11、Pod的升级和回滚当集群中的某个服务需要升级时我们需要停止目前与该服务相关的所有Pod然后下载新版本镜像并创建新的Pod。如果集群规模比较大则这个工作变成了一个挑战而且先全部停止然后逐步升级的方式会导致较长时间的服务不可用。Kubernetes提供了滚动升级功能来解决上述问题。如果Pod是通过Deployment创建的则用户可以在运行时修改Deployment的Pod定义spec.template或镜像名称并应用到Deployment对象上系统即可完成Deployment的自动更新操作。如果在更新过程中发生了错误则还可以通过回滚操作恢复Pod的版本。11.1、Deployment的升级以Deployment nginx为例apiVersion:apps/v1kind:Deployment# 资源类型Kubernetes Deployment工作负载控制器metadata:name:nginx-deployment# Deployment 的名称spec:replicas:3# 期望运行的 Pod 副本数量这里是 3 个selector:# 标签选择器Deployment 通过此规则来关联和管理哪些 PodmatchLabels:app:nginx# 必须与下方 template 中的标签保持一致template:metadata:labels:app:nginx# 为该 Deployment 创建的 Pod 打上标签spec:containers:-name:nginx# 容器名称image:nginx:1.7.9# 使用的 Nginx 镜像及指定版本ports:-containerPort:80# 容器监听的端口已运行的Pod副本数量有3个# kubectl get podsNAME READY STATUS RESTARTS AGE nginx-deployment-4087004473-9jqqs1/1 Running01m nginx-deployment-4087004473-cq0cf1/1 Running01m nginx-deployment-4087004473-vxn561/1 Running01m现在Pod镜像需要被更新为Nginx:1.9.1我们可以通过kubectl set image命令为Deployment设置新的镜像名称$ kubectlsetimage deployment/nginx-deploymentnginxnginx:1.9.1 deploymentnginx-deploymentimage updated另一种更新的方法是使用kubectl edit命令修改Deployment的配置将spec.template.spec.containers[0].image从Nginx:1.7.9更改为Nginx:1.9.1$ kubectl edit deployment/nginx-deployment deploymentnginx-deploymentedited一旦镜像名或Pod定义发生了修改则将触发系统完成Deployment所有运行Pod的滚动升级操作。可以使用kubectl rollout status命令查看Deployment的更新过程$ kubectl rollout status deployment/nginx-deploymentWaiting for rollout to finish:2 out of 3 new replicas have been updated...Waiting for rollout to finish:2 out of 3 new replicas have been updated...Waiting for rollout to finish:2 out of 3 new replicas have been updated...Waiting for rollout to finish:2 out of 3 new replicas have been updated...Waiting for rollout to finish:2 old replicas are pending termination...Waiting for rollout to finish:1 old replicas are pending termination...Waiting for rollout to finish:1 old replicas are pending termination...Waiting for rollout to finish:1 old replicas are pending termination...Waiting for rollout to finish:2 of 3 updated replicas are available...deployment nginx-deployment successfully rolled out查看当前运行的Pod名称已经更新了$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-3599678771-01h26 1/1 Running 0 2m nginx-deployment-3599678771-57thr 1/1 Running 0 2m nginx-deployment-3599678771-s8p21 1/1 Running 0 2m查看Pod使用的镜像已经更新为Nginx:1.9.1了# kubectl describe pod/nginx-deployment-3599678771-s8p21Name: nginx-deployment-3599678771-s8p21......Image: nginx:1.9.1......那么Deployment是如何完成Pod更新的呢我们可以使用kubectl describe deployments/nginx-deployment命令仔细观察Deployment的更新过程。初始创建Deployment时系统创建了一个ReplicaSetnginx-deployment-4087004473​并按用户的需求创建了3个Pod副本。当更新Deployment时系统创建了一个新的ReplicaSetnginx-deployment-3599678771​并将其副本数量扩展到1然后将旧的ReplicaSet缩减为2。之后系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。最后新的ReplicaSet运行了3个新版本Pod副本旧的ReplicaSet副本数量则缩减为0。如图所示。下面列出Deployment nginx-deployment的详细事件信息$ kubectl describe deployments/nginx-deployment Name: nginx-deployment Namespace: default......Replicas:3updated|3total|3available|0unavailable StrategyType: RollingUpdate MinReadySeconds:0RollingUpdateStrategy:1max unavailable,1max surge Conditions: Type Status Reason ---- ------ ------ Available TrueMinimumReplicasAvailable OldReplicaSets:noneNewReplicaSet: nginx-deployment-3599678771(3/3 replicas created)Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- ------------- ---- ------------- -------------- ------- 55m 55m1{deployment-controller}Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-4087004473 to34m 4m1{deployment-controller}Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3599678771 to14m 4m1{deployment-controller}Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4087004473 to24m 4m1{deployment-controller}Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3599678771 to24m 4m1{deployment-controller}Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4087004473 to14m 4m1{deployment-controller}Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3599678771 to34m 4m1{deployment-controller}Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4087004473 to0运行kubectl get rs命令查看两个ReplicaSet的最终状态$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-35996787713331m nginx-deployment-408700447300052m在整个升级的过程中系统会保证至少有两个Pod可用并且最多同时运行4个Pod这是Deployment通过复杂的算法完成的。Deployment需要确保在整个更新过程中只有一定数量的Pod可能处于不可用状态。在默认情况下Deployment确保可用的Pod总数至少为所需的副本数量DESIRED减1也就是最多1个不可用maxUnavailable1​。Deployment还需要确保在整个更新过程中Pod的总数量不会超过所需的副本数量太多。在默认情况下Deployment确保Pod的总数最多比所需的Pod数多1个也就是最多1个浪涌值maxSurge1​。Kubernetes从1.6版本开始maxUnavailable和maxSurge的默认值将从1、1更新为所需副本数量的25%、25%。这样在升级过程中Deployment就能够保证服务不中断并且副本数量始终维持为用户指定的数量DESIRED​。对更新策略的说明如下。在Deployment的定义中可以通过spec.strategy指定Pod更新的策略目前支持两种策略Recreate重建和RollingUpdate滚动更新​默认值为RollingUpdate。在前面的例子中使用的就是RollingUpdate策略。Recreate设置spec.strategy.typeRecreate表示Deployment在更新Pod时会先杀掉所有正在运行的Pod然后创建新的Pod。RollingUpdate设置spec.strategy.typeRollingUpdate表示Deployment会以滚动更新的方式来逐个更新Pod。同时可以通过设置spec.strategy.rollingUpdate下的两个参数maxUnavailable和maxSurge来控制滚动更新的过程。下面对滚动更新时两个主要参数的说明如下。spec.strategy.rollingUpdate.maxUnavailable用于指定Deployment在更新过程中不可用状态的Pod数量的上限。该maxUnavailable的数值可以是绝对值例如5或Pod期望的副本数的百分比例如10%​如果被设置为百分比那么系统会先以向下取整的方式计算出绝对值整数​。而当另一个参数maxSurge被设置为0时maxUnavailable则必须被设置为绝对数值大于0从Kubernetes 1.6开始maxUnavailable的默认值从1改为25%​。举例来说当maxUnavailable被设置为30%时旧的ReplicaSet可以在滚动更新开始时立即将副本数缩小到所需副本总数的70%。一旦新的Pod创建并准备好旧的ReplicaSet会进一步缩容新的ReplicaSet又继续扩容整个过程中系统在任意时刻都可以确保可用状态的Pod总数至少占Pod期望副本总数的70%。spec.strategy.rollingUpdate.maxSurge用于指定在Deployment更新Pod的过程中Pod总数超过Pod期望副本数部分的最大值。该maxSurge的数值可以是绝对值例如5或Pod期望副本数的百分比例如10%​。如果设置为百分比那么系统会先按照向上取整的方式计算出绝对数值整数​。从Kubernetes 1.6开始maxSurge的默认值从1改为25%。举例来说当maxSurge的值被设置为30%时新的ReplicaSet可以在滚动更新开始时立即进行副本数扩容只需要保证新旧ReplicaSet的Pod副本数之和不超过期望副本数的130%即可。一旦旧的Pod被杀掉新的ReplicaSet就会进一步扩容。在整个过程中系统在任意时刻都能确保新旧ReplicaSet的Pod副本总数之和不超过所需副本数的130%。这里需要注意多重更新Rollover的情况。如果Deployment的上一次更新正在进行此时用户再次发起Deployment的更新操作那么Deployment会为每一次更新都创建一个ReplicaSet而每次在新的ReplicaSet创建成功后会逐个增加Pod副本数同时将之前正在扩容的ReplicaSet停止扩容更新​并将其加入旧版本ReplicaSet列表中然后开始缩容至0的操作。例如假设我们创建一个Deployment这个Deployment开始创建5个Nginx:1.7.9的Pod副本在这个创建Pod动作尚未完成时我们又将Deployment进行更新在副本数不变的情况下将Pod模板中的镜像修改为Nginx:1.9.1又假设此时Deployment已经创建了3个Nginx:1.7.9的Pod副本则Deployment会立即杀掉已创建的3个Nginx:1.7.9 Pod并开始创建Nginx:1.9.1 Pod。Deployment不会在等待Nginx:1.7.9的Pod创建到5个之后再进行更新操作。还需要注意更新Deployment的标签选择器LabelSelector的情况。通常来说不鼓励更新Deployment的标签选择器因为这样会导致Deployment选择的Pod列表发生变化也可能与其他控制器产生冲突。如果一定要更新标签选择器那么请务必谨慎确保不会出现其他问题。关于Deployment标签选择器的更新的注意事项如下。1添加选择器标签时必须同步修改Deployment配置的Pod的标签为Pod添加新的标签否则Deployment的更新会报验证错误而失败deploymentsnginx-deploymentwas not valid: * spec.template.metadata.labels: Invalid value:{app:nginx}:selectordoes not match templatelabels添加标签选择器是无法向后兼容的这意味着新的标签选择器不会匹配和使用旧选择器创建的ReplicaSets和Pod因此添加选择器将会导致所有旧版本的ReplicaSets和由旧ReplicaSets创建的Pod处于孤立状态不会被系统自动删除也不受新的ReplicaSet控制​。为标签选择器和Pod模板添加新的标签使用kubectledit deployment命令后效果如下$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-36617425163332s nginx-deployment-35996787713331m nginx-deployment-408700447300052m可以看到新ReplicaSetnginx-deployment-3661742516创建的3个新Pod$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-3599678771-01h261/1 Running02m nginx-deployment-3599678771-57thr1/1 Running02m nginx-deployment-3599678771-s8p211/1 Running02m nginx-deployment-3661742516-46djm1/1 Running052s nginx-deployment-3661742516-kws841/1 Running052s nginx-deployment-3661742516-wq30s1/1 Running052s2更新标签选择器即更改选择器中标签的键或者值也会产生与添加选择器标签类似的效果。3删除标签选择器即从Deployment的标签选择器中删除一个或者多个标签该Deployment的ReplicaSet和Pod不会受到任何影响。但需要注意的是被删除的标签仍会存在于现有的Pod和ReplicaSets上。11.2、Deployment的回滚有时例如新的Deployment不稳定时我们可能需要将Deployment回滚到旧版本。在默认情况下所有Deployment的发布历史记录都被保留在系统中以便于我们随时进行回滚可以配置历史记录数量​。假设在更新Deployment镜像时将容器镜像名误设置成Nginx:1.91一个不存在的镜像​$ kubectlsetimage deployment/nginx-deploymentnginxnginx:1.91 deploymentnginx-deploymentimage updated则这时Deployment的部署过程会卡住$ kubectl rollout status deployments nginx-deployment Waitingforrollout to finish:1out of3new replicas have been updated...由于执行过程卡住所以需要执行Ctrl-C命令来终止这个查看命令。查看ReplicaSet可以看到新建的ReplicaSetnginx-deployment-3660254150​$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-364629502833353s nginx-deployment-366025415011040s nginx-deployment-42342840260001m再查看创建的Pod会发现新的ReplicaSet创建的1个Pod被卡在镜像拉取过程中。$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-3646295028-d5r6r1/1 Running01m nginx-deployment-3646295028-jw22d1/1 Running059s nginx-deployment-3646295028-tw6x71/1 Running01m nginx-deployment-3660254150-9kj510/1 ImagePullBackOff049s为了解决上面这个问题我们需要回滚到之前稳定版本的Deployment。首先用kubectl rollout history命令检查这个Deployment部署的历史记录$ kubectl rollouthistorydeployment/nginx-deployment deploymentsnginx-deploymentREVISION CHANGE-CAUSE1kubectl create--filenamenginx-deployment.yaml--recordtrue2kubectlsetimage deployment/nginx-deploymentnginxnginx:1.9.13kubectlsetimage deployment/nginx-deploymentnginxnginx:1.91注意在创建Deployment时使用–record参数就可以在CHANGE-CAUSE列看到每个版本使用的命令了。另外Deployment的更新操作是在Deployment进行部署Rollout时被触发的这意味着当且仅当Deployment的Pod模板即spec.template被更改时才会创建新的修订版本例如更新模板标签或容器镜像。其他更新操作如扩展副本数将不会触发Deployment的更新操作这也意味着我们将Deployment回滚到之前的版本时只有Deployment的Pod模板部分会被修改。如果需要查看特定版本的详细信息则可以加上--revisionN参数$ kubectl rollouthistorydeployment/nginx-deployment--revision3deploymentsnginx-deploymentwith revision#3Pod Template: Labels:appnginx pod-template-hash3660254150Annotations: kubernetes.io/change-causekubectlsetimage deployment/nginx-deploymentnginxnginx:1.91 Containers: nginx: Image: nginx:1.91 Port:80/TCP Environment:noneMounts:noneVolumes:none现在我们决定撤销本次发布并回滚到上一个部署版本$ kubectl rollout undo deployment/nginx-deployment deploymentnginx-deploymentrolled back当然也可以使用–to-revision参数指定回滚到的部署版本号$ kubectl rollout undo deployment/nginx-deployment --to-revision2deploymentnginx-deploymentrolled back这样该Deployment就回滚到之前的稳定版本了可以从Deployment的事件信息中查看到回滚到版本2的操作过程$ kubectl describe deployment/nginx-deployment Name: nginx-deployment......OldReplicaSets:noneNewReplicaSet: nginx-deployment-3646295028(3/3 replicas created)Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 4m 4m1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-4234284026 to34m 4m1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3646295028 to14m 4m1deployment-controller Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4234284026 to24m 4m1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3646295028 to24m 4m1deployment-controller Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4234284026 to14m 4m1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3646295028 to34m 4m1deployment-controller Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4234284026 to04m 4m1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3660254150 to136s 36s1deployment-controller Normal DeploymentRollback Rolled back deploymentnginx-deploymentto revision236s 36s1deployment-controller Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-3660254150 to011.3、暂停和恢复Deployment的部署操作以完成复杂的修改对于一次复杂的Deployment配置修改为了避免频繁触发Deployment的更新操作可以先暂停Deployment的更新操作然后进行配置修改再恢复Deployment一次性触发完整的更新操作就可以避免不必要的Deployment更新操作了。以之前创建的Nginx为例$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment330332s $ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-42342840263337s通过kubectl rollout pause命令暂停Deployment的更新操作$ kubectl rollout pause deployment/nginx-deployment deploymentnginx-deploymentpaused然后修改Deployment的镜像信息$ kubectlsetimage deploy/nginx-deploymentnginxnginx:1.9.1 deploymentnginx-deploymentimage updated然后修改Deployment的镜像信息$ kubectlsetimage deploy/nginx-deploymentnginxnginx:1.9.1 deploymentnginx-deploymentimage updated查看Deployment的历史记录发现并没有触发新的Deployment部署操作$ kubectl rollouthistorydeploy/nginx-deployment deploymentsnginx-deploymentREVISION CHANGE-CAUSE1kubectl create--filenamenginx-deployment.yaml--recordtrue在暂停Deployment部署之后可以根据需要进行任意次数的配置更新。例如再次更新容器的资源限制$ kubectlsetresourcesdeployment nginx-deployment-cnginx--limitscpu200m,memory512Mi deploymentnginx-deploymentresource requirements updated最后恢复这个Deployment的部署操作$ kubectl rollout resume deploy nginx-deployment deploymentnginx-deploymentresumed可以看到一个新的ReplicaSet被创建出来了$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-31334408823336s nginx-deployment-423428402600049s查看Deployment的事件信息可以看到Deployment完成了更新# kubectl describe deployment/nginx-deploymentName: nginx-deployment......Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-4234284026 to328s 28s1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3133440882 to127s 27s1deployment-controller Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4234284026 to227s 27s1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3133440882 to226s 26s1deployment-controller Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4234284026 to125s 25s1deployment-controller Normal ScalingReplicaSet Scaled up replicasetnginx-deployment-3133440882 to323s 23s1deployment-controller Normal ScalingReplicaSet Scaled down replicasetnginx-deployment-4234284026 to0注意在恢复暂停的Deployment之前无法回滚该Deployment。11.4、使用kubectl rolling-update命令完成RC的滚动升级对于RC的滚动升级Kubernetes还提供了一个kubectlrolling-update命令进行实现。该命令创建了一个新的RC然后自动控制旧的RC中的Pod副本数量逐渐减少到0同时新的RC中的Pod副本数量从0逐步增加到目标 值来完成Pod的升级。需要注意的是系统要求新的RC与旧的RC都在相同的命名空间内。以redis-master为例假设当前运行的redis-master Pod是1.0版本现在需要升级到2.0版本。创建redis-master-controller-v2.yaml的配置文件如下apiVersion:v1kind:ReplicationController# 资源类型ReplicationControllerRC 控制器用于确保指定数量的 Pod 副本在运行metadata:name:redis-master-v2# RC 的名称labels:name:redis-masterversion:v2spec:replicas:1# 期望运行的 Pod 副本数量这里为 1 个selector:# 选择器定义该 RC 管理哪些带有特定标签的 Podname:redis-masterversion:v2template:metadata:labels:name:redis-master# Pod 模板的标签必须与上方的 selector 保持一致version:v2spec:containers:-name:master# 容器名称image:kubeguide/redis-master:2.0# 使用的 Redis 主节点镜像ports:-containerPort:6379# 容器暴露的端口Redis 默认端口在配置文件中需要注意以下两点。RC的名字name不能与旧RC的名字相同。在selector中应至少有一个Label与旧RC的Label不同以标识其为新RC。在本例中新增了一个名为version的Label以与旧RC进行区分。运行kubectl rolling-update命令完成Pod的滚动升级kubectl rolling-update redis-master-fredis-master-controller-v2.yamlkubectl的执行过程如下Creating redis-master-v2 At beginning of loop: redis-master replicas:2, redis-master-v2 replicas:1Updating redis-master replicas:2, redis-master-v2 replicas:1At end of loop: redis-master replicas:2, redis-master-v2 replicas:1At beginning of loop: redis-master replicas:1, redis-master-v2 replicas:2Updating redis-master replicas:1, redis-master-v2 replicas:2At end of loop: redis-master replicas:1, redis-master-v2 replicas:2At beginning of loop: redis-master replicas:0, redis-master-v2 replicas:3Updating redis-master replicas:0, redis-master-v2 replicas:3At end of loop: redis-master replicas:0, redis-master-v2 replicas:3Update succeeded. Deleting redis-master redis-master-v2等所有新的Pod都启动完成后旧的Pod也被全部销毁这样就完成了容器集群的更新工作。另一种方法是不使用配置文件直接用kubectl rolling-update命令加上–image参数指定新版镜像名称来完成Pod的滚动升级kubectl rolling-update redis-master--imageredis-master:2.0与使用配置文件的方式不同执行的结果是旧RC被删除新RC仍将使用旧RC的名称。kubectl的执行过程如下Creating redis-master-ea866a5d2c08588c3375b86fb253db75 At beginning of loop: redis-master replicas:2, redis-master-ea866a5d2c08588c 3375b86fb253db75 replicas:1Updating redis-master replicas:2, redis-master-ea866a5d2c08588c3375b86fb253db75replicas:1At end of loop: redis-master replicas:2, redis-master-ea866a5d2c08588c3375b86fb 253db75 replicas:1At beginning of loop: redis-master replicas:1, redis-master-ea866a5d2c08588c 3375b86fb253db75 replicas:2Updating redis-master replicas:1, redis-master-ea866a5d2c08588c3375b86fb 253db75 replicas:2At end of loop: redis-master replicas:1, redis-master-ea866a5d2c08588c3375b86fb 253db75 replicas:2At beginning of loop: redis-master replicas:0, redis-master-ea866a5d2c08588c 3375b86fb253db75 replicas:3Updating redis-master replicas:0, redis-master-ea866a5d2c08588c3375b86fb253db75replicas:3At end of loop: redis-master replicas:0, redis-master-ea866a5d2c08588c3375b86fb 253db75 replicas:3Update succeeded. Deleting old controller: redis-master Renaming redis-master-ea866a5d2c08588c3375b86fb253db75 to redis-master redis-master可以看到kubectl通过新建一个新版本Pod停掉一个旧版本Pod如此逐步迭代来完成整个RC的更新。更新完成后查看RC$ kubectl get rc CONTROLLER CONTAINER(S)IMAGE(S)SELECTOR REPLICAS redis-master master kubeguide/redis-master:2.0deploymentea866a5d2c08588c3375b86fb253db75,nameredis-master,versionv13可以看到kubectl给RC增加了一个key为“deployment”的Label这个key的名字可通过–deployment-label-key参数进行修改​Label的值是RC的内容进行Hash计算后的值相当于签名这样就能很方便地比较RC里的Image名字及其他信息是否发生了变化。如果在更新过程中发现配置有误则用户可以中断更新操作并通过执行kubectl rolling- update --rollback完成Pod版本的回滚$ kubectl rolling-update redis-master--imagekubeguide/redis-master:2.0--rollbackFound existing updateinprogress(redis-master-fefd9752aa5883ca4d53013a7b583967), resuming. Found desired replicas.Continuing update with existing controller redis-master. At beginning of loop: redis-master-fefd9752aa5883ca4d53013a7b583967 replicas:0, redis-master replicas:3Updating redis-master-fefd9752aa5883ca4d53013a7b583967 replicas:0, redis-master replicas:3At end of loop: redis-master-fefd9752aa5883ca4d53013a7b583967 replicas:0, redis-master replicas:3Update succeeded. Deleting redis-master-fefd9752aa5883ca4d53013a7b583967 redis-master至此可以看到Pod恢复到更新前的版本了。可以看出RC的滚动升级不具有Deployment在应用版本升级过程中的历史记录、新旧版本数量的精细控制等功能在Kubernetes的演进过程中RC将逐渐被RS和Deployment所取代建议用户优先考虑使用Deployment完成Pod的部署和升级操作。11.5、其他管理对象的更新策略Kubernetes从1.6版本开始对DaemonSet和StatefulSet的更新策略也引入类似于Deployment的滚动升级通过不同的策略自动完成应用的版本升级。11.5.1、DaemonSet的更新策略目前DaemonSet的升级策略包括两种OnDelete和RollingUpdate。1OnDeleteDaemonSet的默认升级策略与1.5及以前版本的Kubernetes保持一致。当使用OnDelete作为升级策略时在创建好新的DaemonSet配置之后新的Pod并不会被自动创建直到用户手动删除旧版本的Pod才触发新建操作。2RollingUpdate从Kubernetes 1.6版本开始引入。当使用RollingUpdate作为升级策略对DaemonSet进行更新时旧版本的Pod将被自动杀掉然后自动创建新版本的DaemonSet Pod。整个过程与普通Deployment的滚动升级一样是可控的。不过有两点不同于普通Pod的滚动升级一是目前Kubernetes还不支持查看和管理DaemonSet的更新历史记录二是DaemonSet的回滚Rollback并不能如同Deployment一样直接通过kubectl rollback命令来实现必须通过再次提交旧版本配置的方式实现。11.5.2、StatefulSet的更新策略Kubernetes从1.6版本开始针对StatefulSet的更新策略逐渐向Deployment和DaemonSet的更新策略看齐也将实现RollingUpdate、Paritioned和OnDelete这几种策略以保证StatefulSet中各Pod有序地、逐个地更新并且能够保留更新历史也能回滚到某个历史版本。