​

多种发布策略

滚动发布

在一套旧环境中有若干个副本，先添加一个新版本的服务，然后停一个老版本的服务，一点点向新版本滚动，直到完成全部升级。如果环境中有10台机器，只需要新增1台机器，就可以滚动起来了

优点：节省机器，平滑过渡

缺点：

1. 新老版本共存，一旦访问出问题，无法确定是新版本的问题还是老版本的问题
2. 缺少对流量的控制

蓝绿发布

环境维度上，蓝老绿新。核心是部署两套环境，两套环境的机器配置都一样，老环境部署老版本，新环境部署新版本，以整套环境为基本单位来进行流量分发，比如旧80%，新20%，然后逐步增加新环境的流量。

优点：抗压能力强，出现问题可以随时切回老环境

缺点：耗费资源

金丝雀发布

先部署少量新版本服务，然后采用流量的控制的方式，逐步验证，扩大范围，适用于迭代版本，而不是大版本更新。

金丝雀发布有时候会与灰度发布代表一个意思，总体来说都是小范围尝试，然后逐步扩大。但细说的话有用法层面的区别，金丝雀发布只是站在整体流量的维度进行分配，没有细分用户特征。金丝雀发布可以被视为灰度发布的一种实现方式，但灰度发布的范围更广，涵盖了更多逐步发布的策略。

灰度发布

区分用户群体特征，从所有用户中选出一部分进行灰度验证，然后逐步扩大。

​

Ingress控制流量的方式

基于权重canary-weight

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: 'true'	# 表示开启金丝雀发布机制，启用canary
    nginx.ingress.kubernetes.io/canary-weight: '30'	# 表示分配30%的流量到当前版本
  name: gzd-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: wxzq.in-road.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            Port: 
              number: 80

基于用于请求canary-by-header

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: 'true'	# 表示开启金丝雀发布机制，启用canary
    nginx.ingress.kubernetes.io/canary-by-header: custom-key  # 自定义header
    nginx.ingress.kubernetes.io/canary-weight: '30'	# 表示分配30%的流量到当前版本
  name: gzd-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: wxzq.in-road.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            Port: 
              number: 80

更新上面的Ingress之后，我们在请求中加入不同的Header值，再次访问域名，有以下情况

1. 当Request Header中custom-key的值设置为never时，请求不会被发送到canary版本。
2. 当Request Header中custom-key的值设置为always时，请求会一直发送到canary版本。
3. 当Request Header中custom-key的值设置为其他任何值时，将忽略canary-by-header的设置，按照低优先级的canary-weight设置，将请求按照权重分发给新旧版本。

补充：

1. 如果想要自定义Request Header中custom-key的value值，可以设置

   1	nginx.ingress.kubernetes.io/canary-by-header-value: custom-value

   这样也可以把符合该规则的请求发送到指定的Ingress。

2. 基于用户请求的流量控制，不只可以在Request Header中添加键值，也可以在cookie中添加，具体的用法和canary-by-header类似：

   1	nginx.ingress.kubernetes.io/canary-by-cookie: custom-key