022.掌握Pod-Pod升级和回滚

一 deploymentpod升级和回滚

1.1 deployment升级

若pod是通过deployment创建的，可以在运行时修改deployment的pod定义（spec.template）或镜像名称，并应用到deployment对象上，系统即可完成deployment的自动更新操作。 如果在更新过程中发生了错误， 则还可以通过回滚操作恢复pod的版本。

示例：

  1 [root@uk8s-m-01 study]# vi nginx-deployment.yaml
  2 apiversion: apps/v1beta1
  3 kind: deployment
  4 metadata:
  5   name: nginx-deployment
  6 spec:
  7   replicas: 3
  8   template:
  9     metadata:
 10       labels:
 11         app: nginx
 12     spec:
 13       containers:
 14       - name: nginx
 15         image: nginx:1.7.9
 16         ports:
 17         - containerport: 80
 18 
 19 [root@uk8s-m-01 study]# kubectl create -f nginx-deployment.yaml
 20 [root@uk8s-m-01 study]# kubectl get pods

  1 [root@uk8s-m-01 study]# kubectl get deployment			#查看deployment
  2 [root@uk8s-m-01 study]# kubectl set image deployment/nginx-deployment nginx=nginx:1.8.1	#命令更新
  3 [root@uk8s-m-01 study]# kubectl get pods			        #查看升级后的pod

  1 [root@uk8s-m-01 study]# kubectl edit deployment/nginx-deployment			#直接编辑deployment

  1 [root@uk8s-m-01 study]# kubectl rollout status deployment/nginx-deployment		#查看升级情况

  1 [root@uk8s-m-01 study]# kubectl get pods
  2 [root@uk8s-m-01 study]# kubectl describe pod nginx-deployment-7448597cd5-8sng2 | grep image

1.2 deployment升级原理

  1 [root@uk8s-m-01 study]# kubectl describe deployments/nginx-deployment		#观察deployment的更新过程

初始创建deployment时，系统创建了一个replicaset（nginx-deployment-5754944d6c），并按用户的需求创建了3个pod副本。

当更新deployment时，系统创建了一个新的replicaset（nginx-deployment-b5f766d54），并将其副本数量扩展到1，然后将旧replicaset缩减为2。

之后，系统继续按照相同的更新策略对新旧两个replicaset进行逐个调整。

最后，新的replicaset运行了3个新版本pod副本，旧的replicaset副本数量则缩减为0。

  1 [root@uk8s-m-01 study]# kubectl get rs			#查看多次升级的结果

注意：在整个升级的过程中，系统会保证至少有两个pod可用，并且最多同时运行4个pod，这是deployment通过复杂的算法完成的。deployment需要确保在整个更新过程中只有一定数量的pod可能处于不可用状态。在默认情况下，deployment确保可用的pod总数至少为所需的副本数量（desired）减1，也就是最多1个不可用（maxunavailable=1）。

1.3 deployment升级策略

在deployment的定义中，可以通过spec.strategy指定pod更新的策略，目前支持两种策略：recreate（重建）和rollingupdate（滚动更新），默认值为rollingupdate。

• recreate：设置spec.strategy.type=recreate，表示deployment在更新pod时，会先杀掉所有正在运行的pod，然后创建新的pod。
• rollingupdate：设置spec.strategy.type=rollingupdate，表示deployment会以滚动更新的方式来逐个更新pod。同时，可以通过设置spec.strategy.rollingupdate下的两个参数（maxunavailable和maxsurge）来控制滚动更新的过程。

• spec.strategy.rollingupdate.maxunavailable：用于指定deployment在更新过程中不可用状态的pod数量的上限。 该maxunavailable的数值可以是绝对值（例如5）或pod期望的副本数的百分比（例如10%），如果被设置为百分比，那么系统会先以向下取整的方式计算出绝对值（整数）。而当另一个参数maxsurge被设置为0时，maxunavailable则必须被设置为绝对数值大于0。举例来说，当maxunavailable被设置为30%时，旧的replicaset可以在滚动更新开始时立即将副本数缩小到所需副本总数的70%。一旦新的pod创建并准备好，旧的replicaset会进一步缩容，新的replicaset又继续扩容。整个过程中系统在任意时刻都可以确保可用状态的pod总数至少占pod期望副本总数的70%。
• spec.strategy.rollingupdate.maxsurge：用于指定在deployment更新pod的过程中pod总数超过pod期望副本数部分的最大值。该maxsurge的数值可以是绝对值（例如5）或pod期望副本数的百分比（例
• 如10%）。如果设置为百分比，那么系统会先按照向上取整的方式计算出绝对数值（整数）。举例来说，当maxsurge的值被设置为30%时，新的replicaset可以在滚动更新开始时立即进行副本数扩容，只需要保证新旧replicaset的pod副本数之和不超过期望副本数的130%即可。一旦旧的pod被杀掉，新的replicaset就会进一步扩容。在整个过程中系统在任意时刻都能确保新旧replicaset的pod副本总数之和不超过所需副本数的130%。

1.4 deployment回滚

默认情况下，所有deployment的发布历史记录都被保留在系统中，以便于我们随时进行回滚（可以配置历史记录数量）。

  1 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment	#查看部署历史
  2 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment  --revision=3	#查看对应的部署历史版本
  3 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment  --revision=2	#查看对应的部署历史版本

提示：deployment的更新操作是在deployment进行部署（rollout）时被触发的，即当且仅当deployment的pod模板（即spec.template）被更改时才会创建新的修订版本，例如更新模板标签或容器镜像。其他更新操作（如扩展副本数）将不会触发deployment的更新操作，因此将deployment回滚到之前的版本时，只有deployment的pod模板部分会被修改。

  1 [root@uk8s-m-01 study]# kubectl rollout undo deployment/nginx-deployment --to-revision=2	#回滚版本
  2 [root@uk8s-m-01 study]# kubectl describe deployment/nginx-deployment

1.5 暂停和恢复deployment

对于一次复杂的deployment配置修改，为了避免频繁触发deployment的更新操作，可以先暂停deployment的更新操作，然后进行

配置修改，再恢复deployment，一次性触发完整的更新操作，从而避免不必要的deployment更新操作了。

  1 [root@uk8s-m-01 study]# kubectl get deployments				#查看deployment
  2 [root@uk8s-m-01 study]# kubectl get rs					#查看rs
  3 [root@uk8s-m-01 study]# kubectl rollout pause deployment/nginx-deployment	#暂停deployment
  4 [root@uk8s-m-01 study]# kubectl set image deployment/nginx-deployment nginx=nginx:1.10.3	#升级操作，但由于暂停deployment，因此不会触发更新
  5 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment	#查看历史版本
  6 [root@uk8s-m-01 study]# kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512mi
  7 [root@uk8s-m-01 study]# kubectl rollout resume deployment/nginx-deployment	#恢复deployment
  8 [root@uk8s-m-01 study]# kubectl get rs
  9 name                          desired   current   ready   age
 10 nginx-deployment-7448597cd5   0         0         0       52m
 11 nginx-deployment-84bc94dcb7   1         1         0       6s
 12 nginx-deployment-b5f766d54    3         3         3       55m

  1 [root@uk8s-m-01 study]# kubectl describe deployment/nginx-deployment
  2 [root@uk8s-m-01 study]# kubectl describe pods nginx-deployment-84bc94dcb7-hqxkk | grep image
  3     image:          nginx:1.10.3

二 rc升级和回滚

2.1 rc滚动升级

， kubernetes提供了kubectl rolling-update命令进行对于rc的滚动升级。该命令创建了一个新的rc，然后自动控制旧的rc中的pod副本数量逐渐减少到0，同时新的rc中的pod副本数量从0逐步增加到目标值，来完成pod的升级。

注意：该方式要求新的rc与旧的rc都在相同的命名空间内。

示例：

  1 [root@uk8s-m-01 study]# vi redis-master-controller-v1.yaml
  2 apiversion: v1
  3 kind: replicationcontroller
  4 metadata:
  5   name: redis-master-v1
  6   labels:
  7     name: redis-master
  8 spec:
  9   replicas: 1
 10   selector:
 11     name: redis-master
 12   template:
 13     metadata:
 14       labels:
 15         name: redis-master
 16     spec:
 17       containers:
 18       - name: master
 19         image: kubeguide/redis-master:1.0
 20         ports:
 21         - containerport: 6379
 22 
 23 [root@uk8s-m-01 study]# kubectl create -f redis-master-controller-v1.yaml

  1 [root@uk8s-m-01 study]# vi redis-master-controller-v2.yaml		#rc升级配置文件
  2 apiversion: v1
  3 kind: replicationcontroller
  4 metadata:
  5   name: redis-master-v2
  6   labels:
  7     name: redis-master
  8     version: v2
  9 spec:
 10   replicas: 1
 11   selector:
 12     name: redis-master
 13     version: v2
 14   template:
 15     metadata:
 16       labels:
 17         name: redis-master
 18         version: v2
 19     spec:
 20       containers:
 21       - name: master
 22         image: kubeguide/redis-master:2.0
 23         ports:
 24         - containerport: 6379

注意：使用此方式升级的时候需要注意以下两点：

1. rc的名字（name） 不能与旧rc的名字相同。
2. 在selector中应至少有一个label与旧rc的label不同， 以标识其为新rc。如上所示新增了一个名为version的label，以与旧rc进行区分。

  1 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 -f redis-master-controller-v2.yaml
  2 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 --image=kubeguide/redis-master:2.0	#也可直接命令中升级

kubectl通过新建一个新版本pod， 停掉一个旧版本pod，如此逐步迭代来完成整个rc的更新。

2.2 rc回滚

  1 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 --rollback

提示：rc的滚动升级不具有deployment在应用版本升级过程中的历史记录、新旧版本数量的精细控制等功能，rc将逐渐被rs和deployment所取代，建议用户优先考虑使用deployment完成pod的部署和升级操作。