灰度发布及声明式资源管理（yaml文件）

news2024/9/24 23:33:06

一、三种常见的项目发布方式

1）蓝绿发布

2）灰度发布【常用】

3）滚动发布

应用程序升级，面临最大的问题是新旧业务之间的切换

立项-定稿-需求发布-开发-测试-发布，测试上线后，再完美也会有问题，为了不影响所有用户，产生上述三种发布方式

1）蓝绿发布

①定义：把应用服务集群标记为两个组，认为分成蓝组和绿组。先升级蓝组，要把蓝组从负载均衡中移除，绿组继续提供服务，蓝组升级完毕，将蓝组加入到负载均衡中。再把绿组从负载均衡中移除，升级绿组，再将绿组加入到负载均衡中，完成对外服务

②特点

• 一旦出现问题，影响范围很大

• 发布策略较简单

• 基于现在的云计算和微服务，成本大大降低，用户无感知

• 升级和回滚都比较方便

③缺点：对硬件资源要求很高，在发布升级过程中，只有一部分集群对外服务，集群的负载能力可能会下降，响应变慢，需要给集群增加负载能力，短时间内可能会浪费一定的资源（一般是半夜升级，没有特殊需要可以不加）

2）灰度发布【常用】

必须基于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文件）

1、优点

①声明式管理适合对资源的修改操作

②声明式管理依赖于yaml文件，所有的内容都在yaml文件中声明

③编辑好的yaml文件仍然依赖于陈述式命令发布到k8s集群中

2、发布yaml文件的三种方式

kubectl create

只能创建，不能更新。从指定的yml文件中读取配置，创建服务，不能更新

kubectl apply -f

（常用）

既可以创建资源对象，也可以更新资源对象，若yml文件更改，apply可以直接更新资源对象

kubectl delete -f

删除yml文件中声明的资源对象

3、生成yaml文件

①手打

②基于已有的资源直接生成

查看控制器的yaml文件格式	kubectl get deployments.apps -o yaml

查看service的yaml文件格式	kubectl get service -o yaml

查看pod的yaml文件格式	kubectl get pod -o yaml

基于已有的资源直接生成yaml文件
后面加上--force强制升级可以不需要导出新的yaml文件再升级

4、在k8s中支持两种声明式的资源管理方式

（1）yaml格式：用于配置和管理资源对象

（2）json格式：用于在API接口之间传递消息

5、三种yaml文件

（1）deployment的yaml文件（deployment、daemeonset、statefulset）

（2）service的yaml文件

（3）不基于控制器的pod的yaml文件

（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