解密最受欢迎的开源 Serverless 框架：流量篇
内容提要
Knative在流量管理、流量访问、基于流量的弹性和监控方面具有强大的能力。它提供了自动弹性、多版本管理和流量灰度发布等功能。流量管理只需调整比例，无需管理多种资源。Knative还支持版本验证、自动清理和自定义域名等功能。
延伸解读
Knative 流量管理：简化蓝绿发布的资源抽象
在原生 Kubernetes 中实现基于流量的蓝绿发布，需要同时管理 Service、Deployment、HPA 和 Ingress 等多种资源，随着版本迭代，管理复杂度会显著增加。Knative 通过 Service 抽象将工作负载配置（Configuration）和流量路由（Route）整合，发布新版本时只需调整流量比例，回滚同样只需切换比例。这种设计降低了多资源协调的运维负担，尤其适合需要频繁发布和快速回滚的场景。
版本验证与自动清理：发布流程的实用补充
Knative 的 tag 机制允许为新版本生成独立访问地址，在不切入生产流量的情况下验证新版本，解决了零流量版本难以测试的问题。同时，随着版本迭代，历史 Revision 会不断累积，Knative 提供 config-gc 配置来自动清理非活跃版本，可基于创建时间、最后活跃时间以及非活跃版本数量进行保留策略设置。这两项能力分别针对发布前验证和发布后资源管理，形成了完整的版本生命周期支持。
网关与协议选择：匹配不同业务场景
Knative 支持多种网关，包括 ALB、MSE、ASM 和 Kourier，用户可根据业务需求选择：ALB 侧重应用负载均衡，MSE 面向微服务场景并支持精准弹性，ASM 提供基于 Istio 的服务网格能力，Kourier 则是轻量级基础网关。在协议方面，Knative 支持 HTTP、gRPC 和 WebSocket，并可通过注解同时暴露 HTTP 和 gRPC 服务。这种灵活性意味着用户需要根据自身架构和治理需求评估网关选型，而非默认使用单一方案。
弹性与监控：queue-proxy 的核心角色
Knative 的自动弹性（KPA）和监控均依赖注入每个 Pod 的 queue-proxy 容器。queue-proxy 负责向 Autoscaler 报告并发指标，Autoscaler 根据 Pod 最大并发数和目标使用率计算所需 Pod 数，并支持缩容到 0。同时，queue-proxy 在 9090 和 9091 端口暴露 Prometheus 指标，用于扩缩容决策和应用监控。理解 queue-proxy 的端口分工，有助于排查弹性行为和监控数据来源，是运维 Knative 服务时的关键切入点。
Q&A
Knative 是什么？它主要解决什么问题？
Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架，目标是制定云原生、跨平台的 Serverless 应用编排标准。主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布、函数部署以及事件驱动等。
在 Knative 中如何实现蓝绿发布？与 Kubernetes 原生方式相比有什么优势？
在 Knative 中，蓝绿发布只需面向 Knative Service 一个资源对象，通过调整不同 Revision 的流量比例即可完成。而在 Kubernetes 中，需要管理 Service、Deployment、HPA 和 Ingress 等多种资源，随着版本迭代管理会更复杂。Knative 简化了操作，回滚也只需将新版本流量切回 0，原版本设为 100。
Knative 的 tag 机制有什么作用？如何使用？
tag 机制用于在版本上线前验证新版本。对某个 Revision 打上 tag 后，Knative 会自动生成该 tag 的访问地址（如 http://staging-example-service.default.example.com），通过该地址可以直接访问指定版本进行验证，而不会影响线上流量。
Knative 支持哪些网关？如何选择？
Knative 支持 ALB、MSE、ASM 和 Kourier 网关。ALB 专注于应用负载均衡，提供全托管免运维和自动弹性；MSE 是云原生网关，兼容 K8s Ingress，支持精准自动弹性；ASM 提供基于 Istio 的服务网格能力；Kourier 是轻量级网关，基于 Envoy，支持 gRPC、超时重试等。用户可根据业务场景选择，若仅需基础网关能力可选 Kourier。
Knative 的自动扩缩容（KPA）是如何工作的？Pod 数量如何计算？
Knative 提供基于请求的自动扩缩容 KPA。每个 Pod 注入 queue-proxy 容器，负责向 Autoscaler 报告并发指标。Autoscaler 根据并发请求数、Pod 最大并发数和目标使用率调整 Pod 数量。计算公式为：Pod 数 = 并发请求总数 / (Pod 最大并发数 * 目标使用率)。例如最大并发数 10，目标使用率 0.7，100 个并发请求时创建约 15 个 Pod。当请求为 0 时，可缩容到 0。
Knative 如何实现流量监控？提供了哪些监控指标？
Knative 通过 queue-proxy 采集流量指标，并暴露 Prometheus 指标，包括请求数、并发数、响应时长等。queue-proxy 的 9091 端口暴露应用监控指标，9090 端口供 Autoscaler 采集用于扩缩容。Knative 还集成了 Grafana 大盘，可查看请求量、成功率、4xx/5xx、Pod 扩缩容趋势、响应延迟（P50/P90/P95/P99）、并发数及资源使用量等。
