k8s 中的更新策略，版本回滚，金丝雀发布操作
一、更新策略
1.滚动更新策略
滚动升级策略会允许集群存在新旧版本,可能会对应用存在服务访问问题；
注意点：
Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源，而是将它们分置于两个不同的控制器之下：旧控制器的Pod对象数量不断减少的同时，新控制器的Pod对象数量不断增加，直到旧控制器不再拥有Pod对象，而新控制器的副本数量变得完全符合期望值为止；
maxUnavailable：表示最大不可用pod数量，可以是整数或者百分比；
maxSurge：表示可超过预期值的pod数量，可以是整数或者百分比；
为了保存版本升级的历史，需要在创建Deployment对象时于命令中使⽤“–record”选项。“kubectl apply -f myapp-deploy.yaml --record”；
适用情况：一些无状态应用，允许多个版本存在访问，需要快速回滚；
2.重建策略
重建策略会在创建新策略之前删除所有现有容器集，Kubernetes 先终止当前版本中的所有容器，然后在旧容器删除时同时启动所有新容器，不会有 2 种版本容器同时运行，这对服务使用者来说更简单
一般建议在开发环境使用该策略；
3.蓝绿发布（通过修改label,或者是结合istio）
4.金丝雀发布9(通过修改label,或者是结合istio)
二、版本回滚
查看历史记录
kubectl rollout history deployment nginx
回滚到上一个版本
kubectl rollout undo deployment nginx
也可以使用 --revision参数指定某个历史版本：
kubectl rollout undo deployment nginx --to-revision=3
三、金丝雀发布
金丝雀发布（又称灰度发布、灰度更新）：
金丝雀发布一般是先发1台机器，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试，国内常称灰度测试。以前旷工下矿前，会先放一只金丝雀进去用于探测洞里是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。
发布的各种策略详细介绍参考：蓝绿、ABTest、滚动部署、灰度发布、金丝雀发布介绍
实战
需要更新的应用
[root@k8s-master1 ~]# cat nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: test
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.7
name: nginx
1、打开一个命令行，来监测更新过程
kubectl get pods -l app=nginx -n test -w
## 下面命令执行完之后显示如下，之前的pod还在，新创建了一个pod，没有立即删除。
（也可以使用kubectl rollout statusdeployment myapp-deploy，显示Waiting for deployment "myapp-deploy"rollout to finish: 1 out of 5 new replicas have been updated）
打开另一个命令行来操作，如下：
1、更新镜像，并暂停升级
kubectl set image deployment nginx nginx=nginx:1.8 -n test --record=true && kubectl rollout pause deployment nginx -n test
–record=true 每次更新应用时 Kubernetes 都会记录下当前的配置
注：上面的步骤解释说明
把myapp这个容器的镜像更新到myapp:v2版本，更新镜像之后，创建一个新的pod就立即暂停，这就是我们说的金丝雀发布；如果暂停几个小时之后没有问题，那么取消暂停，就会依次执行后面步骤，把所有pod都升级。
2、解除暂停
确认新版本没问题，则解除暂停
kubectl rollout resume deployment nginx -n test
在刚才监测的界面可以看到如下一些信息，下面过程是把余下的pod里的容器都更新到新的版本：
[root@k8s-master1 ~]# kubectl get pods -l app=nginx -n test -w
NAME READY STATUS RESTARTS AGE
nginx-8fd4b9765-5j2v2 1/1 Running 0 98s
nginx-8fd4b9765-chd5x 1/1 Running 0 97s
nginx-8fd4b9765-xc8dr 1/1 Running 0 99s
nginx-58d48b746d-9j6kv 0/1 Pending 0 0s
nginx-58d48b746d-9j6kv 0/1 Pending 0 0s
nginx-58d48b746d-9j6kv 0/1 ContainerCreating 0 0s
nginx-58d48b746d-9j6kv 1/1 Running 0 1s
nginx-8fd4b9765-chd5x 1/1 Terminating 0 118s
nginx-58d48b746d-9xcrt 0/1 Pending 0 0s
nginx-58d48b746d-9xcrt 0/1 Pending 0 0s
nginx-58d48b746d-9xcrt 0/1 ContainerCreating 0 0s
nginx-8fd4b9765-chd5x 0/1 Terminating 0 119s
nginx-58d48b746d-9xcrt 1/1 Running 0 2s
nginx-8fd4b9765-5j2v2 1/1 Terminating 0 2m1s
nginx-58d48b746d-87x58 0/1 Pending 0 0s
nginx-58d48b746d-87x58 0/1 Pending 0 0s
nginx-58d48b746d-87x58 0/1 ContainerCreating 0 0s
nginx-58d48b746d-87x58 1/1 Running 0 0s
nginx-8fd4b9765-xc8dr 1/1 Terminating 0 2m2s
nginx-8fd4b9765-5j2v2 0/1 Terminating 0 2m2s
nginx-8fd4b9765-xc8dr 0/1 Terminating 0 2m3s
nginx-8fd4b9765-5j2v2 0/1 Terminating 0 2m3s
nginx-8fd4b9765-5j2v2 0/1 Terminating 0 2m3s
nginx-8fd4b9765-chd5x 0/1 Terminating 0 2m2s
nginx-8fd4b9765-chd5x 0/1 Terminating 0 2m2s
可以看到replicaset控制器有2个了
回滚
如果发现刚才升级的这个版本有问题可以回滚，查看当前有哪几个版本：
kubectl rollout history deployment nginx -n test
上面可以看到第一版没了，被还原成了第三版，第三版的前一版是第二版
kubectl get rs -n test -o wide
可以看到上面的rs已经用第一个了，这个就是还原之后的rs