解密最受欢迎的开源 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 网关请参阅：help.aliyun.com/zh/ack/serv…

多协议支撑

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>

设置服务域名
设置命名空间，与服务所在的命名空间一致
方针服务称号
（可选）证书 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 大盘：github.com/knative-ext…

阿里云容器服务 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 交流群。

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