Knative基于Header进行流量灰度验证

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 在 Knative 可以基于流量比例进行灰度发布,但有时候我们需要将确切的请求灰度到指定的版本上进行验证,在 Knative 0.18 版本并结合Kourier网关可以实现基于Header的灰度验证。

导读

在 Knative 可以基于流量比例进行灰度发布,但有时候我们需要将确切的请求灰度到指定的版本上进行验证,通常的做法是在请求的 Header 中设置参数,然后根据Header灰度到指定的版本。那么在Knative 除了基于流量比例灰度,是否还支持基于Header指定版本灰度呢? 答案是可以的。在 Knative 0.18 版本并结合Kourier网关可以实现基于Header的灰度验证。

Knative 中Tag的特性

在 Knative 中创建完成Knative Service 之后会默认生成该服务的访问域名(如:`helloworld.default.example.com`),通过该域名并依据每个Revision版本的流量比例,可以访问到不同的版本。那么如果我们想单独访问某个特定的版本,是否可以呢?Knative 提供了指定某个版本访问的能力,就是对这个版本配置一个Tag。

image.png

Service

Configuration

Route

Revision1

Revision2

Revision3

被打上Tag的Revision版本, 会为这个版本单独生成一个域名(如:test-helloworld.default.example.com),这样我们访问这个域名的话就可以直接访问特定的版本。

一般使用Tag的情况是对未进行线上引流的版本进行功能测试。但这个特性还满足不了实际指定版本灰度验证,因为线上提供服务访问的域名是固定的。因此Knative社区在Tag设置之上提供了设置Header路由策略。

Knative 基于Tag设置Header策略

在 Knative v0.18 版本中可以在请求的Header中加上 Knative-Serving-Tag: {revision-tag}

来指定请求到Tag对应的版本上。

当前 Istio, Contour 以及 Kourier 都已经支持了该特性。开启特性:

  • 阿里云 Knative 已经默认开启。
  • 社区 Knative 默认未开启,执行下面操作即可开启:
kubectl patch cm config-features -n knative-serving -p '{"data":{"tag-header-based-routing":"enabled"}}'

 

通过Header进行灰度验证

前提条件

阿里云 Knative 部署完成之后,当前默认使用Kourier网关。

创建服务

首先我们创建一个helloworld-go的服务,注意这里需要开启tag特性,在Service 的注释中设置:route.serving.knative.aliyun.com/revision-tag: "on"

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  annotations:
    route.serving.knative.aliyun.com/revision-tag: "on"
spec:
  template:
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

执行部署命令:

kubectl apply -f helloworld.yaml

查看版本信息:

kubectl get revision
NAME                  CONFIG NAME     K8S SERVICE NAME      GENERATION   READY   REASON
helloworld-go-k77jq   helloworld-go   helloworld-go-k77jq   1            True

访问服务:

richard@B-N3TEMD6P-1650 tag-route % curl -H "host: helloworld-go.default.example.com" http://39.106.114.214
Hello World!

升级服务

这里我们通过修改环境变量TARGET,打印不同的输出。同时设置新版本的流量为0,这样请求还是会100%到原版本。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  annotations:
    route.serving.knative.aliyun.com/revision-tag: "on"
spec:
  template:
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"
  traffic:
  - latestRevision: true
    percent: 0
  - latestRevision: false
    percent: 100
    revisionName: helloworld-go-k77jq

执行部署命令:

kubectl apply -f helloworld.yaml

查看新版本已经创建出来:

kubectl get revision
NAME                  CONFIG NAME     K8S SERVICE NAME      GENERATION   READY   REASON
helloworld-go-k77jq   helloworld-go   helloworld-go-k77jq   1            True
helloworld-go-zgklc   helloworld-go   helloworld-go-zgklc   2            True

访问服务:

curl -H "host: helloworld-go.default.example.com" http://39.106.114.214
Hello World!

还是原版本信息输出,符合预期。

设置新版本Tag

执行修改 Service 命令:

kubectl edit ksvc helloworld-go

在新版本上设置Tag (tag: demo)

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  annotations:
    route.serving.knative.aliyun.com/revision-tag: "on"
spec:
  template:
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"
  traffic:
  - latestRevision: false
    percent: 0
    revisionName: helloworld-go-zgklc
    tag: demo
  - latestRevision: false
    percent: 100
    revisionName: helloworld-go-k77jq

访问指定版本(helloworld-go-zgklc):

curl -H "host: demo-helloworld-go.default.example.com" http://39.106.114.214
Hello Knative!

 

灰度验证

接下来我们看一下基于Header如何灰度验证,很简单只需要在访问helloworld-go.default.example.com域名的时候加上Knative-Serving-Tag即可:

curl -H "host: helloworld-go.default.example.com" -H "Knative-Serving-Tag:demo"  http://39.106.114.214
Hello Knative!

总结

本文介绍了如何在 Knative 中通过在Header中设置Knative-Serving-Tag来实现灰度验证,有兴趣的同学可以体验一下,也欢迎加入 Knative 交流群一起交流:

image.png

目录
相关文章
|
6月前
在 Higress 中,您可以通过 EnvoyFilter 配置来修改请求中的 spanid
在 Higress 中,您可以通过 EnvoyFilter 配置来修改请求中的 spanid
56 1
|
6月前
|
Kubernetes Cloud Native 测试技术
使用ASM流量泳道的全链路灰度发布实践
服务网格ASM实现全链路灰度发布:通过流量泳道隔离不同版本环境,配置虚拟服务实现灰度比例控制。从创建泳道、打标签、部署新版本到灰度切流、最终上线及下线旧版。
|
弹性计算 Kubernetes 测试技术
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
|
负载均衡 测试技术 数据处理
阿里云服务网格ASM的流量标签及路由功能之(4): 基于ASM实现全链路灰度发布
当您需要在多个服务间实现全链路的灰度发布时,可以通过配置TrafficLabel来识别流量特征,将网关入口流量分为正常流量和灰度流量。灰度流量特征会在请求调用链经过的各个服务间进行传递,从而实现全链路灰度发布。本文介绍如何通过TrafficLabel能力来实现微服务的全链路灰度发布。
425 0
阿里云服务网格ASM的流量标签及路由功能之(4): 基于ASM实现全链路灰度发布
|
Kubernetes Cloud Native Dubbo
流控验证太麻烦?不敢上生产?MSE 有办法!
本文将给出基于微服务引擎(MSE)中的热点参数防护功能,小成本地在生产环境中验证流控的方案,进而可以在生产环境中实施流控。
流控验证太麻烦?不敢上生产?MSE 有办法!
|
Java 中间件 测试技术
全链路灰度新功能:MSE上线配置标签推送
微服务场景下,全链路灰度作为一种低成本的新功能验证方式,得到了越来越广泛的应用。除了微服务实例和流量的灰度,微服务应用中的配置项也应该具备相应的灰度能力,以应对灰度应用对特殊配置的诉求。
全链路灰度新功能:MSE上线配置标签推送
|
运维 Kubernetes Cloud Native
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布|学习笔记(一)
快速学习Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布|学习笔记(一)
|
运维 Kubernetes Cloud Native
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布|学习笔记(一)
快速学习 Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布|学习笔记(一)
|
6月前
|
Kubernetes API Nacos
基于Ingress-APISIX网关实现全链路灰度
本文介绍了通过将 APISIX 提供的灵活的路由能力以及 MSE 提供的全链路灰度能力结合,可以在不需要修改任何业务代码的情况下,轻松实现全链路灰度能力。
基于Ingress-APISIX网关实现全链路灰度
|
Cloud Native Java 中间件
全链路灰度新功能:MSE 上线配置标签推送
本文介绍了全链路灰度场景给配置管理带来的问题,介绍了 MSE 针对这一场景的解决方案,并通过实践的方式展示了配置标签推送的使用流程。后续,MSE 还会针对配置治理做更多的探索,帮助用户更好地解决微服务配置管理中的难题,提高微服务应用的稳定性。
全链路灰度新功能:MSE 上线配置标签推送