kucectl的蓝绿发布、蓝灰发布、滚动发布和声明式资源管理方法(yaml)文件
项目如何发布
三种常见项目发布方式：
蓝绿发布
金丝雀发布(灰度发布)
滚动发布
应用程序升级，面临的最大问题就是新旧业务之间的切换
立项---定稿---需求发布---开发--测试----发布，测试之后上线，再完美也会有问题，为了不让发生的问题影响所有问题，上述三种发布方式
蓝绿发布:把应用服务群标记为两个组，蓝组和绿组，先升级蓝组，要把蓝组从负载均衡当中移除，绿组继续提供
蓝色升级完毕：把绿组从负载均衡当中移除，绿组升级，然后都加入回负载均衡当中去，完成对外服务
蓝绿发布特点
1、一旦出现问题，问题的影响范围很大
2、发布策略简单
3、基于现在的与计算和微服务，用户无感知
4、升级和回滚比较方便
缺点
再发布升级过程中，只有一部分集群再对外提供服务，可能会使集群的负载能力下降，响应变慢，需要注意给集群增加负载均衡能力(一般来说i没什么特殊需要)
短时间内可能会浪费一定资源成本
金丝雀发布(灰度发布)
delpoyment控制器之创建服务，才可以使用这个发布方式，滚动更新，暂停，发布的过程中，暂时停止，只有一部分的pod先升级，其他的pod还是处于老的版本，只有一部分用户可以访问新的版本，绝大多数用户还是再老版本，确定无问题后，再把剩下的老版本，升级成新的版本，先把暂停取消，继续发布，如果有问题，可以立即回滚，暂停不是回滚，一旦取消暂停只能全部升级完毕之后，再回滚
kubectl rollout history deployment nginx
灰度发布
1、自动化要求比较高，对运维人员的要求比较高
2、方便问题，即使解决，影响范围比较小
3、用户无感知，可以实现平滑过渡，节约资源
4、发布策略比较复杂
5、不易回滚，必须要全部发布成功之后才能回滚
滚动更新
deployment 的默认就是滚动更新
声明式资源管理方法(yaml)文件
1、适合对资源的修改操作
2、声明式管理依赖于yaml文件，所有的内容都再yaml文件当中管理
3、编辑好的yaml还是要靠陈述式命令发布到k8s集群当中
create只能创建不能更新，从指定yaml文件中读取配置，创建服务，之只能创建，不能更新
apply -f:既可以创建资源对象也可以发更新资源对象，如果yaml文件更改了，apply可以直接更新资源对象
delete -f:删除yaml文件中声明的资源的对象。
yaml中声明的：
deployment
pod
sevice
其中用的最多的式apply -f
yaml文件如何生成
1、手打
2、可以根据已有的资源直接生成(已经部署好了一个应用)
kubectl apply -f test.yaml --force
--force 强制更新
常用的yaml类型
1、deployment的yaml文件 daemonset statefulset 都是一个格式
2、service的yaml文件
3、不基于控制器的pod的yaml文件
k8s当中支持两种声明式的资源管理方式
1、第一种yaml格式，用于配置和管理资源对象
2、json格式:主要用于再api接口之间消息的传递
deployment
只有deployment是 VERSION: apps/v1
apiVersion: apps/v1
#声明api版本的标签
kind: Deployment
#定义资源的类型service/pod/deployment/Job/ingress/daemonset/statefulset
metadata:
name: nginx1
namespace: wqb1
labels:
defu: nginx1
#定义资源的元数据信息，比方资源的名称，资源对象部署的命名空间，标签等等信息
spec:
#定义deployment资源的参数属性
replicas: 3
#定义副本数
selector:
#定义标签选择器
matchLabels:
defu: nginx1
#选择匹配的标签
template:
#定义业务模板，如果定义了多个副本，所有的副本属性，都会按照模板的配置进行匹配，使
用的配置是那些
metadata:
labels:
defu: nginx1
#定义了pod的副本都是用元数据的标签和属性来进行匹配
spec:
containers:
- name: nginx
images: nginx:1.10
#posts:
#- containerPort: 80
#spec声明的容器的相关参数.虽然我指定了容器的暴露端口号是80，镜像默认的端口是80，nginx默认的镜像就是80
#即使制定了其他的端口，也不会改变容器的端口
service
#定义api的版本
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: wqb1
labels:
defu: nginx1
#元数据信息包括service的名称(再不同的命名空间里不能重复)，所属的命名空间，以及要>匹配的deployment的标签一定要和之前的保持一致
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
nodePort: 30000
#容器对外暴露的端口
selector:
defu: nginx1
#匹配所有的标签都是defu:nginx1的pod后端提供服务
pod
command args 用于定义容器运行的命令参数，类似于docker的CMD和entrypoint. CMD和entrypoint只能由一个
args可以理解为docker中cmd，可以给command传参
command和args都会覆盖原容器的标准输出（CMD和entrypoint都会覆盖原容器内部的标准输出）
#定义pod的apiservice
apiVersion: v1
kind: Pod
#定义元数据信息，pod名称,命名空间，标签
metadata:
name: centos1
namespace: wqb1
spec:
restartPolicy: Always
#restartPolicy指的是pod内容器启动失败或者有问题的重启策略：Always Never Onfailure(只有异常退出才会重启状态非0，不重启)restartPolicy指的是容器的重启策略，资源类型定义为delployment，容器的重
启策略只能是always
containers:
- name: centos
image: centos:7
#多个命令要用分号隔开
command: ["/usr/bin/test", "-e", "/etc/passwd"]
command: ["/bin/bash", "-c", "touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]
#command和args只能有一个，会把容器的标准输出覆盖，不论args和command都会覆盖CMD和ENTYPOINT
#只能用于执行一条命令
#command和args不要同时出现，除非要传参，都会覆盖容器的标准输出(CMD和entrypoint)总结：
三种发布方式
蓝绿发布
灰度发布（重点）基于deployment的滚动发布模式，使用了暂停机制 pause，resume(继续),回滚：所有都升级完毕之后才能回滚
滚动发布
三种yaml文件
deployment service pod