其他
解密最受欢迎的开源 Serverless 框架：流量篇
The following article is from 阿里云云原生 Author 元毅
Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架，其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布、函数部署以及事件驱动等。
流量管理
Cloud Native
如何做蓝绿发布
apiVersion: serving.knative.dev/v1kind: Servicemetadata: name: example-service namespace: defaultspec:... 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 进行版本验证
Revision 版本的 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: v1kind: ConfigMapmetadata: 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
apiVersion: v1kind: ConfigMapmetadata: 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
apiVersion: v1kind: ConfigMapmetadata: 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）
apiVersion: v1kind: ConfigMapmetadata: 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
apiVersion: v1kind: ConfigMapmetadata: 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。
多协议支持
apiVersion: serving.knative.dev/v1kind: Servicemetadata: name: helloworld-grpcspec: 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: TCPgRPC 服务在 Knative 服务中 port 字段下的 name 设置为 h2c。
此外，为了满足单个服务同时暴露 HTTP 和 gRPC 的诉求，我们也扩展了 Knative 能力，支持同时配置 HTTP 和 gRPC 服务暴露，配置示例如下：
apiVersion: serving.knative.dev/v1kind: Servicemetadata: name: helloworld-grpc annotations: knative.alibabacloud.com/grpc: grpcbin.GRPCBinspec: 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自定义域名
为单独服务自定义域名
apiVersion: serving.knative.dev/v1alpha1kind: DomainMappingmetadata: 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 名称
自定义全局域名后缀
apiVersion: v1kind: ConfigMapmetadata: name: config-domain namespace: knative-servingdata: mydomain.com: ""自定义 Path
apiVersion: serving.knative.dev/v1kind: Servicemetadata: name: coffee-mydomain annotations: knative.aliyun.com/serving-ingress: cafe.mydomain.com/coffeespec: 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 数量，从而实现自动扩缩容。
流量监控
Cloud Native
• 8012：queue-proxy 代理的 http 端口，流量的入口都会到 8012
• 8013：http2 端口，用于 grpc 流量的转发
• 8022：queue-proxy 管理端口，如健康检查
• 9090: queue-proxy 的监控端口，暴露指标供 autoscaler 采集，用于 kpa 扩缩容
• 9091：prometheus 应用监控指标（请求数，响应时长等）
• USER_PORT，是用户配置的容器端口，即业务实际暴露的服务端口，在 ksvc container port 配置的
此外 Knative 提供了 grafana 大盘：https://github.com/knative-extensions/monitoring/tree/main/grafana
大盘数据的纵轴 ops/sec 表示每秒处理请求数。
Response Time：可以查看 Knative 的响应延迟数据，包括 P50、P90、P95 和 P99。
Resource Usages：可以查看 Knative 的资源使用量情况，包括 CPU 和内存。
小结
Cloud Native
本文介绍了 Knative 流量管理、流量访问、基于流量的弹性以及监控，并且我们提供了丰富的云产品网关能力，适用于不同的业务场景。可以看到基于 Knative，可以轻松做到基于流量的按需使用、自动弹性的 Severless 能力。
参考阅读：
本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿