Knative是一款基于Kubernetes的Serverless框架，支持基于请求的自动弹性、在没有流量时将实例数量自动缩容至零、版本管理与灰度发布等能力。在完全兼容社区Knative和Kubernetes API的基础上，ACK Knative进行了多维度的能力增强，例如通过保留实例降低冷启动时间、基于AHPA实现弹性预测等。
为什么要在Kubernetes集群中使用Knative
Knative介绍
Knative是一款基于Kubernetes集群的Serverless框架，提供了云原生、跨平台的Serverless编排标准。Knative通过整合容器构建、工作负载管理以及事件模型来实现这一Serverless标准，优势如下。
更聚焦于业务逻辑：Knative通过简单的应用配置、自动扩缩容等手段让开发者聚焦于业务逻辑，降低运维负担、减少对底层资源的关注。
标准化：将业务代码部署到Serverless平台时，需要考虑源码的编译、部署和事件的管理。目前社区和云厂商提供的Serverless解决方案和FaaS方案标准不一。Knative提供了一个标准、通用的Serverless框架。
例如，如需在Knative中实现事件驱动，您可以编写对应的YAML文件（CR）并在集群中部署，无需与云产品做深度绑定，便于跨平台迁移。
使用门槛低：Knative支持将代码自动打包为容器镜像并发布为服务，也支持将函数快捷地部署到Kubernetes集群中，以容器的方式运行。
应用管理自动化：Knative支持在没有流量时自动将实例数量缩容至零，从而节省资源，还提供版本管理、灰度发布等功能。
事件驱动：Knative提供了完整的事件模型，便于接入外部系统的事件，并将事件路由到适当的服务或函数进行处理。
核心组件
Knative包括以下核心组件，分别执行不同的功能。
Knative Serving：管理Serverless工作负载，提供了应用部署、多版本管理、基于请求的自动弹性、灰度发布等能力，而且在没有业务流量时可以将应用实例缩容至零。
Knative Eventing：提供了事件源的接入、事件注册和订阅、以及事件过滤等一整套事件管理的能力。事件模型可以有效地解耦生产者和消费者的依赖关系。
Knative Functions: 提供了一个简单的方式来创建、构建和部署Knative服务。您无需深入了解底层技术栈（例如Kubernetes、容器、Knative），通过使用Knative Functions，即可将无状态、事件驱动的函数作为Knative服务部署到Kubernetes集群中。
功能特性
相较于在Kubernetes集群不使用Knative，使用Knative能帮您以更简便的方式实现如下功能特性。
基于请求的自动弹性
基于CPU或者Memory的弹性有时并不能完全反映业务的真实使用情况。对于Web服务来说，基于并发数（QPS）或者每秒处理请求数（RPS）进行弹性伸缩更能直接反映服务性能。Knative Serving会为每个Pod注入queue-proxy容器，收集容器并发数（Concurrency）或请求数（RPS）指标。Autoscaler定时获取指标后，会根据相应的算法自动调整Deployment的Pod数量，从而实现基于请求的自动扩缩容。
如果在ACK集群中实现相应的操作，您需要分别创建Deployment、Service，配置Ingress网关，然后配置HPA参数。而使用Knative服务时，您只需要部署Knative并配置Knative服务的YAML文件。
在没有流量时将实例数量自动缩容至零
Knative支持在应用无流量请求时将Pod数量自动缩容至0，并在有请求时自动扩容Pod。Knative中定义了两种请求访问模式：Proxy（代理模式）和Serve（请求直达模式）。模式的切换由Autoscaler组件负责。当请求为0时，Autoscaler会将请求模式切换为Proxy模式。当有请求访问时，Autoscaler会收到通知进行扩容，扩容的Pod状态变为Ready后对请求进行转发，此时Autoscaler会将访问模式切换为Serve模式。
版本管理与灰度发布
创建Knative服务时底层会自动创建一个Configuration资源和一个Route资源。
Configuration：当前期望状态的配置。每次更新Service就会更新Configuration，Configuration的更新会创建一个唯一的Revision。Revision相当于Configuration的版本管理机制。
Route：负责将请求路由到Revision，并可以向不同的Revision转发不同比例的流量。
基于以上特性，您可以使用Revision进行版本的管理，例如版本的回退。您还可以进行流量的灰度发布，例如创建了V1版本的Revision后，当版本需要变更时可以更新服务的Configuration，创建V2版本的Revision，通过Route对V1、V2设置不同的流量比例（例如V1为70%，V2是30%），那么流量会按照预设的比例进行分发。
事件驱动
Knative通过Eventing提供了完整的事件模型，便于接入外部系统（例如GitHub、消息队列等）的事件，并将事件路由到适当的Knative服务或函数进行处理。
为什么要使用ACK Knative
在完全兼容社区Knative并提供标准Kubernetes API接口的基础上，ACK Knative进一步增强产品化能力并提供了更丰富的产品方案。
产品化的能力：提供产品化一键部署能力，您无需购买资源搭建系统。同时提供产品控制台，支持白屏化操作，降低Kubernetes集群和Knative的使用门槛。
简化运维：
核心组件托管：在ACK集群中，Knative的核心组件Knative Serving和Knative Eventing均由ACK创建和托管，无需您承担资源费用，且提供高可用保障。
网关托管：ACK Knative提供ALB、MSE、ASM和Kourier四种网关。除社区兼容的Kourier外，其余三种云产品网关的Controller均由ACK创建，提供全托管、免运维的网关服务。
生态集成：无缝集成了阿里云的计算（ECI、ECS）、可观测（日志服务SLS、Prometheus）、CI/CD（云效）、应用集成（EventBridge）等产品。您无需自行采购服务器，也无需自建服务，便能在Knative服务中实现日志与监控告警、持续交付、事件驱动等能力。
更丰富的功能特性：在社区Knative的基础上，ACK Knative结合实际业务场景提供了开箱即用的、更为丰富的产品方案。例如以下方案。
保留实例：在应用没有流量时，社区Knative默认将应用实例数缩容至零以降低成本，从而导致应用重新启动时会经历较长的冷启动时间。如果您的应用对冷启动延时较为敏感，推荐使用此功能，保留一个低规格的突发性能实例，平衡好使用成本和启动时长。
Knative自动伸缩： 除提供开箱即用的HPA、KPA（Knative Pod Autoscaler）外，您还可以为Knative服务配置AHPA（Advanced Horizontal Pod Autoscaler）弹性能力。如果您的应用所需资源具备周期性变化，推荐您使用AHPA进行弹性预测，提前预热所需的资源，缓解使用Knative时遇到的冷启动问题。
关于ACK Knative和社区Knative对比的更多信息，请参见阿里云Knative和开源Knative对比。
使用场景
ACK Knative的典型使用场景如下。
业务场景 | 说明 |
Web服务的托管 |
|
Serverless应用 |
|
AI场景 |
|
事件驱动场景 | Knative Eventing提供了完整的事件模型，简化了接入外部系统的事件的流程。例如，IoT设备可以将传感器数据发送到Knative服务中，ACK Knative可以配置对应的事件源用于接收数据，并触发相应的处理逻辑，例如数据存储、实时分析、监控告警等。 |
ACK Knative的使用流程
ACK Knative的使用流程如下图所示。
流程 | 说明 |
前提条件 | |
在控制台一键部署ACK Knative，安装Knative Serving组件。具体操作，请参见部署Knative。 | |
完成网关选型并部署网关。ACK Knative支持ALB、MSE、ASM、Kourier四种网关。详细信息，请参见Knative网关选型建议。
| |
服务部署与管理 | 指定使用的资源类型：
|
自动伸缩：
| |
版本管理与灰度发布：
| |
Knative服务的访问：
| |
进阶功能 | 事件驱动：在满足云原生开发的常见需求的基础上，Knative Eventing提供了完整、系统的Serverless事件驱动模式，包括外部事件源的接入、事件流转和订阅、以及对事件的过滤等功能。ACK Knative直接丰富的事件源，包括GitHub、EventBridge等。请参见事件驱动概述。 |
Knative Functions：简化在Kubernetes集群中创建、部署和调用函数的流程，请参见部署Knative Functions。 | |
AI推理服务： KServe提供了一个基于Kubernetes集群的机器学习模型服务框架，提供简单的Kubernetes CRD，可将单个或多个经过训练的模型（例如TFServing、TorchServe、Triton等推理服务器）部署到模型服务运行时。您可以部署KServe组件并基于KServe快速部署一个推理服务。 同时，ACK提供了在Knative中部署AI模型推理服务的最佳实践，例如如何加速模型部署、如何配置GPU共享调度等，请参见在Knative中部署AI模型推理服务的最佳实践。 | |
服务网格：如果您需要在Knative服务中集成服务网格，以实现复杂的流量管理并增强服务安全性，推荐您使用服务网格ASM，请参见什么是服务网格ASM？。 | |
可观测性与成本管理 | 日志采集：您可以在Knative服务中使用SLS，无需开发便能快捷完成日志数据采集、消费、投递以及查询分析等功能，请参见在Knative上实现日志采集。 |
监控大盘：您可以把Knative接入阿里云Prometheus监控，便于查看Knative的响应延迟、请求并发数等数据，请参见查看Knative服务监控大盘。 | |
监控告警：您可以使用SLS创建日志告警监控规则，请参见为Knative服务开启监控告警。 | |
成本洞察：作为企业IT成本管理人员，您可以为Knative服务启用成本洞察功能，了解Knative服务的资源使用量及成本分布，请参见启用Knative服务成本洞察。 |
相关计费
在ACK集群中使用ACK Knative时，ACK Knative本身不收取管理费用，但在使用过程中产生的集群管理费用、所创建的云服务器、负载均衡实例、NAT网关等，按照相应资源的价格计费。更多信息，请参见ACK集群的计费说明、云产品资源计费。
常见问题
如您在使用ACK Knative时遇到问题，可以先参见Knative FAQ完成自排查。
客户案例
灵伴科技（Rokid）是一家专注于人机交互技术的产品平台公司，基于ACK Knative方案部署了其在线服务系统，实现了多版本管理以加快应用迭代、基于请求的自动扩缩容以精准调配GPU资源等能力，实现了运维、成本和性能之间的平衡。更多信息，请参见灵伴科技（Rokid）借助 Knative 实现 AI 应用云原生 Serverless 化。
XTransfer是一站式外贸企业跨境金融和风控服务公司，基于ACK Knative方案搭建了DevOps平台，实现了算法模型的Serverless部署。在DevOps平台上，算法工程师可以创建待上线模型版本、定义推理脚本、指定模型服务所需资源（最小副本数、所需的GPU资源、所需的内存资源等），并最终完成模型的发布。更多信息，请参见云原生 Knative 组件助力 XTransfer 加速应用云原生 Serverless 化。
深圳硅基仿生科技股份有限公司是一家创新医疗器械研发与产业化公司，采用ACK Knative方案加速了深度学习模型的性能提升，同时降低了服务部署成本。更多信息，请参见硅基仿生业务全面 Serverless 容器化的增效降本之旅。
联系我们
如果您在使用Knative的过程中有任何疑问或建议，欢迎您搜索钉群号23302777加入钉群。
相关文档
请及时升级Knative Serving组件，以便享受最新的功能特性和缺陷修复。建议您在业务低峰期进行升级。更多信息，请参见Knative版本发布说明、升级Knative Serving组件。
Knative官方文档提供了一个在线书店应用程序教程，带您体验使用Knative构建、部署和监控应用程序的各个步骤，请参见Knative Bookstore Tutorial。