是一款基于Kubernetes集群的Serverless框架，提供了云原生、跨平台的Serverless编排标准。Knative通过整合容器构建、工作负载管理以及事件模型来实现这一Serverless标准，优势如下。
更聚焦于业务逻辑：Knative通过简单的应用配置、自动扩缩容等手段让开发者聚焦于业务逻辑，降低运维负担、减少对底层资源的关注。
标准化：将业务代码部署到Serverless平台时，需要考虑源码的编译、部署和事件的管理。目前社区和云厂商提供的Serverless解决方案和FaaS方案标准不一。Knative提供了一个标准、通用的Serverless框架。
例如，如需在Knative中实现事件驱动，您可以编写对应的YAML文件（CR）并在集群中部署，无需与云产品做深度绑定，便于跨平台迁移。
使用门槛低：Knative支持将代码自动打包为容器镜像并发布为服务，也支持将函数快捷地部署到Kubernetes集群中，以容器的方式运行。
应用管理自动化：Knative支持在没有流量时自动将实例数量缩容至零，从而节省资源，还提供版本管理、灰度发布等功能。
事件驱动：Knative提供了完整的事件模型，便于接入外部系统的事件，并将事件路由到适当的服务或函数进行处理。
Knative包括以下核心组件，分别执行不同的功能。
相较于在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%），那么流量会按照预设的比例进行分发。