目录
一、常用的发布方式
1、蓝绿发布：
2、金丝雀发布（灰度发布）：
3、滚动更新（deployment的默认更新方式）：
二、声明式管理方法（yaml文件）
1、三种发布命令：
2、三种常用的yaml文件：
2.1、deployment的yaml文件：
2.2、service的yaml文件：
2.3、port的yaml文件：
一、常用的发布方式
三种常见的项目发布方式：
蓝绿发布、金丝雀发布（灰度发布）、滚动发布
应用程序升级，面临的最大的问题是新旧业务之间的切换。
立项—定稿—需求发布—开发—测试—发布
测试之后上线，在完美也会有问题。为了不让发生的问题影响所有用户，产生了上述的三种发布方式
1、蓝绿发布：
工作方式：
1、把应用服务集群标记为两个组，蓝组和绿组。先升级蓝组，要把蓝组从负载均衡当中移除，绿组继续提供服务
2、蓝组升级完毕，再把绿组从负载均衡中移除，绿组升级，然后都加入回负载均衡中去，完成对外服务
蓝绿发布对硬件资源要求很高，但是有了云计算和微服务，现在的成本也大大降低了
蓝绿发布的特点：
- 一旦出现问题，问题的影响范围很大
- 发布策略简单
- 基于现在的云计算和微服务，用户是无感知的
- 升级和回滚都比较方便
缺点：
在发布升级的过程中，只有一部分集群在对外提供服务，可能会使集群的负载能力下降，响应变慢，需要注意给这个集群增加负载能力（一般来说没什么特殊需要，一般都是半夜访问最小的之后升级）。在短时间内可能会浪费一定的资源成本
2、金丝雀发布（灰度发布）：
必须是基于deployment控制器创建的服务，才可以使用这种发布方式。相当于测试服
工作方式：
实际上也是一种滚动更新，发布的过程中，暂时停止，只有一部分的pod先升级，其他的pod还是处于老的版本。只有一部分用户可以访问新的版本，绝大多数用户还是老版本。确定无问题之后，再把剩下的老版本升级成新版本，把暂停取消，继续发布。如果有问题，可以立即回滚。暂停不是回滚，一旦取消暂停，只能全部升级完毕之后再回滚
#K8S的金丝雀暂停发布，只会更新一个kubectl set image deployment nginx nginx=nginx:1.24 --record && kubectl rollout pause deployment nginx
#统一更新kubectl rollout resume deployment nginx
#全部升级完毕后才能回滚kubectl rollout history deployment nginxkubectl rollout undo deployment nginx --to-revision=1
若想回滚，只能全部升级完毕之后，才能回滚
灰度发布特点：
- 自动化的要求比较高，对运维人员的要求比较高
- 方便发现问题，及时解决，影响范围比较小
- 用户无感知，可以实现一个平滑的过度。节约资源
- 发布策略比较复杂
- 不易回滚，必须等到全部发布成功之后，才能回滚
3、滚动更新（deployment的默认更新方式）：
deployment的默认更新方式
一般灰度和滚动发布即可
一般用滚动，特殊场景用灰度（要准备场景）
二、声明式管理方法（yaml文件）
1、适合对资源的修改操作
2、声明式管理依赖于yaml文件，所有的内容都在yaml文件中声明
3、编辑好的yml文件还是要靠陈述式命令发布到K8S集群中
K8S中支持两种声明式的资源管理方式：
1、yaml格式：用于配置和管理资源对象
2、json格式：只要用于在api接口之间消息的传递
1、三种发布命令：
kubectl create#create只能创建，不能更新。从指定的yml文件中读取配置，创建服务。不能更新kubectl apply -f#既可以创建资源对象，也可以更新资源对象。如果yml文件更改了，apply可以直接更新资源对象（用的最多的方式）kubectl delete -f#删除yml文件中声明的资源对象yaml文件如何生成：
两种方式：
1、手打
2、可以根据已有的资源直接生成
kubectl get deployments.apps nginx -o yamlkubectl get deployments.apps nginx -o yaml > /opt/test.yaml调用yaml文件
kubectl apply -f test.yaml改过一次的yaml文件再次调用会报错，重新导出yaml文件才行
若修改之后，想再调用加--force 强制调用
kubectl apply -f test.yaml --force2、三种常用的yaml文件：
- deployment的yaml文件（daemonset、statefulset）
- service的yaml文件
- 不基于控制器的pod的yaml文件
2.1、deployment的yaml文件：
#deployment的yaml文件模版
kubectl explain deploymentvim deploymentapiVersion: apps/v1
#声明api版本的标签
kind: Deployment
#定义资源的类型（Service/Pod/Deployment/Job/Ingress/Daemonset/Statefulset）
metadata:name: nginx1 namespace: test1labels: test: nginx1
#定义资源的元数据信息，比如资源名称、资源对象、部署的命名空间、标签等信息
spec:
#定义deployment的资源需要的参数属性replicas: 3
#定义副本数selector:
#定义标签选择器matchLabels: test: nginx1
#选择匹配的标签template:
#定义业务模版，如果定义了多个副本，所有的副本属性都会按照模版的配置进行匹配metadata: labels: test: nginx1
#定义了pod的副本都使用元数据的标签和属性来进行匹配spec:containers: - name: nginximage: nginx:1.10#ports: #- containerPort: 80
#spec声明的是容器的相关参数，虽然指定了容器的暴露端口是80，如果镜像默认的端口不是80，80也访问不了，端口这里可以忽略，默认的不用加，即使指定了其他端口，也不会改变容器的端口，要改只能进容器改.2.2、service的yaml文件：
vim service.yaml#定义api版本
apiVersion: v1
kind: Service
metadata:name: nginx1-servicenamespace: test1labels:test: nginx1
#元数据信息包括，service的名称（不能重复），所属的命名空间，以及要匹配的deployment的标签（要和之前的deployment标签一致，否则会重新生成新的service）spec:type: NodePortports: - port: 80targetPort: 80nodePort: 30000selector: test: nginx1
#匹配所有的标签都是test:nginx1的pod后端提供服务
2.3、port的yaml文件：
vim pod.yaml#pod的yaml模版
kubectl explain pod#定义pod的apiversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息,pod的名称，所属的命名空间，标签等
metadata:name: centos1namespace: test1spec:restartPolicy: Always
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略：Always、Never、Onfailure（只有异常>
退出才会重启，状态码非0重启，为0不重启），restartPolicy指的是容器的重启策略，资源类型定义为deplo
yment，容器的重启策略只能是Always，可以不加。containers:- name: centosimage: centos:7运行一次之后，centos会直接退出
想要持续运行要添加两个参数：
command、args
定义容器运行的命令参数，类型与docker的CMD和ENTRYPOINT
args可以理解为CMD，可以给command传参
CMD可以给ENTRYPOINT传参
command和args都会覆盖原容器的标准输出（CMD和ENTRYPOINT都会覆盖）
持续运行：
#定义pod的apiversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息,pod的名称，所属的命名空间，标签等
metadata:name: centos1namespace: test1spec:restartPolicy: Never
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略：Always、Never、Onfailure（只有异常>
退出才会重启，状态码非0重启，为0不重启），restartPolicy指的是容器的重启策略，资源类型定义为deplo
yment，容器的重启策略只能是Always，可以不加。containers:- name: centosimage: centos:7args: - /bin/bash- -c- while true; do sleep 3600; done
#多个命令用;分号隔开3600秒后自动退出
也可以在一行定义多个命令：用,逗号和空格隔开
command的多条命令一起执行必须是 /bin/bash -c 开头
格式：
command和args只能有一个。会把容器的标准输出覆盖。不论是args和command都会覆盖CMD和ENTRYPOINT
command和args不要同时出现，除非传参时。都会覆盖容器的标准输出（CMD和ENTRYPOINT）
