学习笔记三十六：通过Ingress-nginx实现灰度发布

最新推荐文章于 2024-02-09 17:44:00 发布
最新推荐文章于 2024-02-09 17:44:00 发布
阅读量1.1k 收藏 17
点赞数 17
分类专栏： CKA学习笔记 文章标签： 学习 笔记 nginx
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43258559/article/details/134717256
版权

通过Ingress-nginx实现灰度发布

灰度发布原理

将新版本灰度给部分用户

  • 假设线上运行了一套对外提供 7 层服务的 Service A 服务，后来开发了个新版本 Service A’ 想要上线，但又不想直接替换掉原来的 Service A，希望先灰度一小部分用户，等运行一段时间足够稳定了再逐渐全量上线新版本，最后平滑下线旧版本。这个时候就可以利用 Nginx Ingress 基于 Header 或 Cookie 进行流量切分的策略来发布，业务使用 Header 或 Cookie 来标识不同类型的用户，我们通过配置 Ingress 来实现让带有指定 Header 或 Cookie 的请求被转发到新版本，其它的仍然转发到旧版本，从而实现将新版本灰度给部分用户:
    在这里插入图片描述

切一定比例的流量给新版本

  • 假设线上运行了一套对外提供 7 层服务的 Service B 服务，后来修复了一些问题，需要灰度上线一个新版本 Service B’，但又不想直接替换掉原来的 Service B，而是让先切 10% 的流量到新版本，等观察一段时间稳定后再逐渐加大新版本的流量比例直至完全替换旧版本，最后再滑下线旧版本，从而实现切一定比例的流量给新版本:
    在这里插入图片描述

部署两个版本的服务

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

  • 假设我们现在部署了两个版本的服务，老版本和canary版本
  • nginx.ingress.kubernetes.io/canary-by-header：基于Request Header的流量切分，适用于灰度发布以及 A/B 测试。当Request Header 设置为 always时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口。
  • nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。
  • nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为60意味着60%流量转到canary。权重为 100 意味着所有请求都将被发送到 Canary 入口。
  • nginx.ingress.kubernetes.io/canary-by-cookie：基于 Cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always时，它将被路由到 Canary 入口；当 cookie 值设置为 never时，请求不会被发送到 Canary 入口。

以 nginx 为例，先部署一个 v1 版本:

上传openresty.tar.gz至node节点
链接：https://pan.baidu.com/s/10BU9qNqiAjfQfb9ZyVh1cQ?pwd=6uaq
提取码：6uaq

ctr -n=k8s.io images import openresty.tar.gz
docker load -i  openresty.tar.gz

在master执行

vim v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
      version: v1
  template:
    metadata:
      labels:
        app: nginx
        version: v1
    spec:
      containers:
      - name: nginx
        image: "openresty/openresty:centos"
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          protocol: TCP
          containerPort: 80
        volumeMounts:
        - mountPath: /usr/local/openresty/nginx/conf/nginx.conf
          name: config
          subPath: nginx.conf
      volumes:
      - name: config
        configMap:
          name: nginx-v1
---
apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: nginx
    version: v1
  name: nginx-v1
data:
  nginx.conf: |-
    worker_processes  1;
    events {
        accept_mutex on;
        multi_accept on;
        use epoll;
        worker_connections  1024;
    }
    http {
        ignore_invalid_headers off;
        server {
            listen 80;
            location / {
                access_by_lua '
                    local header_str = ngx.say("nginx-v1")
                ';
            }
        }
    }
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-v1
spec:
  type: ClusterIP
  ports:
  - port: 80
    protocol: TCP
    name: http
  selector:
    app: nginx
    version: v1

kubectl apply -f v1.yaml

部署一个 v2 版本

vim v2.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
      version: v2
  template:
    metadata:
      labels:
        app: nginx
        version: v2
    spec:
      containers:
      - name: nginx
        image: "openresty/openresty:centos"
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          protocol: TCP
          containerPort: 80
        volumeMounts:
        - mountPath: /usr/local/openresty/nginx/conf/nginx.conf
          name: config
          subPath: nginx.conf
      volumes:
      - name: config
        configMap:
          name: nginx-v2
---
apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: nginx
    version: v2
  name: nginx-v2
data:
  nginx.conf: |-
    worker_processes  1;
    events {
        accept_mutex on;
        multi_accept on;
        use epoll;
        worker_connections  1024;
    }
    http {
        ignore_invalid_headers off;
        server {
            listen 80;
            location / {
                access_by_lua '
                    local header_str = ngx.say("nginx-v2")
                ';
            }
        }
    }
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-v2
spec:
  type: ClusterIP
  ports:
  - port: 80
    protocol: TCP
    name: http
  selector:
    app: nginx
    version: v2

kubectl apply -f v2.yaml

再创建一个 Ingress，对外暴露服务，指向 v1 版本的服务:

vim v1-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: canary.example.com
    http:
      paths:
      - path: /  #配置访问路径，如果通过url进行转发，需要修改；空默认为访问的路径为"/"
        pathType:  Prefix
        backend:  #配置后端服务
         service:
           name: nginx-v1
           port:
            number: 80

kubectl apply -f v1-ingress.yaml

访问验证

#curl -H "Host: canary.example.com" http://EXTERNAL-IP # EXTERNAL-IP 替换为 Nginx Ingress 自身对外暴露的 IP

curl -H "Host: canary.example.com" http://192.168.40.12

在这里插入图片描述

基于 Header 的流量切分：

创建 Canary Ingress，指定 v2 版本的后端服务，且加上一些 annotation，实现仅将带有名为 Region 且值为 cd 或 sz 的请求头的请求转发给当前 Canary Ingress，模拟灰度新版本给成都和深圳地域的用户:

vim v2-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "Region"
    nginx.ingress.kubernetes.io/canary-by-header-pattern: "cd|sz"
  name: nginx-canary
spec:
  rules:
  - host: canary.example.com
    http:
      paths:
      - path: /  #配置访问路径，如果通过url进行转发，需要修改；空默认为访问的路径为"/"
        pathType:  Prefix
        backend:  #配置后端服务
         service:
           name: nginx-v2
           port:
            number: 80

kubectl apply -f v2-ingress.yaml

测试访问

#curl -H "Host: canary.example.com" -H "Region: cd" http://EXTERNAL-IP # EXTERNAL-IP 替换为 Nginx Ingress 自身对外暴露的 IP

curl -H "Host: canary.example.com" -H "Region: cd" http://192.168.40.12

curl -H "Host: canary.example.com" -H "Region: bj" http://192.168.40.12

curl -H "Host: canary.example.com" -H "Region: cd" http://192.168.40.12

在这里插入图片描述

可以看到，只有 header Region 为 cd 或 sz 的请求才由 v2 版本服务响应。

基于 Cookie 的流量切分：

与前面 Header 类似，不过使用 Cookie 就无法自定义 value 了，这里以模拟灰度成都地域用户为例，仅将带有名为 user_from_cd 的 cookie 的请求转发给当前 Canary Ingress 。先删除前面基于 Header 的流量切分的 Canary Ingress，然后创建下面新的 Canary Ingress:

kubectl delete -f v2-ingress.yaml
vim v1-cookie.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "user_from_cd"
  name: nginx-canary
spec:
  rules:
  - host: canary.example.com
    http:
      paths:
      - path: /  #配置访问路径，如果通过url进行转发，需要修改；空默认为访问的路径为"/"
        pathType:  Prefix
        backend:  #配置后端服务
         service:
           name: nginx-v2
           port:
            number: 80

kubectl apply -f v1-cookie.yaml

测试访问:

#curl -s -H "Host: canary.example.com" --cookie "user_from_cd=always" http://EXTERNAL-IP # EXTERNAL-IP 替换为 Nginx Ingress 自身对外暴露的 IP

curl -s -H "Host: canary.example.com" --cookie "user_from_cd=always" http://192.168.40.12

curl -s -H "Host: canary.example.com" --cookie "user_from_bj=always" http://192.168.40.12

curl -s -H "Host: canary.example.com" http://192.168.40.12

在这里插入图片描述

可以看到，只有 cookie user_from_cd 为 always 的请求才由 v2 版本的服务响应。

基于服务权重的流量切分

基于服务权重的 Canary Ingress 就简单了，直接定义需要导入的流量比例，这里以导入 10% 流量到 v2 版本为例 (如果有，先删除之前的 Canary Ingress):

kubectl delete -f v1-cookie.yaml

vim v1-weight.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
  name: nginx-canary
spec:
  rules:
  - host: canary.example.com
    http:
      paths:
      - path: /  #配置访问路径，如果通过url进行转发，需要修改；空默认为访问的路径为"/"
        pathType:  Prefix
        backend:  #配置后端服务
         service:
           name: nginx-v2
           port:
            number: 80

kubectl apply -f v1-weight.yaml

测试访问:

#for i in {1..10}; do curl -H "Host: canary.example.com" http://EXTERNAL-IP; done;

for i in {1..10}; do curl -H "Host: canary.example.com" http://192.168.40.12; done;

在这里插入图片描述

可以看到，大概只有十分之一的几率由 v2 版本的服务响应，符合 10% 服务权重的设置

风车带走过往
关注
  • 17
    点赞
  • 踩
  • 17
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
基于 Nginx 实现一个灰度发布系统
xiangzhihong8的专栏
09-26 292
其实公司内部一般都有灰度配置系统，可以配置不同的版本的比例，然后流量经过这个系统之后，就会返回 Set-Cookie 的 header，里面按照比例来分别设置不同的 cookie。如果包含 version=1.0 的 cookie，那就走 version1.0_server 的服务，有 version=2.0 的 cookie 就走 version2.0_server 的服务，否则，走默认的。接下来的问题是，如何用 nginx 实现灰度，让一部分请求走一个版本的代码，一部分请求走另一个版本呢？
ingress-nginx-controller-1.9.yaml
10-18
《Ingress-Nginx控制器与应用部署详解》 在 Kubernetes 集群中，Ingress 是一种用于对外提供服务的资源对象，它定义了外部网络如何访问内部的 Service。Nginx Ingress 控制器是广泛应用的一种解决方案，通过配置 ...
高级运维学习（七）Nginx实现用IP测试灰度发布
2301_79227925的博客
09-01 915
uWSGI是一个Web服务器主要用途是将 Web应用程序部署到生产环境中可以用来连接Nginx服务与Python动态网站。灰度发布是使用比较平稳的过渡方式升级或者替换产品项目的方法统称，它的主要作用是可以及时发现项目问题并尽早获取用户反馈信息，以改进产品。如果项目产生问题，可以将问题影响控制到最小范围
Nginx Ingress实现灰度发布从理论到实战
力哥讲技术
04-18 1411
Ingress作为K8S集群中一种独立的组件，我们需要通过创建它来控制外部访问流量的策略，并通过Ingress Controller将其分配到一个或多个SVC中。K8S官方维护的Controller为Nginx Ingress，该Ingress支持通过配置注解（英文：annotations）的方式来实现蓝绿发布、灰度发布和A/B测试等场景。使用案例案例一：切分部分用户流量到新版本。
Nginx实现系统灰度发布
沛哥儿的专栏
01-28 1844
在系统发布的时候，经常会遇到要停机发布的情况。大家经常会在凌晨去发布系统。 这样导致开发和测试的同时都很辛苦。 那么有没有一种比较简单、成本相对可以接受的方式来进行发布呢？ 在这里，给大家推荐灰度发布的方式。 灰度发布的方式很多，最简单的操作方式是直接操作Nginx的upstream来进行灰度发布。 前提：至少两台服务器A和B。 在灰度发布前，可以使用Nginx的upstream的方式，先简单注释其中一个服务器A， 等A重新发布完成之后，再重新注释B，开启A。 等B发布完成之后，再把B也开启
基于Ingress Nginx实现灰度发布系统
weixin_44093727的博客
02-09 1480
介绍了基于Ingress Nginx实现灰度发布系统
ingress-nginx-controller（含镜像和代码）.rar
10-28
ingress-nginx-controller 是 Kubernetes 社区维护的一个项目，它提供了对 Ingress 资源的实现，使得可以通过定义简单的 YAML 文件来管理对外暴露的服务路由。Nginx 作为业界广泛使用的高性能反向代理服务器，其稳定...
ingress-nginx-controller-v1.2.0-images用到的镜像
12-27
ingress-nginx-controller-v1.2.0_daemonset用到的镜像，免费下载
ingress-nginx.tar离线安装包，适用k8s版本 1.25.x~1.28.x
最新发布
05-22
ingress-nginx.tar离线安装包，适用k8s版本 1.25.x~1.28.x
k8s-修改ingress-nginx-controller中nginx配置文件参数参考
07-20
k8s-修改ingress-nginx-controller中nginx配置文件参数参考
基于 Nginx 实现灰度发布与 AB 测试
JineD的博客
10-20 1313
背景 单位的云办公相关系统没有成熟的平滑发布方案，导致每一次发布都是直接发布，dll文件或配置文件的变更会引起站点的重启。 云办公系统的常驻用户有10000+，即使短短半分多钟，也会收到一堆投诉。基于此，我们梳理了一套平滑发布的方案。 实施方案 1、跟nginx代理服务器约定了一个健康检查的接口 2、通过接口返回的http状态码来让nginx决定是否分流用户请求（这个我们单位的技术部那边有标准的做法） 3、根据提供的这个服务健康检查的接口：nginx判断只要某个实例的接口返回5xx的状态码，..
基于 Nginx 实现一个灰度上线系统
chengbo_eva的博客
07-18 1049
基于 Nginx 实现一个灰度上线系统
灰度发布专题---3、Nginx+Lua灰度发布
u014526891的博客
11-28 1971
上一章已经讲解了配置文件灰度发布、应用版本灰度发布、API网关灰度发布实现，但如果用户这时候在代理层如何做灰度发布呢？
Web服务不停机更新和灰度发布方案
Honins的博客
03-26 2924
文章目录Web服务不停机更新和灰度发布方案当前情况方案一 负载均衡：问题:方案二 灰度发布：用IF指令实现根据来源ip做判断根据cookie做判断使用lua写脚本实现使用nginx+lua实现web项目的灰度发布 Web服务不停机更新和灰度发布方案 当前情况 Web服务需要改造成使用jwt登陆访问。因此可以使用nginx进行不停机更新。 方案一 负载均衡： 将新版本另起一个端口，nginx中配置负载均衡，并反向代理到新旧两个服务。若新服务功能正常，则可关闭旧版本，只使用新版本。 配置如图： http {
【干货】基于 Nginx 实现一个灰度上线系统
小生方勤
08-07 476
软件开发一般不会上来就是最终版本，而是会一个版本一个版本的迭代。新版本上线前都会经过测试，但就算这样，也不能保证上线了不出问题。所以，在公司里上线新版本代码一般都是通过灰度系统。灰度系统可以把流量划分成多份，一份走新版本代码，一份走老版本代码。而且灰度系统支持设置流量的比例，比如可以把走新版本代码的流量设置为 5%，没啥问题再放到 10%，50%，最后放到 100% 全量。这样可以把出现问题的影响...
如何在 Kubernetes 中借助Ingress 实现灰度发布和蓝绿发布
三劫散仙
08-24 606
部署在 Kubernetes 集群中的应用，在升级发布时可能会存在的问题：1，由于 Kuberneter 底层 Pod 容器生命周期与网络组件生命周期是异步管理的，在升级时如果没有处理好应用优雅退出的问题，就很容易导致 http 访问请求 5xx2，原生 Deployment 应用的滚动发布功能是一把梭的全量发布模式，没有灰度和分批控制发布的概念，一旦出现问题，故障影响范围就会迅速扩大。
【Kubernetes运维篇】ingress-nginx实现业务灰度发布详解
秦子腾
07-25 2557
这个时候就可以利用 Nginx Ingress 基于 Header 或 Cookie 进行流量切分的策略来发布，业务使用 Header 或 Cookie 来标识不同类型的用户，我们通过配置 Ingress 来实现让带有指定 Header 或 Cookie 的请求被转发到新版本，其它的仍然转发到旧版本，从而实现将新版本灰度给部分用户。：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。
Ingress-nginx灰度发布功能详解
u012516914的专栏
08-04 2054
灰度发布使用背景 最近公司一直在推进DevOps，主要目标是减少对个人的依赖，降低团队之间的损耗，在保证质量的前提下，快速交付价值。在实际执行过程中表现出来的就是服务拆分粒度尽可能细，服...
nginx-ingress 的灰度发布
lswzw的博客
12-27 1546
nginx-ingress 的灰度发布 基于Request Header的流量切分 nginx.ingress.kubernetes.io/canary-by-header：用于通知Ingress将请求路由到Canary Ingress中指定的服务的标头。当请求标头设置always为时，它将被路由到Canary。当标头设置never为时，它将永远不会被路由到Canary。对于任何其他值，将忽略标头...
apiVersion: v1 kind: Service metadata: labels: app.kubernetes.io/component: controller app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx app.kubernetes.io/version: 1.6.4 name: ingress-nginx-controller namespace: ingress-nginx spec: externalTrafficPolicy: Local ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - appProtocol: http name: http port: 80 protocol: TCP targetPort: http - appProtocol: https name: https port: 443 protocol: TCP targetPort: https selector: app.kubernetes.io/component: controller app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/name: ingress-nginx type: NodePort 指定targetPort
06-06
在上述配置中，targetPort 是用来指定 Service 要代理的后端 Pod 的端口号。在这个例子中，Service 会将请求代理到后端 Pod...这里的 targetPort 要与后端 Pod 中监听的端口一致，如果不一致，请求就无法到达后端 Pod。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值