deployment：声明式的升级应用

9.1.使用RC实现滚动升级

#kubectl rolling-update kubia-v1 kubia-v2 --image=luksa/kubia:v2

　　使用kubia-v2版本应用来替换运行着kubia-v1的RC，将新的复制控制器命名为kubia-v2，并使用luksa/kubia:v2最为镜像。

　　升级完成后使kubectl describe rc kubia-v2查看升级后的状态。

　　为什么现在不再使用rolling-update？

　　1.直接更新pod和RC的标签并不是一个很的方案；

　　2.kubectl只是执行升级中的客户端，但如果执行kubectl过程中是去了网络连接，升级将会被中断，pod和RC将会处于一个中间的状态，所以才有了Deployment资源的引入。

 

9.2.使用Deployment声明式的升级应用

　　Rs替代Rc来复制个管理pod。

　　创建Deployment前确保删除所有的RC和pod，但是暂时保留Service，

　　kubectl delete rc --all

　　创建Deployment

#kubectl create -f kubectl.depl-v1.yaml --record  //--record可以记录历史版本

#查看Deployment的相关信息
#kubectl get deployment
#kubectl describe deployment

#查看部署状态：
#kubectl rollout status deployment kubia

　　

9.3.触发deployment升级

#kubectl edit deployment kubia //修改完后资源对象会被更新
#kubectl patch deployment kubia -p '{...}' //只能包含想要更新的字段
#kubectl apply -f kubia-deploy-v2.yml //如果yml中定义的资源不存在，会自动被创建
#kubectl replace -f kubia-deploy-v2.yml //如果yml中定义的资源不存在，则会报错

　　修改configmap并不会触发升级，如果想要触发，可以创建新的configmap并修改pod模板引用新的configmap。

 

9.4.回滚deployment

　　在上述升级deployment过程中可以使用如下命令来观察升级的过程

#kubectl rollout status deployment kubia

　　如果出现报错，如何进行停止？可以使用如下命令进行回滚到先前部署的版本

#kubectl rollout undo deployment kubia

　　如何显示deployment的历史版本？

#kubectl rollout history deployment kubia

　　如何回滚到特定的版本？

#kubectl rollout undo deployment kubia --to-revision=1

　　

9.5.控制滚动升级的速率

　　在deployment的滚动升级过程中，有两个属性决定一次替换多少个pod：maxSurge、maxUnavailable,可以通过strategy字段下的rollingUpdate的属性来配置，

　　maxSurge：决定期望的副本数，默认值为25%，如果副本数设置为4个，则在滚动升级过程中，不会运行超过5个pod。

　　maxUnavaliable: 决定允许多少个pod处于不可用状态，默认值为25%，如果副本数为4，那么只能有一个pod处于不可用状态，

       默认情况下如果10分钟内没有升级完成，将被视为失败，如果要修改这个参数可以使用kubectl describe deploy kubia 查看到一条ProgressDeadline-Exceeded的记录，可以修改此项参数修改判断时间。