版本回退
接着上面的文章继续：https://www.cnblogs.com/zouzou-busy/p/16153612.html
前面我们已经对版本进行了升级， 通过查看 rs，发现有两个 rs，一个是 pc-deployment-5db6b86685，这个是老的，也就是 nginx:1.14 的版本。还有一个 pc-deployment-78d879f8b6，这个就是我们升级后的版本，当前有 3 个 pod 在运行
deployment 支持版本升级过程中的暂停、继续功能以及版本回退等。
kubectl rollout 支持下面的选项
- status：显示当前升级状态
- history：显示升级历史记录
- pause：暂停版本升级过程
- resume：继续以及暂停的版本升级过程
- restart：重启版本升级过程
- undo：回滚到上一级版本（可以使用 --to-revision 回滚到指定版本）
查看当前版本升级的状态
可以通过下面的命令查看更新的状态
# pc-deployment 是 deployment 的名称 kubectl rollout status deployment pc-deployment -n zouzou
查看升级历史记录
如果你的 CHANGE-CAUSE 为空的话，是因为你执行命令的时候没有加 --record 参数
kubectl create -f pc-deployment.yaml --record=true
查看历史版本
[root@dce-10-6-215-215 ~]# kubectl rollout history deploy pc-deployment -n zouzou deployment.apps/pc-deployment REVISION CHANGE-CAUSE 3 kubectl create --filename=pc-deployment.yaml --record=true 4 kubectl create --filename=pc-deployment.yaml --record=true
可以看到，有 3 和 4 两个版本，那为啥是 3 和 4 呢？1 和 2 版本去哪了？因为之前我们最早版本是 1，对应的镜像是 1.14，后面我们进行了升级，这时候版本为 2，镜像为1.15。在后面我们又把镜像从 1.15 改为了 1.14，这时候版本为 3，但版本 3 和版本 1 版本内容是一样的，所以 3 就是对应的 1 版本。在后面，我们又把镜像从 1.14 改为了 1.15，这时候版本为 4，但版本 4 和版本 2 的版本是一样的。所以就只有版本 3 和版本 4 了
这时候查看镜像是 1.15
版本回退
回到上一个版本
# 不加 --to-revision 就是回滚到上一个版本 kubectl rollout undo deployment pc-deployment -n zouzou
指定 --to-revision 就是回滚到某个版本
# 回退到 3 版本，这里直接使用 --to-revision=3 回滚到了 3 版本，如果省略这个选项，就是回退到上个版本 [root@dce-10-6-215-215 ~]# kubectl rollout undo deployment pc-deployment --to-revision=3 -n zouzou deployment.apps/pc-deployment rolled back # 查看发现，nginx 的镜像回到了 1.14，之前是 1.15 [root@dce-10-6-215-215 ~]# kubectl get deploy -n zouzou -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR nginx3 1/1 1 1 28h nginx nginx:1.14 app=nginx3 pc-deployment 4/3 3 4 113m nginx nginx:1.14 app=nginx-pod # 查看 rs 发现，旧的 rs pc-deployment-5db6b86685 已经有三个 pod 在运行了，新的 rs pc-deployment-78d879f8b6 的 pod 为 0 了 # 其实 deployment 之所以实现版本的回滚，就是通过记录下历史 rs 来实现的 # 一旦想回滚到哪个版本，只需要将当前版本 pod 数量降为 0，然后将回滚版本的 pod 提升为目标数量就可以了 [root@dce-10-6-215-215 ~]# kubectl get rs -n zouzou NAME DESIRED CURRENT READY AGE nginx3-c5d7c9466 1 1 1 175m pc-deployment-5db6b86685 3 3 3 113m pc-deployment-78d879f8b6 0 0 0 75m # 在查看版本，发现 3 版本没了，多了版本 5，其实版本 3 和版本 5 是一样的 [root@dce-10-6-215-215 ~]# kubectl rollout history deploy pc-deployment -n zouzou deployment.apps/pc-deployment REVISION CHANGE-CAUSE 4 kubectl create --filename=pc-deployment.yaml --record=true 5 kubectl create --filename=pc-deployment.yaml --record=true
总结：其实 deployment 之所以实现版本的回滚，就是通过记录下历史 rs 来实现的，一旦想回滚到哪个版本，只需要将当前版本 pod 数量降为 0，然后将回滚版本的 pod 提升为目标数量就可以了
金丝雀发布
金丝雀发布，即灰度发布，是一种 Pod 的发布方式。金丝雀发布采取先添加、再删除的方式，保证 Pod 的总量不低于期望值。并且在更新部分 Pod 后，暂停更新，当确认新 Pod 版本运行正常后再进行其他版本的 Pod 的更新
deployment 控制器支持控制更新过程中的控制，如“暂停（pause）”或“继续（resume）”操作
比如有一批新的 pod 资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，在筛选一小部分的用户请求路由到新版本的 pod 应用中，继续观察能否稳定的按期望的方式运行。确定没问题之后在继续完成剩下的 pod 资源滚动更新，否则立即回滚更新操作，这就是所谓的金丝雀发布。
先来查看下当前的 nginx 的版本
# nginx 的版本是 1.14 [root@dce-10-6-215-215 ~]# kubectl get deploy -n zouzou -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR nginx3 1/1 1 1 29h nginx nginx:1.14 app=nginx3 pc-deployment 3/3 3 3 168m nginx nginx:1.14 app=nginx-pod
在来看下 rs
# 可以看到，目前 rs 是用的 pc-deployment-5db6b86685 控制器 [root@dce-10-6-215-215 ~]# kubectl get rs -n zouzou -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx3-c5d7c9466 1 1 1 3h50m nginx nginx:1.14 app=nginx3,pod-template-hash=c5d7c9466 pc-deployment-5db6b86685 3 3 3 169m nginx nginx:1.14 app=nginx-pod,pod-template-hash=5db6b86685 pc-deployment-78d879f8b6 0 0 0 130m nginx nginx:1.15 app=nginx-pod,pod-template-hash=78d879f8b6
接下来我们就进行金丝雀发布
# 更新 deployment 的版本，并配置暂停 deployment [root@dce-10-6-215-215 ~]# kubectl set image deploy pc-deployment nginx=nginx:1.15 -n zouzou && kubectl rollout pause deployment pc-deployment -n zouzou deployment.apps/pc-deployment image updated deployment.apps/pc-deployment paused
执行完上面的命令之后，在来查看 deployment，从下面可以看到，nginx 的镜像为 1.15 了，但 READY 的有 4/3，其中的 4 表示我们有 4 个可以对外提供服务的 pod，3 表示我们期望的是三个，UP-TO-DATE 为 1 ，表示最新版本的 pod 数量为 1 个，AVAILABLE 为 4 ，表示当前可用的 pod 数量为 4 个
[root@dce-10-6-215-215 ~]# kubectl get deploy -n zouzou -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR nginx3 1/1 1 1 29h nginx nginx:1.14 app=nginx3 pc-deployment 4/3 1 4 172m nginx nginx:1.15 app=nginx-pod
在来看下 rs，从下面的结果可以看到，之前的三个 pod 还是正常运行的，之前没有 pod 的 pc-deployment-78d879f8b6 有一个可以用的，所以总共是有 4 个 pod，三个 镜像为 1.14 的，一个镜像为 1.15 的。因为我们升级的镜像是 1.15，如果升级一个之前没有用过的，就会在增加一个 pc-deployment-xxxxxxxxx。
监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
[root@dce-10-6-215-215 ~]# kubectl get rs -n zouzou -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx3-c5d7c9466 1 1 1 3h57m nginx nginx:1.14 app=nginx3,pod-template-hash=c5d7c9466 pc-deployment-5db6b86685 3 3 3 176m nginx nginx:1.14 app=nginx-pod,pod-template-hash=5db6b86685 pc-deployment-78d879f8b6 1 1 1 137m nginx nginx:1.15 app=nginx-pod,pod-template-hash=78d879f8b6
观察一下更新状态，从下面的结果里可以看到，三分之一的 pod 已更新。
[root@dce-10-6-215-215 ~]# kubectl rollout status deploy pc-deployment -n zouzou Waiting for deployment "pc-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
假如经过了一段时间，发现新的应用是没有问题的，这时候我们就可以进行全部升级了
# 继续升级 [root@dce-10-6-215-215 ~]# kubectl rollout resume deploy pc-deployment -n zouzou deployment.apps/pc-deployment resumed
在来查看下 nginx 的版本和 rs
kubectl get deploy -n zouzou -o wide kubectl get rs -n zouzou -o wide
删除 deployment
# 删除deployment，其下的rs和pod也将被删除 [root@dce-10-6-215-215 ~]# kubectl delete -f pc-deployment.yaml deployment.apps "pc-deployment" deleted
或者使用下面的命令
kubectl delete deployment deployment的名称 -n 命名空间
