构建基于 Ingress 的全链路灰度能力

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 随着云原生技术不断普及,越来越多的业务应用开始向云原生架构转变,微服务架构下,有一些需求开发,涉及到微服务调用链路上的多个微服务同时发生了改动,通常每个微服务都会有灰度环境或分组来接受灰度流量,我们希望通过进入上游灰度环境的流量,也能进入下游灰度的环境中,确保1个请求始终在灰度环境中传递,即使这个调用链路上有一些微服务没有灰度环境,这些应用请求下游的时候依然能够回到灰度环境中。通过 MSE 提供的全链路灰度能力,可以在不需要修改任何您的业务代码的情况下,能够轻松实现能力。

背景

随着云原生技术不断普及,越来越多的业务应用开始向云原生架构转变,借助容器管理平台 Kubernetes 的不可变基础设施、弹性扩缩容和高扩展性,助力业务迅速完成数字化转型。其中,集群入口流量管理方式在云原生技术演进过程中逐步通用化、标准化,用户通过 Kubernetes 定义的 Ingress 资源来管理外部访问集群内部服务的方式。

微服务架构下,有一些需求开发,涉及到微服务调用链路上的多个微服务同时发生了改动,通常每个微服务都会有灰度环境或分组来接受灰度流量,我们希望通过进入上游灰度环境的流量,也能进入下游灰度的环境中,确保1个请求始终在灰度环境中传递,即使这个调用链路上有一些微服务没有灰度环境,这些应用请求下游的时候依然能够回到灰度环境中。通过 MSE 提供的全链路灰度能力,可以在不需要修改任何您的业务代码的情况下,能够轻松实现上述能力。


Kubernetes 网关概述

Kubernetes 集群对外暴露流量的方式主要分为三种,Node Port、LoadBalancer 以及 Ingress。


对于 Node Port 而言,实现了朴素的端口和后端 Pod 的一一对应,不仅存在单点问题,而且由于端口范围的限制,一旦后端的服务数量上升,会出现无端口可用的情况;而对于 LoadBalancer 来说,其解决 Node Port 的单点问题和端口数量的问题,奈何它是一个纯粹的流量转发资源,并没有路由配置能力,也无法管理后端众多的 Service 应用,所以 Ingress 的诞生就是必然的结果。Ingress 不仅有着天然的路由定义的能力,也扮演者后端众多 Service 管理者的角色。不过这里需要提一句,大众所熟知的 Ingress 资源只是单纯的一个 路由 Resource 定义,真正的实现者和执行者其实是具体的 Ingress 标准实现,包括大家所熟知的 Nginx Ingress Controller 都属于此列。


image.png


在阿里云 ACK 平台上,有着众多 Ingress 的实现方式,其中包括 Nginx-Ingress 、ALB-Ingress 以及最近推出的 MSE-Ingress,本文将讲述一种较为通用的基于 MSE 微服务治理的统一方案,在 Ingress 网关上实现全链路流量灰度。


如何实现在 Ingress 上实现全链路流量灰度


首先我们要知道在实现全链路灰度时所必须具备的要素,然后再在 Ingress 环境中实现这些要素,就能够实现在 Ingress 网关下的全链路流量灰度。由历史经验可知,我们这里主要靠标签路由、节点打标以及流量染色这三个要素去实现。


标签路由通过对服务下所有节点按照标签名和标签值不同进行分组,使得订阅该服务节点信息的服务消费端可以按需访问该服务的某个分组,即所有节点的一个子集。服务消费端可以使用服务提供者节点上的任何标签信息,根据所选标签的实际含义,消费端可以将标签路由应用到更多的业务场景中。


节点打标,如果是在使用Kubernetes Service作为服务发现的业务系统中,服务提供者通过向ApiServer提交Service资源完成服务暴露,服务消费端监听与该Service资源下关联的Endpoint资源,从Endpoint资源中获取关联的业务Pod资源,读取上面的Labels数据并作为该节点的元数据信息。所以,我们只要在业务应用描述资源Deployment中的Pod模板中为节点添加标签即可。


image.png


流量染色是指我们可以在请求的源头上对流量进行染色,前端在发起请求时根据用户信息或者平台信息的不同对流量进行打标。如果前端无法做到,我们也可以在微服务网关上对匹配特定路由规则的请求动态添加流量标识。此外,流量在链路中流经灰度节点时,如果请求信息中不含有灰度标识,需要自动为其染色,接下来流量就可以在后续的流转过程中优先访问服务的灰度版本。


为了实现上面全链路灰度三个要素,MSE 微服务治理提出了泳道和泳道组的概念。举一个例子,我们假设应用的架构由 Nginx-Ingress 以及后端的微服务架构(Spring Cloud)来组成,后端调用链路有3跳,交易中心,商品中心,库存中心,客户端通过客户端或者是 H5 页面来访问后端服务,它们通过 Nacos 注册中心做服务发现。


image.png


1) 通过设置流量规则对所需流量进行'染色','染色'流量会路由到灰度机器。

2) 灰度流量携带灰度标往下游传递,形成灰度专属环境流量泳道,无灰度环境应用会默认选择未打标的基线环境。

进入到 MSE 控制台的泳道的定义界面里,我们也可以发现,其对应了全链路灰度实现的三要素:

image.png


快速玩转 Ingress 全链路灰度


我们以 ACK Nginx-Ingress 全链路为例,快速地体验如何借助 MSE 微服务治理,实现 Ingress 的全链路流量灰度,总体的步骤如下:


image.png

我们主要描述下如何将 ACK Ingress Controller 接入到 MSE 微服务中去,只需在 Nginx Ingress Controller 的 ConfigMap 增加下面两项配置即可:

  • use-mse: true
  • mse-app-name: ingress-canary-test


mse-app-name 为自定义的名称,此时我们就可以在 MSE 控制台上看到名为 ingress-canary-test 的阿里云 Ingress 入口了:


image.png


其余步骤均和 Java 应用的全链路灰度步骤一致,具体可以参考以下这篇文章:

https://help.aliyun.com/document_detail/460275.html


待我们配置好泳道规则后,我们打对应特征的流量就会流入的对应的泳道中去,我们可以在 MSE 控制台观察灰度的情况,以便验证全链路灰度功能是不是生效了:

image.png

MSE Ingress 是 MSE 团队自主研发的 Ingress 实现,基于 MSE 云原生网关(同时兼容 Ingress 和 Istio)取代 Nginx 来实现流量托管,不仅有着更强大的性能,也有着天然的流量治理与管控基因,其全链路灰度的玩法与 ACK Nginx Ingress 基本上一致,具体步骤可以参考以下这篇文章:

https://help.aliyun.com/document_detail/460375.html

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
1月前
|
自然语言处理 Cloud Native 安全
适应多样化需求:WASM 插件在全链路灰度发布中的应用
MSE(微服务引擎)在微服务全链路灰度场景下提供了一套成熟的功能,支持内容规则和百分比规则的灰度路由策略。
61541 7
|
6月前
|
Kubernetes 测试技术 微服务
Kruise Rollout 全链路灰度实践
OpenKruise 是一个基于 Kubernetes 的扩展套件,主要聚焦于云原生应用的自动化,比如部署、发布、运维以及可用性防护。本文介绍通过 OpenKruise 构建自动化运维的方式实现基于 Istio 的全链路灰度功能。
|
6月前
|
Cloud Native 前端开发 测试技术
MSE微服务引擎中我想实现灰度发布,怎么来实现灰度发布流量控制
MSE微服务引擎中我想实现灰度发布,怎么来实现灰度发布流量控制?
63 1
|
8月前
|
Cloud Native 测试技术 开发工具
通过 OpenKruise 实现基于 Higress 的全链路灰度
通过 OpenKruise 实现基于 Higress 的全链路灰度
|
9月前
|
Kubernetes 负载均衡 安全
【服务网格】最佳实践在哪里-1:全链路灰度
作为完全兼容社区Istio的服务网格产品,服务网格ASM针对全链路灰度场景提出了自己的思考,并针对性地设计了对应的流量标签方案,来解决上述全链路灰度实现方案中的痛点问题。
|
3天前
|
Java Go 数据库
OpenSergo/MSE & CloudWeGo 共同保障微服务运行时流量稳定性
微服务运行时稳定性的问题微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化,服务之间的依赖关系变得越来越复杂,业务系统也面临着巨大的高可用挑战。大家可能都经历过以下的场景:演唱会抢票瞬间洪峰流量导致系统超出最大负载,load 飙高,用户无法正常下单;在线选...
OpenSergo/MSE & CloudWeGo 共同保障微服务运行时流量稳定性
|
消息中间件 设计模式 运维
从三万英尺看全链路灰度
从本期开始,我们将通过《全链路灰度:自顶向下的方法》的系列文章,本期为《从三万英尺看全链路灰度》:介绍微服务的基础概念、主流的部署模式。
从三万英尺看全链路灰度
|
Kubernetes Cloud Native 前端开发
构建基于 Ingress 的全链路灰度能力
微服务架构下,有一些需求开发,涉及到微服务调用链路上的多个微服务同时发生了改动,通常每个微服务都会有灰度环境或分组来接受灰度流量,我们希望通过进入上游灰度环境的流量,也能进入下游灰度的环境中,确保1个请求始终在灰度环境中传递,即使这个调用链路上有一些微服务没有灰度环境,这些应用请求下游的时候依然能够回到灰度环境中。通过 MSE 提供的全链路灰度能力,可以在不需要修改任何您的业务代码的情况下,能够轻松实现上述能力。
构建基于 Ingress 的全链路灰度能力
|
3天前
|
移动开发 Kubernetes 测试技术
MSE服务治理最佳实践:基于Ingress-nginx网关实现全链路灰度
微服务架构下,有一些需求开发涉及到微服务调用链路上的多个微服务同时改动。通常每个微服务都会有灰度环境或分组来接受灰度流量。我们希望进入上游灰度环境的流量也能进入下游灰度的环境中,确保1个请求始终在灰度环境中传递。即使这个调用链路上有一些微服务应用不存在灰度环境,那么这些微服务应用在请求下游应用的时候依然能够回到下游应用的灰度环境中。我们通过 MSE 提供的全链路灰度能力,可以在不需要修改任何业务代码的情况下,轻松实现上述所说的全链路灰度能力。
|
运维 Cloud Native Dubbo
微服务全链路灰度新能力
微服务体系架构中,服务之间的依赖关系错综复杂,有时某个功能发版依赖多个服务同时升级上线。我们希望可以对这些服务的新版本同时进行小流量灰度验证,这就是微服务架构中特有的全链路灰度场景,通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。
微服务全链路灰度新能力