一 deploymentPod升级和回滚
1.1 deployment升级
若Pod是通过Deployment创建的，可以在运行时修改Deployment的Pod定义（spec.template）或镜像名称，并应用到Deployment对象上，系统即可完成Deployment的自动更新操作。 如果在更新过程中发生了错误， 则还可以通过回滚操作恢复Pod的版本。
示例：
代码语言：javascript复制 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升级原理
代码语言：javascript复制 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的发布历史记录都被保留在系统中，以便于我们随时进行回滚（可以配置历史记录数量）。
代码语言：javascript复制 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模板部分会被修改。
代码语言：javascript复制 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-deployment1.5 暂停和恢复deployment
对于一次复杂的Deployment配置修改，为了避免频繁触发Deployment的更新操作，可以先暂停Deployment的更新操作，然后进行
配置修改，再恢复Deployment，一次性触发完整的更新操作，从而避免不必要的Deployment更新操作了。
代码语言：javascript复制 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都在相同的命名空间内。
示例：
代码语言：javascript复制 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注意：使用此方式升级的时候需要注意以下两点：
- RC的名字（name） 不能与旧RC的名字相同。
- 在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回滚
代码语言：javascript复制 1 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 --rollback提示：RC的滚动升级不具有Deployment在应用版本升级过程中的历史记录、新旧版本数量的精细控制等功能，RC将逐渐被RS和Deployment所取代，建议用户优先考虑使用Deployment完成Pod的部署和升级操作。
