1)蓝绿发布
2)灰度发布【常用】
3)滚动发布
应用程序升级,面临最大的问题是新旧业务之间的切换
立项-定稿-需求发布-开发-测试-发布,测试上线后,再完美也会有问题,为了不影响所有用户,产生上述三种发布方式
①定义:把应用服务集群标记为两个组,认为分成蓝组和绿组。先升级蓝组,要把蓝组从负载均衡中移除,绿组继续提供服务,蓝组升级完毕,将蓝组加入到负载均衡中。再把绿组从负载均衡中移除,升级绿组,再将绿组加入到负载均衡中,完成对外服务
②特点
??一旦出现问题,影响范围很大
??发布策略较简单
??基于现在的云计算和微服务,成本大大降低,用户无感知
??升级和回滚都比较方便
③缺点:对硬件资源要求很高,在发布升级过程中,只有一部分集群对外服务,集群的负载能力可能会下降,响应变慢,需要给集群增加负载能力,短时间内可能会浪费一定的资源(一般是半夜升级,没有特殊需要可以不加)
必须基于deployment控制器创建的服务才可以使用灰度发布方式,在滚动更新的基础上,加入暂停功能。发布过程中,暂时停止,只有一部分pod先升级,其他pod还是旧版本,只有一部分用户可以访问新版本,绝大多数用户还是旧版本,确定完全没问题后,全部升级成新版本,取消暂停,继续发布,若有问题可以立即回滚(暂停不是回滚,一旦取消暂停,只能全部升级完毕后,才能回滚)
先更新一个pod版本 | kubectl set image deployment nginx nginx=nginx:1.24 --record && kubectl rollout pause deployment nginx |
继续更新剩下的pod版本 | kubectl rollout resume deployment nginx |
特点
??自动化要求比较高,对运维人员要求较高
??方便发现问题,及时解决,影响范围较小
??用户无感知,实现平滑过度,节约资源
??发布策略复杂
??不易回滚,必须全部发布成功之后才能回滚
①声明式管理适合对资源的修改操作
②声明式管理依赖于yaml文件,所有的内容都在yaml文件中声明
③编辑好的yaml文件仍然依赖于陈述式命令发布到k8s集群中
kubectl create | 只能创建,不能更新。从指定的yml文件中读取配置,创建服务,不能更新 |
kubectl apply -f (常用) | 既可以创建资源对象,也可以更新资源对象,若yml文件更改,apply可以直接更新资源对象 |
kubectl delete -f | 删除yml文件中声明的资源对象 |
①手打
②基于已有的资源直接生成
查看控制器的yaml文件格式 | kubectl get deployments.apps -o yaml |
查看service的yaml文件格式 | kubectl get service -o yaml |
查看pod的yaml文件格式 | kubectl get pod -o yaml |
基于已有的资源直接生成yaml文件 | |
后面加上--force强制升级可以不需要导出新的yaml文件再升级 |
(1)yaml格式:用于配置和管理资源对象
(2)json格式:用于在API接口之间传递消息
(1)deployment的yaml文件
(2)service的yaml文件
(3)不基于控制器创建yaml文件
Always | 在容器退出时重启容器,无论退出状态如何 |
Never | 用于短期任务或批处理,其中容器应运行一次,然后不会重新启动 |
OnFailure | 仅在容器以非0状态退出时才会重启容器 |
重启策略不会影响 Pod 本身的终止状态。只要 Pod 中至少有一个容器在运行,就认为 Pod 处于“正在运行”阶段。如果 Pod 中的所有容器都退出,则 Pod 会过渡到“已完成”或“失败”阶段,具体取决于最后一个容器的退出状态 |
command | 定义容器运行的命令参数,类似于docker的CMD和entrypoint。args可以理解为docker中的CMD,可以给command传参。command和args都会覆盖原容器内部的标准输出【面试题】 |
args |
/bin/bash | 指定输出脚本 |
-c | 指定输出内容 |
注:command和args只能有一个