Knative: 基于流量的灰度发布和自动弹性实践

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 作为 Severless Framework 就离不开按需分配资源的能力,Knative 提供了基于流量的自动扩缩容能力,可以根据应用的请求量在高峰时期自动扩容实例数,当请求量减少以后自动缩容实例数,做到自动化的帮助您节省成本。此外 Knative 还提供了基于流量的灰度发布能力,可以根据流量百分比进行灰度发布。

导读

作为 Severless Framework 就离不开按需分配资源的能力,Knative 提供了基于流量的自动扩缩容能力,可以根据应用的请求量在高峰时期自动扩容实例数,当请求量减少以后自动缩容实例数,做到自动化的帮助您节省成本。此外 Knative 还提供了基于流量的灰度发布能力,可以根据流量百分比进行灰度发布。本文会从以下 4 个方面展开介绍:

  • ASK Knative 中流量请求机制
  • 基于流量的灰度发布
  • 弹性自动扩缩容
  • 示例演示


介绍Knative 灰度发布和自动弹性前,我们先来看一下 ASK Knative 中流量请求机制。

ASK Knative 流量请求机制

在 ASK Knative 中,流量首先通过SLB网关,然后根据转发规则,将请求转发到对应服务的POD上,这里转发规则是通过Knative Ingress Controlller创建,该 controller 通过 Route 中设置的规则,最终转换成 SLB 规则。

image.png

Service

Configuration

Route

externaltrafficarrives

throughthegateway

Revision

Revision1

ECI

Revision2

lngressGateway

Pod

(SLB)

a0IJss8Y

Revision3

10%

Jeuieiuo.

enENO

ECI

Jasn

Pod

Jeuiejuo.

保留规格

Route

Jsn

aneND

lngress(SLB)

Deployment

reference

scale

Autoscaler

HPA

KPA

Knative

ASK

再谈 Knative 应用生命周期


Knative Service 是直接面向开发者操作的资源对象它直接负责对Route和Configuration的管控,一个Service 分别对应一个Route和一个Configuration


Service

每次 Service 变化如果需要创建新的 Workload 就更新 Configuration,然后每次 Configuration 更更新都会创建一个唯一的 Revision。Configuration 可以认为是版本控制器,负责管理多个Revision版本

image.png

Service

Configuration

管理容器期望的状态

类似版本控制器,每次更新

Configuration都会创建新的Revision

Configuration

Route

apiversionserying.knatied/llh

kind:configuration

metadata:

Revision

name:coffee

spec:

template:

spec:

containers:

image:tegistzy.cnhangzhou

enV:

nAme:TARGET

"coffee"

value:

Route

Route 主要负责 Knative 的流量管理,控制流量分发到不同到Revision, 并且支持按照百分比进行流量分发。这里我们可以通过在Traffic中对不同的Revison 设置不同对流量比例即可控制流量分发。

image.png

Service

Route

控制流量分发到不同的Revision

支持按照百分比进行流量分发

Route

Configuration

apiversionservingknti/

kind:Route

10%

metadata:

Revision

name:coffee

spec:

traffic:

90%

Revision

revisionNamecoFfee-08-17-2019

percent:90

reyisionName:coffee-0819-2020

percent:10

Revision

Revision. 一个Revision可以认为是一个Configuration的快照。通过Revision可以实现历史版本追踪,以及灰度发布的过程中进行回滚等功能。

image.png

Service

Revision

一个Configuration的快照

.版本追踪,回滚

Configuration

Route

apiversionservingte

kind:Revision

metadata:

Revision

name:coffee-b7g8d

spec:

template:

Revision

spec:

containers:

mage:tegsty:changhou

enV:

name:TARGET

value:"coffee"



基于流量的灰度发布

那么接下来我们看一下基于流量的灰度发布我们可以怎样做。

假设一开始我们创建了V1版本的Revison, 这时候如果有新的版本变更,那么我们只需要更新Service 中的Configuration, 就会创建出V2版本,然后我们可以通过Route对V1、V2设置不同对流量比例,这里v1是70%, v2是30%, 那么流量就会分别按照7:3的比例分发到这两个版本上。一旦新到V2版本验证没有问题,那么我们接下来就可以通过调整比例继续灰度,直到新版本V2 100%。在这个灰度到过程中,一旦发现新版本有异常,可以通过调整比例进行回滚操作。

除此以外,我们可以在Route到Traffic 中对Revison打Tag,  打完Tag的Revison, 我们可以直接通过Url进行单独的版本测试,对这个版本对调试不会影响正常对流量访问。

image.png

Service

Configuration

Route

Revision1

Revision2

Revision3

自动弹性

接下来我们聊一下自动弹性。作为 Severless Framework 就离不开按需分配资源的能力,Knative 提供了基于流量的自动扩缩容KPA能力,以及基于CPU和Memory的HPA弹性能力,除此以外,Knative 提供了弹性的扩展能力,我们可以基于不同的指标自定义弹性功能。

  • Knative Pod 自动扩缩容 (KPA)
  • Pod 水平自动扩缩容 (HPA)
  • 支持定时 + HPA的自动扩缩容策略
  • 事件网关(基于流量请求的精准弹性)
  • 扩展自定义扩缩容插件


KPA

Knative Serving 中默认使用KPA。

image.png

Route

active

inactive

route

route

resize

create

Pods

Deployment

Activator

metrics

Autoscaler

activate

Revision

上图展示了 Knative Autoscaler 的工作机制,Route 负责接入流量,Autoscaler 负责做弹性伸缩。当没有业务请求的时候会缩容到零,缩容到零后 Route 进来的请求会转到 Activator 上。当第一个请求进来之后 Activator 会保持住 http 链接,然后通知 Autoscaler 去做扩容。Autoscaler 把第一个 pod 扩容完成以后 Activator 就把流量转发到 Pod ,从而做到了缩容到零也不会损失流量的目的。

当后续有流量进来之后,流量会直接Route到Pod上,这时候Autoscaler会直接采集Pod中的指标,根据指标进行1-N的扩缩容操作。


HPA

基于CPU、Memory的自动扩缩容-HPA

image.png


利用 Horizontal Pod Autoscaling,kubernetes 能够根据监测到的 CPU 、Memory利用率 通过 修改deployment  中 pod 的数量,进行扩容。在Knative 中集成了HPA的能力,通过autoscaling class可以选择HPA的能力。


定时与HPA融合

支持定时+HPA的自动扩缩容:

  • 提前规划容量进行资源预热
  • 与CPU、Memory弹性指标相结合


image.png

Pod

Pod

Pod

Deployment

Revision

定时

HPA

事件网关

基于流量请求的精准弹性:

  • 基于请求数自动弹性
  • 支持1对1任务分发

image.png

事件网关

POD

POD

Event

Gateway

POD

POD

Deployment

任务数

Scaler

自动弹性

自定义扩缩容插件

Knative 中提供了灵活的扩缩容插件机制, 开发者可以通过设置`autoscaling.knative.dev/class`来指定所使用的具体插件。自定义扩缩容插件只需要实现下面两个关键能力即可:

  • 采集指标
  • 调整Pod实例数

image.png

示例演示

这里我们分别演示一下基于流量灰度发布和自动扩缩容的功能。

灰度流量发布

我们以 helloworld 的服务为例,分别执行如下操作:

  • 创建 helloworld 服务
  • 升级服务
  • 灰度发布

创建 helloworld 服务

  1. 登录容器服务管理控制台
  2. 集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情
  3. 在集群管理页左侧导航栏中,选择应用 > Knative
  4. 服务管理页签右上角,单击创建服务
  5. 设置集群命名空间服务名称,选择所要使用的镜像和镜像版本等配置信息。这里我们创建 helloworld-go 服务。

image.png

  1. 单击创建创建完成后,您可以在服务管理页签的列表中,点击helloworld-go看到新创建的服务。


image.png

此时我们访问服务:

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

升级服务

点击【创建修订版本】,这里我们设置新版本环境变量为:TARGET=Knative

image.png

环块变量

安量/变量引用

奥型

安量名称

TARGET

自定义

KnaLivel

数称卷:

加本地存馆

存储寻炎型

挂盐源

容器路径

楼加云存声明(Persistentvolumeclaim)

挂裁源

容器游经

存储糕英型

下一步

返回

点击下一步,我们可以设置新版本的流量比例,这里我们设置新版本流量为0,点击创建。

image.png

集群:knative-系列直播-y

创建修订版本

default

b-yuanyi/命名空间:

创建完成

流晕设置

基本信息

流量设亡:

添加

流量比阿%

特订版本

最新停订版本

100

hellovrorldgom4w[2021-02-0915:23:37]

上一步

创廷

在服务详情中,可以看到新的版本已经创建完成,如图:

image.png

集群:knative-系列直番-yuany/Knative服务普理:hellowordgo

别乐

返回列表

创延修订版本

访问设五

设直流量比例

苏本信息

服务名称:

hellowiorld-go

访问网关:

39.106.199.35

默认域名:

成功

状态:

创连时间:

2021-02-0915:23:37

停订版本信

操作

锭俊

流量

创注时间

状态

2021-02-0915:32:42

工作负苛

hellowarid-go-5zcv[最新停订版本]

出险

0%

成功

registyCnhangzou.Alyncscomnemplhewq.7b

2021-02-0915:23:37

registycn-hangzhou.liyun.complh

工作负载

别险

音君Yaml

100%

球功

helloworld-qo-m45w8

由于新版本流量为0,所以当前访问helloworld-go 服务的话,还是请求到原来的版本中。

此时我们访问服务:

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

灰度发布

接下来我们开始灰度流量发布,点击【设置流量比例】,将新、旧版本各设置为50%。

image.png

在服务详情中,可以看到新、旧的版本已经创建完成,如图:

image.png

创滨停订版本

朱群:knative-系列直播-yuanyl/knative服务管理:helloworid-qo

设置流量比例

访问设置

返回列表

可新

什本信息

服务名称:

helloworld-go

访问网关:

39.106.199.35

默认域名:

helloworid-go.defaultexample.com

成功

状态:

2021-02-0915:23:37

创诺时间:

传订版本信总

操作

找态

钠像

创硅时间

流量

hellowvorld-go-5zcvj[服折停订版本]

工作负栽

现隐

2021-02-0915:32:42

成功

50%

registiycnhangzhou.aliyuncs.comnate-samleowr.

2021-02-0915:23:37

工作负钱

50%

刮除

成功

查Yam

hellowyarla-qo-m4sw8

registirycn-hangzhou.lyunsmw

由于新、旧版本流量各为50%,所以当前访问helloworld-go 服务的话,基本是50%进行流量分配。

此时我们访问服务:

image.png

我们通过调整流量比例继续灰度,直到新版本100%,完成灰度发布。

image.png

在这个过程中,如何发现新版本有问题,可以随时通过调整流量比例的方式进行回滚操作。

基于流量的自动扩缩容

我们模拟并发场景,并发50,持续30s。使用hey工具(hey压测工具的详细介绍请参见hey

hey -z 30s -c 50   -host "helloworld-go.default.example.com"   "http://39.106.199.35"

结果如下:

$ kubectl get po
helloworld-go-g2qfr-deployment-5f557f97cc-76mjb                   2/2     Running   0          38s
helloworld-go-g2qfr-deployment-5f557f97cc-7j797                   2/2     Running   0          34s
helloworld-go-g2qfr-deployment-5f557f97cc-fh4nl                   2/2     Running   0          2m4s
helloworld-go-g2qfr-deployment-5f557f97cc-kdqjx                   2/2     Running   0          38s
helloworld-go-g2qfr-deployment-5f557f97cc-kmxsz                   2/2     Running   0          26s
helloworld-go-g2qfr-deployment-5f557f97cc-p24s8                   2/2     Running   0          2m48s
helloworld-go-g2qfr-deployment-5f557f97cc-wq89q                   2/2     Running   0          36s
helloworld-go-g2qfr-deployment-5f557f97cc-zfhf6                   2/2     Running   0          38s
helloworld-go-g2qfr-deployment-5f557f97cc-xvdf6                   2/2     Running   0          38s
helloworld-go-g2qfr-deployment-5f557f97cc-aeaf8                   2/2     Running   0          37s
helloworld-go-g2qfr-deployment-5f557f97cc-dfdsa                   2/2     Running   0          46s

当然,我们也可以在日志服务中配置查看Pod扩缩容趋势

image.png


总结

本文我们介绍了基于流量的灰度发布以及自动弹性策略,并分别进行了示例演示。欢迎有兴趣同学关注 Knative 钉钉交流群。

image.png


相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
测试技术 微服务 负载均衡
微服务部署:蓝绿部署、滚动部署、灰度发布、金丝雀发布
在项目迭代的过程中,不可避免需要”上线“。上线对应着部署,或者重新部署;部署对应着修改;修改则意味着风险。 目前有很多用于部署的技术,有的简单,有的复杂;有的得停机,有的不需要停机即可完成部署。
2865 0
|
2月前
|
Kubernetes 监控 Java
发布策略:蓝绿部署、金丝雀发布(灰度发布)、AB测试、滚动发布、红黑部署的概念与区别
发布策略:蓝绿部署、金丝雀发布(灰度发布)、AB测试、滚动发布、红黑部署的概念与区别
231 0
|
3月前
|
Cloud Native 测试技术 开发者
阿里云服务网格ASM多集群实践(二):高效按需的应用多环境部署与全链路灰度发布
介绍服务网格ASM提出的一种多集群部署下的多环境部署与全链路灰度发布解决方案。
|
5月前
|
Kubernetes Cloud Native 测试技术
使用ASM流量泳道的全链路灰度发布实践
服务网格ASM实现全链路灰度发布:通过流量泳道隔离不同版本环境,配置虚拟服务实现灰度比例控制。从创建泳道、打标签、部署新版本到灰度切流、最终上线及下线旧版。
|
Kubernetes Cloud Native 前端开发
构建基于 Ingress 的全链路灰度能力
微服务架构下,有一些需求开发,涉及到微服务调用链路上的多个微服务同时发生了改动,通常每个微服务都会有灰度环境或分组来接受灰度流量,我们希望通过进入上游灰度环境的流量,也能进入下游灰度的环境中,确保1个请求始终在灰度环境中传递,即使这个调用链路上有一些微服务没有灰度环境,这些应用请求下游的时候依然能够回到灰度环境中。通过 MSE 提供的全链路灰度能力,可以在不需要修改任何您的业务代码的情况下,能够轻松实现上述能力。
构建基于 Ingress 的全链路灰度能力
|
测试技术 Serverless vr&ar
Knative 灰度发布和自动弹性|学习笔记(二)
快速学习Knative 灰度发布和自动弹性
165 0
Knative 灰度发布和自动弹性|学习笔记(二)
|
测试技术 Serverless vr&ar
Knative 灰度发布和自动弹性|学习笔记(一)
快速学习 Knative 灰度发布和自动弹性
148 0
Knative 灰度发布和自动弹性|学习笔记(一)
|
测试技术 Serverless vr&ar
Knative 灰度发布和自动弹性(一)|学习笔记
快速学习 Knative 灰度发布和自动弹性(一)
130 0
Knative 灰度发布和自动弹性(一)|学习笔记
|
Serverless 测试技术 vr&ar
Knative 灰度发布和自动弹性(二)|学习笔记
快速学习Knative 灰度发布和自动弹性(一)
|
Kubernetes 监控 网络协议
Serverless容器与基于流量模式的自动扩缩
Serverless和Service Mesh是两种流行的云原生技术,客户正在探索如何从中创造价值。 随着我们与客户深入研究这些解决方案,问题经常出现在这两种流行技术之间的交集以及它们如何相互补充上。我们能否利用 Service Mesh 来保护、观察和公开我们的 Knative 无服务器应用程序?本文试图解释如何在一个托管的服务网格技术平台上支持基于Knative的Serverless容器, 以及基于流量模式的自动扩缩能力。
881 0
Serverless容器与基于流量模式的自动扩缩