通过阿里云容器服务K8S Ingress Controller实现应用服务的灰度发布

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 日常工作中我们经常需要对服务进行版本更新升级,为此我们经常使用到的发布方式有滚动升级、分批暂停发布、蓝绿发布以及灰度发布,今天主要跟大家分享下在阿里云容器服务Kubernetes集群中如何通过Ingress Controller来实现应用服务的灰度发布及AB测试。

简介

日常工作中我们经常需要对服务进行版本更新升级,为此我们经常使用到的发布方式有滚动升级、分批暂停发布、蓝绿发布以及灰度发布,今天主要跟大家分享下在阿里云容器服务Kubernetes集群中如何通过Ingress Controller来实现应用服务的灰度发布及AB测试。

发布场景

场景一

假设当前线上环境我们已经有一套服务Service A对外提供7层服务,此时我们新开发了一些新的特性,需要灰度发布上线一个新的版本Service A',但是我们暂时又不希望简单地直接替换掉Service A服务,而是希望将请求头中包含foo=bar或者cookie中包含foo=bar的客户端请求转发到Service A'服务中,待运行一段时间稳定,将所有的流量切换到Service A'服务中后,再平滑地下线掉Service A服务:

image

场景二

假设当前线上环境我们已经有一套服务Service B对外提供7层服务,此时我们修复了一些问题,需要灰度发布上线一个新的版本Service B',但是我们又不希望简单直接地将所有客户端流量切换到新版本Service B'中,而是希望仅仅切换20%的流量到新版本Service B'中,待运行一段时间稳定,将所有的流量切换到Service B'服务中后,再平滑地下线掉Service B服务:

image

针对以上多种不同的应用发布需求,阿里云容器服务K8S Ingress Controller支持了多种流量切分方式:

  1. 基于Request Header的流量切分,适用于灰度发布以及AB测试场景
  2. 基于Cookie的流量切分,适用于灰度发布以及AB测试场景
  3. 基于Query Param的流量切分,适用于灰度发布以及AB测试场景
  4. 基于服务权重的流量切分,适用于蓝绿发布场景

注解说明

阿里云容器服务K8S Ingress Controller通过下列Annotation来支持应用服务的灰度发布机制:

1. nginx.ingress.kubernetes.io/service-match

该注解用来配置新版本服务的路由匹配规则,格式如下:

nginx.ingress.kubernetes.io/service-match: | 
    <service-name>: <match-rule>
# 参数说明:
# service-name:服务名称,满足match-rule的请求会被路由到该服务中
# match-rule:路由匹配规则
#
# 路由匹配规则:
# 1. 支持的匹配类型
# - header:基于请求头,支持正则匹配和完整匹配
# - cookie:基于cookie,支持正则匹配和完整匹配
# - query:基于请求参数,支持正则匹配和完整匹配
#
# 2. 匹配方式
# - 正则匹配格式:/{regular expression}/,//表明采用正则方式匹配
# - 完整匹配格式:"{exact expression}",""表明采用完整方式匹配

路由匹配规则配置示例:

# 请求头中满足foo正则匹配^bar$的请求被转发到新版本服务new-nginx中
new-nginx: header("foo", /^bar$/)

# 请求头中满足foo完整匹配bar的请求被转发到新版本服务new-nginx中
new-nginx: header("foo", "bar")

# cookie中满足foo正则匹配^sticky-.+$的请求被转发到新版本服务new-nginx中
new-nginx: cookie("foo", /^sticky-.+$/)

# query param中满足foo完整匹配bar的请求被转发到新版本服务new-nginx中
new-nginx: query("foo", "bar")
2. nginx.ingress.kubernetes.io/service-weight

该注解用来配置新旧版本服务的流量权重,格式如下:

nginx.ingress.kubernetes.io/service-weight: | 
    <new-svc-name>:<new-svc-weight>, <old-svc-name>:<old-svc-weight>
参数说明:
new-svc-name:新版本服务名称
new-svc-weight:新版本服务权重
old-svc-name:旧版本服务名称
old-svc-weight:旧版本服务权重

服务权重配置示例:

nginx.ingress.kubernetes.io/service-weight: | 
    new-nginx: 20, old-nginx: 60

注意

  1. 服务权重采用相对值计算方式。如示例中的服务权重设置,new-nginx服务的权重百分比为25%,old-nginx服务的权重百分比为75%。
  2. 一个服务组(同一个ingress yaml中具有相同Host和Path的服务)中未明确设置权重的服务默认权重值为100。

版本更新

目前阿里云容器服务K8S Ingress Controller需要0.12.0-5及其以上版本才支持流量切分特性,可以通过下面命令来查看Ingress Controller的当前版本号:

  1. 采用Deployment部署的情况
 kubectl -n kube-system get deploy nginx-ingress-controller -o yaml | grep -v 'apiVersion' | grep 'aliyun-ingress-controller'
  1. 采用DaemonSet部署的情况
 kubectl -n kube-system get ds nginx-ingress-controller -o yaml | grep -v 'apiVersion' | grep 'aliyun-ingress-controller'

若您的集群内Ingress Controller当前版本号小于0.12.0-5,那么您可以通过下面方式来升级Ingress Controller到新版本:

  1. 采用Deployment部署的情况
 kubectl -n kube-system set image deploy/nginx-ingress-controller nginx-ingress-controller=registry.cn-hangzhou.aliyuncs.com/acs/aliyun-ingress-controller:0.12.0-5
  1. 采用DaemonSet部署的情况
 kubectl -n kube-system set image ds/nginx-ingress-controller nginx-ingress-controller=registry.cn-hangzhou.aliyuncs.com/acs/aliyun-ingress-controller:0.12.0-5

至此,您集群内的Ingress Controller已经支持灰度发布功能。

部署服务

在应用灰度发布前,我们必须事先已经存在一套现有的应用对外提供服务。这里我们部署一套nginx服务并通过Ingress Controller对外提供7层域名访问:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: old-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      run: old-nginx
  template:
    metadata:
      labels:
        run: old-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/xianlu/old-nginx
        imagePullPolicy: Always
        name: old-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: old-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: old-nginx
  sessionAffinity: None
  type: NodePort

部署ingress资源:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 老版本服务
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80

部署并测试访问情况:

 kubectl get ing
NAME           HOSTS             ADDRESS        PORTS     AGE
gray-release   www.example.com   47.107.20.35   80        1m
 curl -H "Host: www.example.com"  http://47.107.20.35
old
 curl -H "Host: www.example.com"  http://47.107.20.35
old
 curl -H "Host: www.example.com"  http://47.107.20.35
old

灰度发布新版本服务

此时我们需要发布一个新版本的nginx服务并配置仅允许部分客户端才能访问到这个新版本服务:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: new-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: new-nginx
  template:
    metadata:
      labels:
        run: new-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/xianlu/new-nginx
        imagePullPolicy: Always
        name: new-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: new-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: new-nginx
  sessionAffinity: None
  type: NodePort
场景一:设置满足特定规则的客户端才能访问新版本服务

假若我们希望请求头中满足foo=bar的客户端请求才能路由到新版本服务中,那么我们可以如下修改配置ingress规则:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # 请求头中满足正则匹配foo=bar的请求才会被路由到新版本服务new-nginx中
    nginx.ingress.kubernetes.io/service-match: | 
      new-nginx: header("foo", /^bar$/)
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 老版本服务
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # 新版本服务
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

测试客户端请求:

 curl -H "Host: www.example.com"  http://47.107.20.35
old
 curl -H "Host: www.example.com"  http://47.107.20.35
old
 curl -H "Host: www.example.com"  http://47.107.20.35
old
 curl -H "Host: www.example.com" -H "foo: bar" http://47.107.20.35
new
 curl -H "Host: www.example.com" -H "foo: bar" http://47.107.20.35
new
 curl -H "Host: www.example.com" -H "foo: bar" http://47.107.20.35
new
场景二:在满足特定规则的基础上设置一定比例的请求被路由到新版本服务中

假若我们希望请求头中满足foo=bar的客户端请求仅允许50%的流量被路由到新版本服务中,那么我们可以如下修改配置ingress规则:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # 请求头中满足正则匹配foo=bar的请求才会被路由到新版本服务new-nginx中
    nginx.ingress.kubernetes.io/service-match: |
        new-nginx: header("foo", /^bar$/)
    # 在满足上述匹配规则的基础上仅允许50%的流量会被路由到新版本服务new-nginx中
    nginx.ingress.kubernetes.io/service-weight: |
        new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 老版本服务
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # 新版本服务
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

测试客户端请求:

 curl -H "Host: www.example.com" http://47.107.20.35
old
 curl -H "Host: www.example.com" http://47.107.20.35
old
 curl -H "Host: www.example.com" http://47.107.20.35
old
 curl -H "Host: www.example.com" -H "foo: bar" http://47.107.20.35
new
 curl -H "Host: www.example.com" -H "foo: bar" http://47.107.20.35
old
 curl -H "Host: www.example.com" -H "foo: bar" http://47.107.20.35
old
 curl -H "Host: www.example.com" -H "foo: bar" http://47.107.20.35
new
场景三:仅设置一定比例的请求被路由到新版本服务中

假若我们仅仅希望50%的流量被路由到新版本服务中,那么我们可以如下修改配置ingress规则:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
      # 允许50%的流量被路由到新版本服务new-nginx中
      nginx.ingress.kubernetes.io/service-weight: |
          new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 老版本服务
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # 新版本服务
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

测试客户端访问:

 curl -H "Host: www.example.com" http://47.107.20.35
new
 curl -H "Host: www.example.com" http://47.107.20.35
new
 curl -H "Host: www.example.com" http://47.107.20.35
new
 curl -H "Host: www.example.com" http://47.107.20.35
old
 curl -H "Host: www.example.com" http://47.107.20.35
old
 curl -H "Host: www.example.com" http://47.107.20.35
new
 curl -H "Host: www.example.com" http://47.107.20.35
old

特别说明:当我们既没有设置service-match也没有设置service-weight注解时,Ingress Controller在转发请求时默认会将请求均衡地随机转发到新老版本服务中。

灰度发布完成

系统运行一段时间后,当新版本服务已经稳定并且符合预期后,我们需要将老版本的服务下线掉,仅仅保留新版本服务在线上运行,此时我们需要修改ingress规则删除相关的annotation以及老版本服务,最终规则如下:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 新版本服务
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

测试客户端访问:

 curl -H "Host: www.example.com" http://47.107.20.35
new
 curl -H "Host: www.example.com" http://47.107.20.35
new
 curl -H "Host: www.example.com" http://47.107.20.35
new

可以看到,现在的请求是全部被路由到了新版本的服务中,这就完成了灰度发布的整个周期。最后,您可以删除老版本的service和deployment。

相关实践学习
巧用云服务器ECS制作节日贺卡
本场景带您体验如何在一台CentOS 7操作系统的ECS实例上,通过搭建web服务器,上传源码到web容器,制作节日贺卡网页。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
5天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
22 2
|
15天前
|
Kubernetes 监控 开发者
掌握容器化:Docker与Kubernetes的最佳实践
【10月更文挑战第26天】本文深入探讨了Docker和Kubernetes的最佳实践,涵盖Dockerfile优化、数据卷管理、网络配置、Pod设计、服务发现与负载均衡、声明式更新等内容。同时介绍了容器化现有应用、自动化部署、监控与日志等开发技巧,以及Docker Compose和Helm等实用工具。旨在帮助开发者提高开发效率和系统稳定性,构建现代、高效、可扩展的应用。
|
7天前
|
存储 Kubernetes Docker
【赵渝强老师】Kubernetes中Pod的基础容器
Pod 是 Kubernetes 中的基本单位,代表集群上运行的一个进程。它由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。基础容器负责维护 Pod 的网络空间,对用户透明。文中附有图片和视频讲解,详细介绍了 Pod 的组成结构及其在网络配置中的作用。
【赵渝强老师】Kubernetes中Pod的基础容器
|
4天前
|
存储 Kubernetes 网络协议
k8s的无头服务
Headless Service 是一种特殊的 Kubernetes 服务,其 `spec:clusterIP` 设置为 `None`,不会分配 ClusterIP,通过 DNS 解析提供服务发现。与普通服务不同,Headless Service 不提供负载均衡功能,每个 Pod 都有唯一的 DNS 记录,直接映射到其 IP 地址,适用于有状态应用的场景,如与 StatefulSet 一起部署数据库。示例中通过创建 Nginx 的 StatefulSet 和 Headless Service,展示了如何直接访问单个 Pod 并进行内容修改。
15 3
|
7天前
|
运维 Kubernetes Shell
【赵渝强老师】K8s中Pod的临时容器
Pod 是 Kubernetes 中的基本调度单位,由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。临时容器用于故障排查和性能诊断,不适用于构建应用程序。当 Pod 中的容器异常退出或容器镜像不包含调试工具时,临时容器非常有用。文中通过示例展示了如何使用 `kubectl debug` 命令创建临时容器进行调试。
|
7天前
|
Kubernetes 调度 容器
【赵渝强老师】K8s中Pod中的业务容器
Pod 是 Kubernetes 中的基本调度单元,由一个或多个容器组成。除了业务容器,Pod 还包括基础容器、初始化容器和临时容器。本文通过示例介绍如何创建包含业务容器的 Pod,并提供了一个视频讲解。示例中创建了一个名为 &quot;busybox-container&quot; 的业务容器,并使用 `kubectl create -f firstpod.yaml` 命令部署 Pod。
|
7天前
|
Kubernetes 容器 Perl
【赵渝强老师】K8s中Pod中的初始化容器
Kubernetes的Pod包含业务容器、基础容器、初始化容器和临时容器。初始化容器在业务容器前运行,用于执行必要的初始化任务。本文介绍了初始化容器的作用、配置方法及优势,并提供了一个示例。
|
15天前
|
Kubernetes 负载均衡 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第27天】Kubernetes(简称K8s)是云原生应用的核心容器编排平台,提供自动化、扩展和管理容器化应用的能力。本文介绍Kubernetes的基本概念、安装配置、核心组件(如Pod和Deployment)、服务发现与负载均衡、网络配置及安全性挑战,帮助读者理解和实践Kubernetes在容器编排中的应用。
47 4
|
16天前
|
Kubernetes 监控 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第26天】随着云计算技术的发展,容器化成为现代应用部署的核心趋势。Kubernetes(K8s)作为容器编排领域的佼佼者,以其强大的可扩展性和自动化能力,为开发者提供了高效管理和部署容器化应用的平台。本文将详细介绍Kubernetes的基本概念、核心组件、实践过程及面临的挑战,帮助读者更好地理解和应用这一技术。
48 3
|
17天前
|
存储 运维 Kubernetes
云端迁移:备份中心助力企业跨云迁移K8s容器服务平台
本文将简要介绍阿里云容器服务ACK的备份中心,并以某科技公司在其实际的迁移过程中遇到具体挑战为例,阐述如何有效地利用备份中心来助力企业的容器服务平台迁移项目。

相关产品

  • 容器计算服务
  • 容器服务Kubernetes版