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

本文涉及的产品
容器镜像服务 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

相关实践学习
基于函数计算快速搭建Hexo博客系统
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
目录
相关文章
|
6月前
|
Kubernetes 测试技术 应用服务中间件
k8s七层代理Ingress-nginx基于cookie、请求头、权重实现灰度发布
k8s七层代理Ingress-nginx基于cookie、请求头、权重实现灰度发布
|
3月前
|
Kubernetes Cloud Native 测试技术
使用ASM流量泳道的全链路灰度发布实践
服务网格ASM实现全链路灰度发布:通过流量泳道隔离不同版本环境,配置虚拟服务实现灰度比例控制。从创建泳道、打标签、部署新版本到灰度切流、最终上线及下线旧版。
|
9月前
|
Kubernetes JavaScript API
如何理解 Istio Ingress, 它与 API Gateway 有什么区别?东西流量?南北流量?
这三者都和流量治理密切相关,那么流量治理在过去和现在有什么区别呢?都是如何做的呢? 在学习istio的时候对流量管理加深了理解。什么是东西流量?什么是南北流量?
185 0
|
6月前
|
监控 Cloud Native 安全
使用Linkerd实现流量管理:学习如何使用Linkerd的路由规则来实现流量的动态控制
使用Linkerd实现流量管理:学习如何使用Linkerd的路由规则来实现流量的动态控制
44 0
|
7月前
|
弹性计算 Kubernetes 测试技术
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
245 0
|
9月前
|
负载均衡 Kubernetes 前端开发
基于 Traefik 的加权灰度发布
众所周知,Traefik 是云原生生态中的一个爆款的反向代理和负载均衡器。我们无论如何定义、赞美它都不为过。毫无疑问,基于传统的反向代理组件而言,真正使 Traefik 与 Nginx,Haproxy 最为关键的不同之处在于其“开箱即用”的功能,即它的自适应和动态可配置性。不仅如此,相比较而言,Traefik 最为核心的部分可能是它做自动服务发现、灰度发布等能力。
257 0
|
运维 Kubernetes Cloud Native
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布|学习笔记(一)
快速学习 Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布
118 0
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布|学习笔记(一)
|
Cloud Native Java 中间件
全链路灰度新功能:MSE 上线配置标签推送
本文介绍了全链路灰度场景给配置管理带来的问题,介绍了 MSE 针对这一场景的解决方案,并通过实践的方式展示了配置标签推送的使用流程。后续,MSE 还会针对配置治理做更多的探索,帮助用户更好地解决微服务配置管理中的难题,提高微服务应用的稳定性。
全链路灰度新功能:MSE 上线配置标签推送
|
Java 中间件 测试技术
全链路灰度新功能:MSE上线配置标签推送
微服务场景下,全链路灰度作为一种低成本的新功能验证方式,得到了越来越广泛的应用。除了微服务实例和流量的灰度,微服务应用中的配置项也应该具备相应的灰度能力,以应对灰度应用对特殊配置的诉求。
全链路灰度新功能:MSE上线配置标签推送
|
4天前
|
Kubernetes API Nacos
基于Ingress-APISIX网关实现全链路灰度
本文介绍了通过将 APISIX 提供的灵活的路由能力以及 MSE 提供的全链路灰度能力结合,可以在不需要修改任何业务代码的情况下,轻松实现全链路灰度能力。
基于Ingress-APISIX网关实现全链路灰度