滚动更新：
在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如，第一批1台（金丝雀），第二批10%，第三批 50%，第四批100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀10 分钟，后续间隔 2分钟)。
实战
1、命令行监测
打开一个窗口按如下操作：
kubectl get pods -l app=myapp -n test -w
将事先准备好的例子，从myapp:v1改成myapp:v3
保存退出，执行如下
kubectl apply -f deploy-demo.yaml
再在监测的那个窗口可以看到信息如下：
pending表示正在进行调度，ContainerCreating表示正在创建一个pod，running表示运行一个pod，running起来一个pod之后再Terminating（停掉）一个pod，以此类推，直到所有pod完成滚动升级
在另外一个窗口执行kubectl get rs -n test，显示如下：
上面可以看到rs有两个，上面那个是升级之前的，已经被停掉，但是可以随时回滚
kubectl rollout history deployment myapp-deploy -n test
查看myapp-deploy这个控制器的滚动历史，显示如下：
需要回滚的话kubectl rollout undo作如下：
2、扩容到5个
cat deploy-demo.yaml
修改replicas数值是5
kubectl apply -f deploy-demo.yaml
kubectl get pods -n test
显示扩容成功了
3、修改maxSurge和maxUnavailable用来控制滚动更新的更新策略
修改更新策略最多不可用0个，也就是少不能少于5个，最大不能超过6个
kubectl patch deployment myapp-deploy -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}' -n test
然后执行
kubectl describe deployment myapp-deploy -n test
查看myapp-deploy这个控制器的详细信息
上面可以看到RollingUpdateStrategy: 0 max unavailable, 1 max surge
这个rollingUpdate更新策略变成了刚才设定的，因为我们设定的pod副本数是5，0和1表示最少不能少于5个pod，最多不能超过6个pod
这个就是通过控制RollingUpdateStrategy这个字段来设置滚动更新策略的。
