1. Toy模板网首页
  2. > Toy博客

K8S Nginx Ingress实现金丝雀发布

7月前 作者：summer_west_fish 分类：Toy博客 阅读(31) 违法举报

这篇具有很好参考价值的文章主要介绍了K8S Nginx Ingress实现金丝雀发布。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

通过给 Ingress 资源指定 Nginx Ingress 所支持的 annotation 可实现金丝雀发布。

需给服务创建2个 Ingress，其中1个常规 Ingress，另1个为带 nginx.ingress.kubernetes.io/canary: "true" 固定的 annotation 的 Ingress，称为 Canary Ingress。

Canary Ingress 一般代表新版本的服务，结合另外针对流量切分策略的 annotation 一起配置即可实现多种场景的金丝雀发布。

以下为相关 annotation 的详细介绍：

  • nginx.ingress.kubernetes.io/canary-by-header
    表示如果请求头中包含指定的 header 名称，并且值为 always，就将该请求转发给该 Ingress 定义的对应后端服务。如果值为 never 则不转发，可以用于回滚到旧版。如果为其他值则忽略该 annotation。

  • nginx.ingress.kubernetes.io/canary-by-header-value
    该 annotation 可以作为 canary-by-header 的补充，可指定请求头为自定义值，包含但不限于 always 或 never。当请求头的值命中指定的自定义值时，请求将会转发给该 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
    与 canary-by-header 类似，该 annotation 用于 cookie，仅支持 always 和 never。

  • nginx.ingress.kubernetes.io/canary-weight
    表示 Canary Ingress 所分配流量的比例的百分比，取值范围 [0-100]。例如，设置为10，则表示分配10%的流量给 Canary Ingress 对应的后端服务。

  • 金丝雀规则按优先顺序进行如下排序：canary-by-header - > canary-by-cookie - > canary-weight

基于不同的场景，灰度发布有四种：

//第一种，所有的请求都会被转发到灰度（Canary）版本
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "always"
 
//第二种，所有的请求都不会被转发到灰度（Canary）版本
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "never"
 
//第三种，如果请求的header头包含"user-id: user_1"，该请求会被转发到灰度（Canary）版本
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "user_id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "user_1"
 
//第四种，如果请求的header头包含"user-id: user_2"或"user-id: user-3"或"user-id: user4"，该请求会被转发到灰度（Canary）版
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "user_id"    #在networking.k8s.io/v1中，canary-by-header的值尽量不用使用下划线“_”。如果使用了，请求头中要使用中横线“-”代替。
    nginx.ingress.kubernetes.io/canary-by-header-pattern: "user_2|user-3|user4"

一、部署蓝环境版本服务

1、ConfigMap

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-blue-config
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("blue")
                ';
            }
        }
    }

2、Deployment

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx-blue
  labels:
    dce.daocloud.io/app: nginx-blue
  annotations:
    dce.daocloud.io/last-replicas: '1'
    deployment.kubernetes.io/revision: '3'
    kubernetes.io/change-cause: update YAML
spec:
  replicas: 1
  selector:
    matchLabels:
      dce.daocloud.io/component: nginx-blue
  template:
    metadata:
      name: nginx-blue
      labels:
        dce.daocloud.io/app: nginx-blue
        dce.daocloud.io/component: nginx-blue
      annotations:
        dce.daocloud.io/parcel.egress.burst: '0'
        dce.daocloud.io/parcel.egress.rate: '0'
        dce.daocloud.io/parcel.ingress.burst: '0'
        dce.daocloud.io/parcel.ingress.rate: '0'
        dce.daocloud.io/parcel.net.type: calico
    spec:
      volumes:
        - name: nginx-blue-config
          configMap:
            name: nginx-blue-config
            defaultMode: 420
      containers:
        - name: nginx-blue
          image: 'x.x.x.x/library/openresty:1.19.9.1-sw-r4'
          resources:
            limits:
              cpu: 500m
              memory: '314572800'
            requests:
              cpu: 200m
              memory: '314572800'
          volumeMounts:
            - name: nginx-blue-config
              mountPath: /etc/nginx/nginx.conf
              subPath: nginx.conf

3、Service

kind: Service
apiVersion: v1
metadata:
  name: nginx-blue-default
  labels:
    dce.daocloud.io/app: nginx-blue
  annotations:
    io.daocloud.dce.serviceSelectorType: service
spec:
  ports:
    - name: nginx-nginx-default-80680-80
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 31046
  selector:
    dce.daocloud.io/component: nginx-blue
  clusterIP: 172.31.69.137
  type: NodePort
  sessionAffinity: None
  externalTrafficPolicy: Cluster

4、修改pod内容

cd /usr/local/openresty/nginx/html/

ls
50x.html  index.html

echo "Hello Blue" > index.html

cat index.html 
Hello Blue

二、部署绿环境版本服务

1、ConfigMap

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-green-config
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("green")
                ';
            }
        }
    }

2、Deployment

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx-green
  labels:
    dce.daocloud.io/app: nginx-green
  annotations:
    deployment.kubernetes.io/revision: '5'
    kubernetes.io/change-cause: update YAML
spec:
  replicas: 1
  selector:
    matchLabels:
      dce.daocloud.io/component: nginx-green
  template:
    metadata:
      name: nginx-green
      labels:
        dce.daocloud.io/app: nginx-green
        dce.daocloud.io/component: nginx-green
        env: green
      annotations:
        dce.daocloud.io/parcel.egress.burst: '0'
        dce.daocloud.io/parcel.egress.rate: '0'
        dce.daocloud.io/parcel.ingress.burst: '0'
        dce.daocloud.io/parcel.ingress.rate: '0'
        dce.daocloud.io/parcel.net.type: calico
        dce.daocloud.io/parcel.net.value: default-ipv4-ippool
    spec:
      volumes:
        - name: nginx-green-config
          configMap:
            name: nginx-green-config
            defaultMode: 420
      containers:
        - name: nginx-green
          image: 'x.x.x.x/library/openresty:1.19.9.1-sw-r4'
          resources:
            limits:
              cpu: 500m
              memory: '314572800'
            requests:
              cpu: 200m
              memory: '314572800'
          volumeMounts:
            - name: nginx-green-config
              mountPath: /etc/nginx/nginx.conf
              subPath: nginx.conf

3、Service

kind: Service
apiVersion: v1
metadata:
  name: nginx-green-default
  labels:
    dce.daocloud.io/app: nginx-green
  annotations:
    io.daocloud.dce.serviceSelectorType: service
spec:
  ports:
    - name: nginx-nginx-default-15833-80
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 35218
  selector:
    dce.daocloud.io/component: nginx-green
  clusterIP: 172.31.207.22
  type: NodePort
  sessionAffinity: None
  externalTrafficPolicy: Cluster

 4、修改pod内容

cd /usr/local/openresty/nginx/html/

ls
50x.html  index.html

echo "Hello Green" > index.html

cat index.html 
Hello Green

三、设置Ingress

1、blue环境Ingress

kind: Ingress
apiVersion: networking.k8s.io/v1beta1
metadata:
  name: nginx-blue-ingress
  labels:
    dce.daocloud.io/app: nginx-blue
  annotations:
    nginx.ingress.kubernetes.io/use-port-in-redirects: 'true'
spec:
  rules:
    - host: nginx.ms-sit.xxxxxx.net
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              serviceName: nginx-blue-default
              servicePort: 80

2、green环境Ingress

案例1:

kind: Ingress
apiVersion: networking.k8s.io/v1beta1
metadata:
  name: nginx-green-ingress
  labels:
    dce.daocloud.io/app: nginx-green
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: 'true'
    nginx.ingress.kubernetes.io/canary-by-header: env
    nginx.ingress.kubernetes.io/canary-by-header-pattern: green
spec:
  rules:
    - host: nginx.ms-sit.xxxxxx.net
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              serviceName: nginx-green-default
              servicePort: 80

案例2:

kind: Ingress
apiVersion: networking.k8s.io/v1beta1
metadata:
  name: nginx-green-ingress  
ingress
  labels:
    dce.daocloud.io/app: nginx-green
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: 'true'
    nginx.ingress.kubernetes.io/canary-by-header: Cookie
    nginx.ingress.kubernetes.io/canary-by-header-pattern: bu=xxxcn|bu=xxxsg
spec:
  rules:
    - host: nginx.ms-sit.aswatson.net
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              serviceName: nginx-green-default
              servicePort: 80

四、测试

K8S Nginx Ingress实现金丝雀发布,K8S,kubernetes,nginx

案例1:

K8S Nginx Ingress实现金丝雀发布,K8S,kubernetes,nginx

案例2:

K8S Nginx Ingress实现金丝雀发布,K8S,kubernetes,nginx文章来源地址https://www.toymoban.com/news/detail-678666.html

到了这里，关于K8S Nginx Ingress实现金丝雀发布的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：
领支付宝红包 赞助服务器费用

相关文章

  • 微服务部署：金丝雀发布、蓝绿发布和滚动发布的对比

    金丝雀发布、蓝绿发布和滚动发布都是软件发布策略，它们都旨在降低发布风险并提高发布速度。但是，这三种策略在工作方式、优缺点等方面存在一些差异。 工作方式 金丝雀发布 ：将新版本软件逐步发布给用户，从一小部分用户开始，逐渐扩展到所有用户。 蓝绿发布 ：

    2024年02月19日
    浏览(32)
  • 1W字长文：蓝绿发布、金丝雀发布、滚动发布、A/B测试 原理和实操

    1W字长文：蓝绿发布、金丝雀发布、滚动发布、A/B测试 原理和实操

    蓝绿发布、金丝雀发布、滚动发布、A/B测试 ，是大家日常常见的发布工作。所以 发布的原理和实操 是一个 非常、非常核心的面试知识点 。 在40岁老架构师 尼恩的 读者交流群 (50+)中，其相关面试题是一个非常、非常高频的交流话题。 只要一面试，基本就会问： 对灰度发布

    2024年02月04日
    浏览(38)
  • 蓝/绿部署 VS 金丝雀部署

    蓝/绿部署 VS 金丝雀部署

    在生产环境中更新和配置应用程序通常是件令人望而生畏的事。面对如此多的可用选项，应如何选择最适合你的用例的部署策略？ 部署策略用于升级或配置正在运行的应用程序。在下文中，我们将讨论三种部署策略： 重建部署 ：在部署新版本之前，终止当前版本。 蓝/绿部

    2024年02月06日
    浏览(27)
  • 自动化金丝雀部署：Flagger全面解读webhook（含源码）

    自动化金丝雀部署：Flagger全面解读webhook（含源码）

    内容导读： 上文通过下面的配置就实现了 验收测试 和 压力测试 ，对此有以下疑问： metadata定义脚本和类型，说明接口能执行shell，那它是怎么实现的？ type未设置是怎样的执行逻辑？type有哪些值，各有什么作用？ 本文将通过源码来解答以上问题 本文采用 粗读 源码方式，

    2024年04月11日
    浏览(41)
  • k8s使用ingress实现应用的灰度发布升级

    k8s使用ingress实现应用的灰度发布升级

    v1是1.14.0版本nginx ,实操时候升级到v2是1.20.0版本nginx，来测试灰度发布实现过程 一、方案：使用ingress实现应用的灰度发布 1、服务端：正常版本v1，灰度升级版本v2 2、客户端：带有请求头version=v2标识的请求访问版本v2，其他的请求访问版本v1 3、待版本v2稳定后，所有请求切换

    2024年01月24日
    浏览(37)
  • k8s中部署nginx-ingress实现外部访问k8s集群内部服务

    k8s中部署nginx-ingress实现外部访问k8s集群内部服务

    k8s通过nginx-ingress实现集群外网访问功能 1.1 ingress 工作原理 step1：ingress contronler通过与k8s的api进行交互，动态的去感知k8s集群中ingress服务规则的变化，然后读取它，并按照定义的ingress规则，转发到k8s集群中对应的service。 step2：而这个ingress规则写明了哪个域名对应k8s集群中的

    2024年02月07日
    浏览(32)

  • Kubernetes(k8s)使用ingress发布服务

    目录 一.系统环境 二.前言 三.Kubernetes ingress简介 四.Ingress vs NodePort vs LoadBalancer 五.安装部署Nginx Ingress Controller控制器 六.使用Ingress来发布Kubernetes服务 6.1 创建3个pod 6.2 配置ingress规则发布服务 七.总结 本文主要基于Kubernetes1.21.9和Linux操作系统CentOS7.4。 服务器版本 Nginx Ingress C

    2024年02月08日
    浏览(38)
  • k8s部署ingress-nginx

    k8s部署ingress-nginx

    k8s服务对外暴露有三种方式 NodePort,LoadBalancer,Ingress Nodeport : 服务暴露需要在集群每个节点都开放一个同样的端口，通过 nodtIp:nodePort 来访问，如果服务数量多了，开放的端口就难以管理 LoadBalancer : 大部分情况下只适用于支持外部负载均衡器的云提供商（AWS,阿里云,华为云等）

    2024年02月04日
    浏览(29)

  • 关于k8s中ingress、Gateway、nginx之间关系

    在Kubernetes中，Ingress是一种用于将外部流量路由到集群内部服务的API对象。它通常与Ingress控制器一起使用，Ingress控制器负责根据Ingress规则路由外部流量到不同的服务上。 下面是使用Ingress的一些步骤： 安装Ingress控制器 在Kubernetes中，Ingress控制器是需要安装和配置的。有许多

    2024年02月09日
    浏览(27)
  • K8s的ingress-nginx配置https

    K8s的ingress-nginx配置https

    在另一台机器上配置hosts解析www.yaoyao.com，然后访问 curl --cacert tls.crt https://www.yaoyao.com:10443 这里的10443端口是ingress-nginx-controller服务暴露的nodeport端口

    2024年02月07日
    浏览(28)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包，优惠每天领

二维码1

领取红包

二维码2

领红包