解密最受欢迎的开源 Serverless 框架:流量篇

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 解密最受欢迎的开源 Serverless 框架:流量篇

作者:元毅


对于 web 应用来说,通过请求流量的并发数、qps、rt 等指标,可以很好的衡量当前的 web 服务质量。Knative 中提供了基于请求驱动的 Serverless 能力,包括多版本管理流量,流量访问,基于流量的弹性以及监控等。本文从流量角度出发,为您解密 Knative 相关的能力。

Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架,其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布、函数部署以及事件驱动等。

流量管理


如何做蓝绿发布

我们首先看一下,在 K8s 中如果要做基于流量的蓝绿发布需要怎么做?



首先需要创建对应的 K8s Service 与 Deployment,如果需要弹性,则还需要配置 HPA,然后在流量灰度发布时,要创建新的版本。以上图为例,创始版本是 v1,要想实现流量灰度发布,我们需要创建一个新的版本 v2。创建 v2 时,要创建对应的 Service、Deployment、HPA。创建完之后通过 Ingress 设置对应的流量比例,最终实现流量灰度发布的功能。显然,在 K8s 要做基于流量的蓝绿发布,需要管理多种资源,并且随着版本的迭代,管理起来会更加复杂。


而在 Knative 做到基于流量的灰度发布,只需要面向 Knative Service 一个资源对象,调整流量比例即可。



Knative 提供了 Serverless 应用模型的抽象:Service。Knative Service 中包含两部分配置,一部分用于配置工作负载,叫做 Configuration,每次 Configuration 内容更新都会创建一个新的 Revision。另一部分 Route 主要负责 Knative 的流量管理。可以这样理解:Knative Revision Ingress + Service + Deployment + 弹性(HPA) 。一个 Knative Service 流量配置示例如下:


apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - percent: 0
    revisionName: example-service-1
    tag: staging
  - percent: 40
    revisionName: example-service-2
  - percent: 60
    revisionName: example-service-3


不同的 revision 版本之间只需要配置对应的流量比例,即可进行流量的蓝绿发布。而回滚到原版本的操作亦是如此,只需要将新版本的流量切回到 0,原版本设置为 100 即可。


指定 tag 进行版本验证

在实际发布新版本上线时,对于新版本我们往往需要在切入生产流量之前验证这个版本是否有问题,但这时候新版本流量为 0,如果进行验证呢?Knative 中提供了 tag 机制可以做到。也就是对某个版本打上 tag,然后 Knative 会自动生成改 tag 的访问地址。


例如,上面的 example-service-1 版本中设置了 staging 的 tag,就会创建一个  staging-example-service.default.example.com 的访问地址。通过这个访问地址就可以直接验证 example-service-1 版本,而不用担心线上流量访问该版本,做到了指定版本验证的能力。


Revision 版本的 GC 策略

Knative Service 每次修改就会创建新的版本,而随着迭代的加速,必然会导致很多历史版本,那么对历史版本如何清理呢?Knative 中提供了版本自动清理能力。可以通过 config-gc 配置 GC 策略。这里的参数说明一下:


  • retain-since-create-time:表示 revision 从创建时间开始多长时间保留,默认是 48 小时。
  • retain-since-last-active-time:表示从最后一次活跃状态(表示被 route 引用,即使 traffic 配置为 0,只要被引用也就表示活跃)开始多长时间保留,默认是 15 小时。
  • min-non-active-revisions:最少非活跃的版本数,默认是 20 个版本数。
  • max-non-active-revisions:最大非活跃的版本数,默认是 1000 版本数。


apiVersion: v1
kind: ConfigMap
metadata:
  name: config-gc
  namespace: knative-serving
  labels:
    app.kubernetes.io/name: knative-serving
    app.kubernetes.io/component: controller
    app.kubernetes.io/version: "1.8.2"
data:
  _example: |
    # ---------------------------------------
    # Garbage Collector Settings
    # ---------------------------------------
    # Duration since creation before considering a revision for GC or "disabled".
    retain-since-create-time: "48h"
    # Duration since active before considering a revision for GC or "disabled".
    retain-since-last-active-time: "15h"
    # Minimum number of non-active revisions to retain.
    min-non-active-revisions: "20"
    # Maximum number of non-active revisions to retain
    # or "disabled" to disable any maximum limit.
    max-non-active-revisions: "1000"


例如,如果要配置立即回收 inactive revision,可以这样配置:


min-non-active-revisions: "0"
max-non-active-revisions: "0"
retain-since-create-time: "disabled"
retain-since-last-active-time: "disabled"


例如,如果要配置只保留 10 个 inactive revision,可以这样配置:


retain-since-create-time: "disabled"
retain-since-last-active-time: "disabled"
max-non-active-revisions: "10"


流量访问


多网关支持

为了满足不同场景的诉求,我们提供了多样化的网关能力,包括 ALB、MSE、ASM 以及 Kourier 网关。


ALB

阿里云应用型负载均衡 ALB(Application Load Balancer) 之上提供更为强大的 Ingress 流量管理方式,提供全托管免运维的方式,并且提供自动弹性能力。



配置 ALB 网关,只需要在 config-network 进行如下设置:


apiVersion: v1
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
  labels:
    app.kubernetes.io/name: knative-serving
    app.kubernetes.io/component: networking
    app.kubernetes.io/version: "1.8.2"
data:
  ingress.class: "alb.ingress.networking.knative.dev"
  ...


微服务网关 MSE

MSE 云原生网关是兼容 K8s Ingress 标准的下一代网关产品,将传统的流量网关和微服务网关功能合并。Knative 结合 MSE 网关支持基于请求的精准自动弹性(mpa),支持精准控制单个 Pod 请求并发处理数。



配置 MSE 网关,只需要在 config-network 进行如下设置:


apiVersion: v1
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
  labels:
    app.kubernetes.io/name: knative-serving
    app.kubernetes.io/component: networking
    app.kubernetes.io/version: "1.8.2"
data:
  ingress.class: "mse.ingress.networking.knative.dev"
  ...


服务网格 ASM(Istio)

阿里云服务网格(简称 ASM)是一个统一管理微服务应用流量、兼容 Istio 的托管式平台。通过流量控制、网格观测以及服务间通信安全等功能,服务网格 ASM 可以全方位地简化服务治理。



Knative 天然支持与 Istio 的集成,因此只需要在 config-network 配置  istio.ingress.networking.knative.dev 即可:


apiVersion: v1
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
  labels:
    app.kubernetes.io/name: knative-serving
    app.kubernetes.io/component: networking
    app.kubernetes.io/version: "1.8.2"
data:
  ingress.class: "istio.ingress.networking.knative.dev"
  ...


Kourier

Kourier 是一个基于 Envoy 架构实现的轻量级网关,提供 Knative Revisions 流量分发,支持 gRPC 服务、超时和重试、TLS 证书和外部认证授权等功能。



只需要在 config-network 配置 kourier.ingress.networking.knative.dev 即可:


apiVersion: v1
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
  labels:
    app.kubernetes.io/name: knative-serving
    app.kubernetes.io/component: networking
    app.kubernetes.io/version: "1.8.2"
data:
  ingress.class: "kourier.ingress.networking.knative.dev"
  ...


上述网关总的来说,ALB 专注与应用负载均衡,云原生网关 MSE 专注于微服务场景,而 ASM 提供了服务网格(Istio)的能力,用户可以结合自身的业务场景选择相应的云产品网关产品,当然如果用户仅需基础的网关能力,也可以选择 Kourier。


选择适合自己的 Knative 网关请参考:https://help.aliyun.com/zh/ack/serverless-kubernetes/user-guide/select-a-gateway-for-knative


多协议支持

Knative 支持多种访问协议:HTTP、gRPC 以及 WebSocket。一个 Knative gRPC 服务配置示例如下:


apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-grpc
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
    spec:
      containers:
      - image: docker.io/moul/grpcbin # 该镜像是一个用于测试gRPC的工具,它通过提供gRPC服务来响应请求。
        env:
        - name: TARGET
          value: "Knative"
        ports:
        - containerPort: 9000
          name: h2c
          protocol: TCP


gRPC 服务在 Knative 服务中 port 字段下的 name 设置为 h2c。

此外,为了满足单个服务同时暴露 HTTP 和 gRPC 的诉求,我们也扩展了 Knative 能力,支持同时配置 HTTP 和 gRPC 服务暴露,配置示例如下:


apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-grpc
  annotations:
    knative.alibabacloud.com/grpc: grpcbin.GRPCBin
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
    spec:
      containers:
      - image: docker.io/moul/grpcbin
        args:
        - '--production=true'
        env:
        - name: TARGET
          value: "Knative"
        ports:
        - containerPort: 80
          name: http1
          protocol: TCP
        - containerPort: 9000
          name: h2c
          protocol: TCP


自定义域名

在 Knative 中,可以对单独的 Knative Service 自定义域名,也支持全景的域名后缀配置,此外也支持自定义 path。


为单独服务自定义域名

如果想自定义单个 Service 的域名,可以使用 DomainMapping。DomainMapping 配置模版如下:


apiVersion: serving.knative.dev/v1alpha1
kind: DomainMapping
metadata:
  name: <domain-name>
  namespace: <namespace>
spec:
  ref:
    name: <service-name>
    kind: Service
    apiVersion: serving.knative.dev/v1
  tls:
    secretName: <cert-secret>

  • <domain-name> 设置服务域名
  • <namespace> 设置命名空间,与服务所在的命名空间一致
  • <service-name> 目标服务名称
  • <cert-secret>(可选)证书 secret 名称


自定义全局域名后缀

可以通过修改 config-domain,配置全局域名后缀。如使用 mydomain.com 替换掉 example.com。修改配置如下即可:


apiVersion: v1
kind: ConfigMap
metadata:
  name: config-domain
  namespace: knative-serving
data:
  mydomain.com: ""


自定义 Path

此外,可以通过 knative.aliyun.com/serving-ingress 注解,配置自定义的路由 Path,示例如下:


apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: coffee-mydomain
  annotations:
    knative.aliyun.com/serving-ingress: cafe.mydomain.com/coffee
spec:
  template:
    metadata:
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8


流量弹性


Knative 提供基于流量请求的自动扩缩容 KPA(Knative Pod Autoscaler)能力。实现原理是:Knative Serving 会为每个 Pod 注入一个名为 queue-proxy 的 QUEUE 代理容器,该容器负责向 Autoscaler 报告业务容器的并发指标。Autoscaler 接收到这些指标之后,会根据并发请求数及相应的算法,调整 Deployment 的 Pod 数量,从而实现自动扩缩容。



Knative Pod Autoscaler(KPA)基于每个 Pod 的平均请求数(或并发数)进行自动扩缩容,Knative 默认使用基于并发数的自动弹性,每个 Pod 的最大并发数为 100。此外,Knative 还提供了目标使用率(target-utilization-percentage)的概念,用于指定自动扩缩容的目标使用率。


基于并发数弹性为例,Pod 数计算方式如为:Pod 数=并发请求总数/(Pod 最大并发数*目标使用率)。


例如,如果服务中 Pod 最大并发数设置为 10,目标使用率设置为 0.7,此时如果接收到了 100 个并发请求,则 Autoscaler 就会创建 15 个 Pod(即 100/(0.7*10)≈15)。


此外当请求为 0 时,支持 Pod 数自动缩容到 0 。


具体 Knative 弹性介绍详见:《解密最受欢迎的开源 Serverless 框架弹性技术实现》


流量监控


Knative 如何采集流量指标,关键还是 queue-proxy。queue-proxy 除了用于流量弹性之外,还提供 Promethues 指标暴露,如请求数,并发数,响应时长等。其端口说明如下:


• 8012:queue-proxy 代理的 http 端口,流量的入口都会到 8012
• 8013:http2 端口,用于 grpc 流量的转发
• 8022:queue-proxy 管理端口,如健康检查
• 9090:  queue-proxy 的监控端口,暴露指标供 autoscaler 采集,用于 kpa 扩缩容
• 9091:prometheus 应用监控指标(请求数,响应时长等)
• USER_PORT,是用户配置的容器端口,即业务实际暴露的服务端口,在 ksvc container port 配置的



通过 Prometheus 采集到的关键指标如下:


此外 Knative 提供了 grafana 大盘:https://github.com/knative-extensions/monitoring/tree/main/grafana


阿里云容器服务 Knative 集成了该 grafana大盘, 提供了开箱即用的可观测能力,通过大盘可以查看请求数、请求成功率、Pod 扩缩容趋势以及请求响应延迟等。Overview:可以查看 Knative 的请求量、请求成功率、4xx(客户端错误)、5xx(服务器端错误)和 Pod 扩缩容趋势的监控数据。



大盘数据的纵轴 ops/sec 表示每秒处理请求数。

Response Time:可以查看 Knative 的响应延迟数据,包括 P50、P90、P95 和 P99。



Autoscaler:可以查看 Knative 的请求并发数的详细数据。



Resource Usages:可以查看 Knative 的资源使用量情况,包括 CPU 和内存。



基于这些指标,我们可以很容易计算出 1 个请求的资源使用量。


小结


本文介绍了 Knative 流量管理、流量访问、基于流量的弹性以及监控,并且我们提供了丰富的云产品网关能力,适用于不同的业务场景。可以看到基于 Knative,可以轻松做到基于流量的按需使用、自动弹性的 Severless 能力。


欢迎使用钉钉搜索群号:23302777 加入 Knative 交流群。


点击此处了解更多阿里云 Knative 产品相关信息!

相关实践学习
【文生图】一键部署Stable Diffusion基于函数计算
本实验教你如何在函数计算FC上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。函数计算提供一定的免费额度供用户使用。本实验答疑钉钉群:29290019867
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
相关文章
|
3月前
|
运维 监控 Serverless
函数计算产品使用问题之HTTP触发器被恶意刷流量,该怎么办
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
29天前
|
运维 物联网 关系型数据库
关于阿里云Serverless 框架的产品体验
阿里云Serverless框架简化运维,实现5分钟一键部署。弹性伸缩、按需付费等特点让企业专注业务创新,降低成本与运维负担。适用于Web应用、数据分析、物联网等多种场景,支持快速迭代与多语言开发。尽管面临资源配额、网络配置等挑战,其竞争力在于成本节约、功能集成与性能优化,尤其适合追求高效开发与弹性扩展的团队。
74 1
|
14天前
|
运维 Serverless 对象存储
函数计算产品使用问题之如何使用Flask框架支持Stream模式
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
2月前
|
JSON 运维 Serverless
Serverless 应用引擎使用问题之ThinkPHP框架是否有基于SDK的demo
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
17天前
|
机器学习/深度学习 监控 大数据
Serverless 应用的监控与调试问题之Flink在整个开源大数据生态中应该如何定位,差异化该如何保持
Serverless 应用的监控与调试问题之Flink在整个开源大数据生态中应该如何定位,差异化该如何保持
|
3月前
|
运维 Serverless API
Serverless 应用引擎产品使用合集之如何实现一键迁移Web框架
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
4月前
|
弹性计算 运维 Serverless
阿里云Elasticsearch Serverless帮助某视觉科技公司平稳应对流量激增
某视觉科技公司借助阿里云Elasticsearch Serverless应对创意资源平台的流量激增,通过服务自动扩缩容,确保流量高峰时的快速响应,降低至少50%的成本。同时,它提供弹性数据容量支持,简化运维,提升开发效率,并保证高精确度的搜索体验。
670 1
|
4月前
|
关系型数据库 Serverless 分布式数据库
【PolarDB 开源】PolarDB Serverless 模式:自动扩缩容与成本效益分析
【5月更文挑战第25天】PolarDB Serverless 提供自动扩缩容功能,适应动态工作负载,降低成本。在业务高峰期增加资源保障性能,低谷期减少资源实现成本优化。通过对比传统模式下的成本浪费,示例说明了Serverless如何节省开支。代码演示了连接与查询PolarDB Serverless数据库的基本操作。要充分利用该模式,需合理规划业务、监控性能并结合其他云服务。PolarDB Serverless是弹性、经济的数据库选择,未来将持续创新,助力企业高效发展。
398 1
|
4月前
|
JavaScript 前端开发 Cloud Native
报名开启!2024 开源之夏丨Serverless Devs 课题已上线!
2024 年,Serverless Devs 再次加入中国科学院软件研究所开源软件供应链点亮计划支持下的系列高校开源活动——开源之夏 2024。
|
3月前
|
运维 关系型数据库 Serverless
Serverless 应用引擎产品使用合集之FC到外网的流量属于函数计算的计费范围吗
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。