Knative概述

为什么要在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）、应用集成（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的典型使用场景如下。

使用流程

ACK Knative的使用流程如下图所示。

计费说明

在ACK集群中使用ACK Knative时，ACK Knative本身不收取管理费用，但在使用过程中产生的集群管理费用、所创建的云服务器、负载均衡实例、NAT网关等，按照相应资源的价格计费。更多信息，请参见ACK集群的计费概述、云产品资源费用。

常见问题

如您在使用ACK Knative时遇到问题，可以先参见Knative FAQ自排查。

如果您在使用Knative的过程中有任何疑问或建议，欢迎您搜索钉群号23302777加入钉群。

• 阿里云Knative和社区开源Knative有什么差异

• 安装Knative时，应该选择哪种网关

• 通过RAM用户或角色使用Knative时，需要有什么权限

• Knative中的Pod需要多长时间会缩容至0

• 在Knative中，如何使用GPU资源

• 在Knative中，如何使用共享GPU

• 应用没有流量时Knative默认会将实例数缩容至零，如何解决冷启动延时的问题

• ACK Knative组件的Activator组件是否计费

• Knative服务的监听端口怎么配置

相关文档

• 请及时升级Knative Serving组件，以便享受最新的功能特性和缺陷修复，请参见Knative版本发布说明、升级Knative Serving组件。

• Knative官方文档提供了一个在线书店应用程序教程，带您体验使用Knative构建、部署和监控应用程序的各个步骤，请参见Knative Bookstore Tutorial。