【博客700】如何使用 Nginx Ingress 快速实现金丝雀与蓝绿部署

如何使用 Nginx Ingress 快速实现金丝雀与蓝绿部署

背景

越来越多的应用采用微服务架构,应用数量相比传统模式更多,管理更加复杂,发布更加频繁,如果直接将新版本上线发布给全部用户。一旦遇到线上事故(或BUG),对用户的影响极大,解决问题周期较长,甚至有时不得不回滚到前一版本,严重影响了用户体验。为了保证整体系统的稳定,风险降到最低,我们可以采用灰度发布与蓝绿发布等不同的发布方式。

金丝雀发布

在这里插入图片描述

蓝绿发布

在这里插入图片描述

基于客户端请求头的流量切分

假设线上已运行了一套对外提供的七层demo应用,此时开发了一些新的功能,需要上线新版本demo应用,但是又不想直接替换成新版本demo应用,而是希望将请求头包含user=kubesre的客户端请求转发到新版本demo应用中,进行验证测试新版本demo应用,等测试验证通过并稳定后,可将所有流量从老版本demo应用切换到新版本demo应用中,再平滑地将老版本demo应用下线。创建新版本Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-new-canary
  annotations:
    # 开启Canary。
    nginx.ingress.kubernetes.io/canary: "true"
    # 请求头为user
    nginx.ingress.kubernetes.io/canary-by-header: "user"
    # 请求头user的值为kubesre时,请求才会被路由到新版本服务new-new中。
    nginx.ingress.kubernetes.io/canary-by-header-value: "kubesre"
spec:
  rules:
  - host: demo.kubesre.com
    http:
      paths:
      - path: /info
        pathType: Prefix
        backend:
          service:
            name: demo-new-svc
            port:
              number: 8080
  ingressClassName: nginx

基于客户端来源IP的流量切分

假设线上已运行了一套对外提供的七层demo应用,此时开发了一些新的功能,需要上线新版本demo应用,又不想直接替换成新版本demo应用,而是只希望公司内部人员能访问到新版本demo应用中,进行测试验证新版本demo应用,非公司内部人员访问还是访问到老版本应用中。等公司内部人员测试验证通过并稳定后,可将所有流量从老版本demo应用切换到新版本demo应用中,再平滑地将老版本demo应用下线。创建新版本Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-new-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "X-Forwarded-For"
    # 假设客户端来源IP为123.456.789.123
    nginx.ingress.kubernetes.io/canary-by-header-value: "123.456.789.123"
spec:
  rules:
  - host: demo.kubesre.com
    http:
      paths:
      - path: /info
        pathType: Prefix
        backend:
          service:
            name: demo-new-svc
            port:
              number: 8080
  ingressClassName: nginx

基于服务权重的流量切分

假设线上已运行了一套对外提供的七层demo应用,此时修复了一些问题,需要上线新版本demo应用,又不想直接替换成新版本demo应用,而是希望将20%的流量切换新版本。待运行一段时间稳定后,可将所有流量从老版本demo应用切换到新版本demo应用中,再平滑地将老版本demo应用下线。创建新版本Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-new-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "X-Forwarded-For"
    # 将20%的流量转发到新版本
    nginx.ingress.kubernetes.io/canary-weight: "20"
spec:
  rules:
  - host: demo.kubesre.com
    http:
      paths:
      - path: /info
        pathType: Prefix
        backend:
          service:
            name: demo-new-svc
            port:
              number: 8080
  ingressClassName: nginx

注解说明:

Nginx Ingress支持通过配置注解(Annotations)来实现不同场景下的发布和测试,可以满足灰度发布、蓝绿发布、A/B测试等业务场景。

实现原理:

具体实现过程如下:为服务创建两个Ingress,一个为常规Ingress,另一个为带nginx.ingress.kubernetes.io/canary: "true"注解的Ingress,称为Canary Ingress;为Canary Ingress配置流量切分策略Annotation,两个Ingress相互配合,即可实现多种场景的发布和测试。

Nginx Ingress的Annotation支持以下几种规则:

  • nginx.ingress.kubernetes.io/canary-by-header基于Header的流量切分,适用于灰度发布。如果请求头中包含指定的header名称,并且值为“always”,就将该请求转发给Canary Ingress定义的对应后端服务。如果值为“never”则不转发,可用于回滚到旧版本。如果为其他值则忽略该annotation,并通过优先级将请求流量分配到其他规则。
  • nginx.ingress.kubernetes.io/canary-by-header-value必须与canary-by-header一起使用,可自定义请求头的取值,包含但不限于“always”或“never”。当请求头的值命中指定的自定义值时,请求将会转发给Canary Ingress定义的对应后端服务,如果是其他值则忽略该annotation,并通过优先级将请求流量分配到其他规则。
  • nginx.ingress.kubernetes.io/canary-by-header-pattern与canary-by-header-value类似,唯一区别是该annotation用正则表达式匹配请求头的值,而不是某一个固定值。如果该annotation与canary-by-header-value同时存在,该annotation将被忽略。
    nginx.ingress.kubernetes.io/canary-by-cookie基于Cookie的流量切分,适用于灰度发布。与canary-by-header类似,该annotation用于cookie,仅支持“always”和“never”,无法自定义取值。
  • nginx.ingress.kubernetes.io/canary-weight基于服务权重的流量切分,适用于蓝绿部署。表示Canary Ingress所分配流量的百分比,取值范围[0-100]。例如,设置为100,表示所有流量都将转发给Canary Ingress对应的后端服务。

优先级问题:

以上注解规则会按优先级进行评估,优先级为:canary-by-header -> canary-by-cookie -> canary-weight。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值