标签:kubectl 升级 v2 deployment pod 声明 kubia
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的记录,可以修改此项参数修改判断时间。标签:kubectl,升级,v2,deployment,pod,声明,kubia 来源: https://blog.51cto.com/u_14841814/2869658
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。