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

最新推荐文章于 2024-04-26 15:29:21 发布

高可用架构

最新推荐文章于 2024-04-26 15:29:21 发布

阅读量65

点赞数

文章标签：开源 serverless 云原生

原文链接：https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653562359&idx=1&sn=968ed802bdad0f86aa4756e168796eeb&chksm=80d3f871ca76036e7104c866cbacc8f224c0acc06f7ac3e805731bdf07deae00f968eb7d14c7&scene=126&sessionid=0

版权

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

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

流量管理

Cloud Native

如何做蓝绿发布

我们首先看一下，在 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"

流量访问

Cloud Native

多网关支持

为了满足不同场景的诉求，我们提供了多样化的网关能力，包括 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

流量弹性

Cloud Native

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 框架弹性技术实现》

流量监控

Cloud Native

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 个请求的资源使用量。

小结

Cloud Native

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

参考阅读：

本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿

高可用架构

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
解密最受欢迎的开源 Serverless 框架：流量篇

对于 web 应用来说，通过请求流量的并发数、qps、rt 等指标，可以很好的衡量当前的 web 服务质量。Knative 中提供了基于请求驱动的 Serverless 能力，包括多版本管理流量，流量访问，基于流量的弹性以及监控等。本文从流量角度出发，为您解密 Knative 相关的能力。Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架，其目标是制定云原...
复制链接

扫一扫