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