K8S基于ingress-nginx实现灰度发布

摘自:https://www.cnblogs.com/xiaoqi/p/ingress-nginx-canary.html

之前介绍过使用ambassador实现灰度发布,今天介绍如何使用ingre-nginx实现。

介绍

Ingress-Nginx 是一个K8S ingress工具,支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试。 Nginx Annotations 支持以下 4 种 Canary 规则:

  • nginx.ingress.kubernetes.io/canary-by-header:基于 Request Header 的流量切分,适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always时,请求将会被一直发送到 Canary 版本;当 Request Header 设置为 never时,请求不会被发送到 Canary 入口;对于任何其他 Header 值,将忽略 Header,并通过优先级将请求与其他金丝雀规则进行优先级的比较。
  • nginx.ingress.kubernetes.io/canary-by-header-value:要匹配的 Request Header 的值,用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时,它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值,必须与上一个 annotation (即:canary-by-header)一起使用。
  • nginx.ingress.kubernetes.io/canary-weight:基于服务权重的流量切分,适用于蓝绿部署,权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 Canary 入口。
  • nginx.ingress.kubernetes.io/canary-by-cookie:基于 Cookie 的流量切分,适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always时,它将被路由到 Canary 入口;当 cookie 值设置为 never时,请求不会被发送到 Canary 入口;对于任何其他值,将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

注意:金丝雀规则按优先顺序进行如下排序:

canary-by-header - > canary-by-cookie - > canary-weight

我们可以把以上的四个 annotation 规则可以总体划分为以下两类:

  • 基于权重的 Canary 规则

  • 基于用户请求的 Canary 规则

注意: Ingress-Nginx 实在0.21.0 版本 中,引入的Canary 功能,因此要确保ingress版本OK

测试

应用准备

两个版本的服务,正常版本:

import static java.util.Collections.singletonMap;

@SpringBootApplication
@Controller
public class RestPrometheusApplication {

    @Autowired
    private MeterRegistry registry;

    @GetMapping(path = "/", produces = "application/json")
    @ResponseBody
    public Map<String, Object> landingPage() {
        Counter.builder("mymetric").tag("foo", "bar").register(registry).increment();
        return singletonMap("hello", "ambassador");
    }

    public static void main(String[] args) {
        SpringApplication.run(RestPrometheusApplication.class, args);
    }

}

访问会输出:

{"hello":"ambassador"}  

灰度版本:

import static java.util.Collections.singletonMap;

@SpringBootApplication
@Controller
public class RestPrometheusApplication {

    @Autowired
    private MeterRegistry registry;

    @GetMapping(path = "/", produces = "application/json")
    @ResponseBody
    public Map<String, Object> landingPage() {
        Counter.builder("mymetric").tag("foo", "bar").register(registry).increment();
        return singletonMap("hello", "ambassador, this is a gray version");
    }

    public static void main(String[] args) {
        SpringApplication.run(RestPrometheusApplication.class, args);
    }

}

访问会输出:

{"hello":"ambassador, this is a gray version"}  

ingress 配置

我们部署好两个服务,springboot-rest-demo是正常的服务,springboot-rest-demo-gray是灰度服务,我们来配置ingress,通过canary-by-header来实现:

正常服务的:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: springboot-rest-demo
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: springboot-rest.jadepeng.com
    http:
      paths:
      - backend:
          serviceName: springboot-rest-demo
          servicePort: 80

canary 的:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: springboot-rest-demo-gray
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
spec:
  rules:
  - host: springboot-rest.jadepeng.com
    http:
      paths:
      - backend:
          serviceName: springboot-rest-demo-gray
          servicePort: 80

将上面的文件执行:

kubectl -n=default apply -f ingress-test.yml
ingress.extensions/springboot-rest-demo created
ingress.extensions/springboot-rest-demo-gray created

执行测试,不添加header,访问的默认是正式版本:

# curl http://springboot-rest.jadepeng.com; echo
{"hello":"ambassador"}
# curl http://springboot-rest.jadepeng.com; echo
{"hello":"ambassador"}

添加header,可以看到,访问的已经是灰度版本了

# curl -H "canary: true" http://springboot-rest.jadepeng.com; echo
{"hello":"ambassador, this is a gray version"}

多实例Ingress controllers

参考

  • https://kubesphere.com.cn/docs/v2.0/zh-CN/quick-start/ingress-canary/#ingress-nginx-annotation-%E7%AE%80%E4%BB%8B
  • https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary

作者:Jadepeng
出处:jqpeng的技术记事本--http://www.cnblogs.com/xiaoqi
您的支持是对博主最大的鼓励,感谢您的认真阅读。
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

原文地址:https://www.cnblogs.com/xichji/p/12208151.html

时间: 2024-11-08 21:18:49

K8S基于ingress-nginx实现灰度发布的相关文章

基于Geoip城市的灰度发布

1.安装epel源 wget https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm rpm -ivh epel-release-6-8.noarch.rpm 2.首先安装 MaxMind 的 GeoIP 库,其官网是: http://www.maxmind.com,MaxMind 提供了免费的 IP 地域数据库(GeoIP.dat),不过这个数据库文件是二进制的 yum install GeoIP G

Istio 太复杂?KubeSphere基于Ingress-Nginx实现灰度发布

在 Bookinfo 微服务的灰度发布示例 中,KubeSphere 基于 Istio 对 Bookinfo 微服务示例应用实现了灰度发布.有用户表示自己的项目还没有上 Istio,要如何实现灰度发布? 在 Ingress-Nginx (0.21.0 版本) 中,引入了一个新的 Canary 功能,可用于为网关入口配置多个后端服务,还可以使用指定的 annotation 来控制多个后端服务之间的流量分配. KubeSphere 在 2.0.2 的版本 中,升级了项目网关 (Ingress Con

基于cookie在nginx实现业务灰度发布

基于cookie在nginx实现业务灰度发布 背景 灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式. 灰度发布可以保证整体系统的稳定, 在初始灰度的时候就可以发现.调整问题,以保证其影响度. 业务存在灰度发布的需求, 可以通过nginx+lua形式实现业务的灰度发布, 目前这一形式已在广平互动广告相关业务已经实现. 流程 用户使用帐号登录后,判断用户帐号是否在灰度发布的名单中,如果再则给用户的cookie中增加灰度发布标识,然后刷新页面. 当用户访问页面时,业务接入层的nginx方向代理会

k8s容器灰度发布最佳实践(基于spinnaker)

k8s中的容器一般是通过deployment管理的,那么一次滚动升级理论上会更新所有pod,这由deployment资源特性保证的,但在实际的工作场景下,需要灰度发布进行服务验证,即只发布部分节点,这似乎与k8s的deployment原理相违背,但是灰度发布的必要性,运维同学都非常清楚,如何解决这一问题? 最佳实践:定义两个不同的deployment,例如:fop-gate和fop-gate-canary,但是管理的pod所使用的镜像.配置文件全部相同,不同的是什么呢?答案是:replicas

[系统集成] 用 Kubernetes Nginx Ingress 实现 HTTP 服务发布与负载均衡

用户在 Kubernetes 上部署的服务一般运行于私有网络,Pod和Service 提供了 hostPort,NodePort等参数用于暴露这些服务端口到K8S节点上,供使用者访问.这样的方法有明显缺点: 1)容易占用过多的主机端口: 2)服务端口暴露到多台主机会增加防火墙和安全配置的难度 3)默认的hostPort,NodePort方式没有负载均衡的作用 K8S的 Ingress 资源提供了另一种服务暴露的方法,它可以获取各个服务的状态,传递给nginx等工具进行配置修改.重新加载等工作,实

nginx 根据IP 进行灰度发布

灰度发布,简单来说,就是根据各种条件,让一部分用户使用旧版本,另一部分用户使用新版本. nginx 的语法本身可以看作是一门小型的编程语言,通过简单的编程,可以轻松实现基于IP的灰度发布. 需求:搭建准生产环境,供开发人员/运维在线上做最后的调整.如果OK,直接用rsync推送至生产环境. 条件:办公室网络出口有固定IP 解决办法: nginx 负载均衡器判断客户端IP地址, 如果是办公室IP,则反向代理到准生产环境: 如果不是,则反向代理到生产环境. 1 2 3 4 5 6 7 8 9 10

Nginx配置之负载均衡、限流、缓存、黑名单和灰度发布

一.Nginx安装(基于CentOS 6.5) 1.yum命令安装 yum install nginx –y(若不能安装,执行命令yum install epel-release) 2. 启动.停止和重启 service nginx startservice nginx stopservice nginx restart浏览器中 输入服务器的 ip 地址,即可看到相应信息 3. 其他信息 rpm -ql nginx 来查看安装路径yum remove nginx 来卸载 nginx -s rel

k8s实现灰度发布

灰度发布在实际生产部署中是经常被使用的方式,常规的方法是手动从前端LB(负载均衡)上将后端服务器摘掉,然后,停服务,最后上传代码,完成软连接更新.在使用CI/CD工具时,这个过程变得自动化了,我们只需要通过Jenkins这个功能强大的开源持续集成和部署工具,就可以联合Gitlab 或 Gogs 来实现自动拉取代码,并根据自己编写的pipeline脚本,实现自动连接到LB上摘掉后端Server,并自动连接到后端Server上,上传代码,并重启服务,最后通过邮件通知管理员整个过程的结果报告.但今天,

K8s Ingress Nginx 支持 Socket.io

Ingress 及 Ingress Controller 简介 Ingress:是k8s 资源对象,用于对外暴露服务,该资源对象定义了不同主机名(域名)及 URL 和对应后端 Service(k8s Service)的绑定,根据不同的路径路由 http 和 https 流量. Ingress Contoller:是一个pod服务,封装了一个Web前端负载均衡器,同时在其基础上实现了动态感知Ingress 并根据Ingress的定义动态生成前端web负载均衡器的配置文件,比如Nginx Ingre