作者：李鹏（阿里云）、魏文哲（束禾科技），本文基于kubecon China 2023分享整理。
AI服务的数据、训练、推理都消耗了大量的计算资源和运维成本，而在束禾科技的金融业务场景中，模型迭代频繁，会同时在线部署多个版本的模型，以评估模型在线的真实效果， 这是高昂的资源成本。如何在保证服务质量的基础上，提高AI服务运维效率，降低资源成本，是一个具有挑战性的问题。
Knative 是基于 Kubernetes 的开源 Serverless 应用架构，提供基于请求的自动弹性、缩容到 0、灰度发布等功能。 通过 Knative 部署 Serverless 应用，您可以专注于应用逻辑开发，按需使用资源。 因此，将 AI 服务与 Knative 技术相结合可以提高效率并降低成本。
目前，束禾科技通过Knative部署了500+AI模型服务节省 60% 的资源成本，并将平均部署周期从 1 天缩短到 05天。
在本次演讲中，我们将向您展示如何在 Knative 上部署 AI 工作负载，包括：
作为一个开源的容器化编排系统，用户可以使用K8S来降低运维成本，提高运维效率，并且它提供了标准化的API，这意味着K8s是核心的云原生生态系统，可以避免被云厂商的束缚。 根据 CNCF 2021 调查，96% 的企业正在使用或评估 Kubernetes。
随着云原生技术的演进，以应用为中心、按需使用资源的Serverless技术逐渐成为主流。 Gartner**到 2025 年，全球超过 50% 的企业将部署无服务器。
我们知道，以 AWS Lambda 为代表的 Faas 已经将无服务器推向了火线。 Faas确实简化了编程，你只需要写一段话就可以直接运行，不需要开发者关心底层基础设施。 然而，Faas存在明显的不足，包括侵入式开发模式、函数运行时的限制以及对跨云平台的支持。
以k8s为代表的容器技术很好地解决了这些问题。 Serverless 的核心思想是专注于业务逻辑，减少对基础设施的关注。
那么如何为开发者提供基于 K8s 开放标准的 Serverless 容器技术呢？答案是：knative。
knative的发展轨迹
Knative 是一个基于 Kubernetes 的开源无服务器容器编排框架，于 2018 年在 Google Cloud Next 上发布。 目标是开发云原生、跨平台的 Serverless 应用编排标准，构建企业级 Serverless 平台。 阿里云容器服务也早在 2019 年就提供了 Knative 产品化能力，随着 2022 年 3 月 CNCF 的加入，越来越多的开发者开始拥抱 Knative。
knative 概述
knative核心模块主要包括：为工作负载部署服务和事件驱动的框架事件。
Knative Serving 的核心竞争力是其简单高效的应用程序托管服务，这也是其 Serverless 能力的基础。 Knative 可以根据应用的请求量，在高峰期自动扩容实例数量，并在请求量减少时自动缩容实例数量，帮助您自动节省成本。
Knative 中的事件提供了一个完整的事件模型。 事件被访问后，通过CloudEvent标准在内部流通，并结合Broker触发机制，为事件处理提供了一种非常理想的方式。
knative 应用程序模型
knative 应用模型是 knative service：
knative 服务由 2 个配置部分组成，一个用于配置工作负载，称为配置，每次更新配置内容时都会创建一个新的修订版。 路由的另一部分主要负责knative的流量管理。 
让我们来看看基于流量的灰度发布可以做什么：
假设我们在一开始就创建了一个 v1 版本的 revison，如果有新的版本变更，那么我们只需要更新服务中的配置，然后我们可以通过 route 为 v1 和 v2 设置不同的流量比例，其中 v1 是 70%，v2 是 30%，那么流量会按照 7：3 的比例分配到这两个版本。 一旦新的 v2 版本没有问题，那么我们可以通过调整比例来继续灰度，直到新的 v2 版本达到 100%。 在这个灰度过程中，一旦发现新版本异常，可以通过调整比例来回滚操作。
另外，我们可以在路由中对 revion 进行 taged，在对 tag 进行 revis 之后，我们可以直接通过 URL 进行单独的版本测试，可以理解为灰度验证，这个版本的调试不会影响对流量的正常访问。
基于请求的自动复原能力：kpa
为什么要执行基于请求的自动复原？
基于 CPU 或内存的弹性有时并不能完全反映业务的实际使用情况，但基于并发事务数或每秒处理的请求数（QPS RPS），对于 Web 服务来说，可以更直接地反映服务性能，Knative 提供了基于请求的自动弹性。
如何收集指标？
为了获取当前服务的请求数，knative serving 会向每个 pod 注入一个队列容器（queue-proxy），该容器负责收集用户容器并发（concurrency）或请求（rps）指标。 AutoScaler 定期获取这些指标后，会根据相应的算法调整部署的 Pod 数量，实现基于请求的自动伸缩。
弹性 Pod 是如何计算的？
Autoscaler 根据每个 Pod 的平均请求数（或并发数）计算所需的 Pod 数。 默认情况下，knative 会根据并发数使用自动弹性，默认 Pod 最多 100 个并发。 此外，knative 中还有一个概念叫做 target-utilization-percentage，称为 target utilization。
例如，基于并发弹性，Pod 的数量计算如下：
Pod 数量 = 并发请求总数（最大并发 Pod 数量×目标使用量）。Knative 中定义了 2 种请求访问模式：代理和 serve。 顾名思义，**模式，即请求会通过激活器组件进行 ***serve mode 是请求直接模式，从网关直接请求到 pod，不经过激活器，如下图所示：
模式切换由自动缩放器组件处理，当请求为 0 时，自动缩放器将请求模式切换为代理模式。 此时会通过网关向 Activator 组件请求请求，Activator 在收到请求后会将请求放入队列中，同时推送指示器通知 autoscaler 扩容，当 Activator 检测到准备扩容的 pod 时， 它将立即发出请求。
响应突发的流量
突发流量下如何快速弹出资源
这里 KPA 涉及到 2 个与弹性相关的概念：稳定模式和 panic 模式，基于这两种模式，我们可以看到 KPA 如何快速反弹资源。
首先，稳定模式基于稳定窗口，默认为 60 秒。 也就是说，计算 60 秒内 Pod 并发的平均数。
另一方面，恐慌模式基于恐慌窗口，该窗口由稳定窗口和 panic-window-percentage 参数计算。 恐慌窗口的计算公式如下：恐慌窗口 = 稳定窗口 *恐慌窗口百分比。 默认情况下，它是 6 秒。 计算 6 秒内并发的平均 Pod 数。
KPA 根据 Pod 在稳定模式和 panic 模式下的平均并发数计算所需的 Pod 数量。
那么哪个值实际上是基于弹性效应的呢？这里会根据panic模式下计算的pod数量是否超过panic阈值来判断。 默认情况下，当 panic 模式下计算的 pod 数量大于等于当前就绪 Pod 数量的 2 倍时，将使用 panic 模式下的 Pod 数量进行弹性效果，否则将使用稳定模式下的 Pod 数量。
显然，紧急模式旨在应对流量激增。 至于弹性灵敏度，可以通过上述可配置参数进行调整。
如何防止 Pod 在突发流量中被炸毁
在 KPA 中，您可以设置 target-burst-capacity，以防 Pod 出现意外流量。 即通过对该参数值的计算，将请求调整为切换到代理模式，这样在面对突发流量时，将激活器组件作为请求缓冲区，避免 Pod 被炸毁。
减少冷启动的一些技巧
延迟缩减
对于启动成本较高的 Pod，您可以通过在 KPA 中将 Pod 延迟缩容时间和 Pod 缩容设置为 0 保留期来降低 Pod 伸缩的频率。
降低目标利用率，实现资源预热
目标阈值使用情况的配置在 knative 中可用。 通过减小该值，可以提前扩展超出实际所需使用量的 Pod 数量，并在请求到达目标并发之前扩展容量，从而间接实现资源预热。
弹性策略配置
通过上面的介绍，我们对 knative pod autoscaler 的工作原理有了进一步的了解，那么我们来介绍一下如何配置 kpa。 在 knative 中配置 KPA 有两种方式：全局模式和修订模式。 全局模式可以通过 configmap：config-autoscaler 使用以下参数进行配置：
阿里云容器服务Kubernetes版
开源产品一般不能直接用于产品化。 Knative 产品化存在的问题包括：
管控组件多、运维复杂、算力多样，如何解决云产品层面可按需调度到不同资源规格的网关能力冷启动问题。 为了解决这些问题，我们提供了容器服务（KNATIVE）。 完全兼容社区 Knative，支持 AI 推理框架 Kserve。 通过支持预留资源池、精准弹性和弹性**来增强弹性;支持完全托管的 ALB、MSE 和 ASM 网关事件驱动方面与云产品 EventBridge 集成;此外，它还与阿里云的其他产品（如ECI、ARMS和日志服务）完全集成。
预留资源池
除了原生 KPA 功能之外，我们还提供了预留资源池的功能。 该功能可应用于以下场景：
ECS 与 ECI 混合使用。 如果我们想在正常情况下使用 ECS 资源，将 ECI 用于突发流量，那么我们可以通过预留资源池来实现。 一般情况下，ECS资源用于承载流量，新扩容的资源用于ECI进行突发流量。 资源预热。 对于完全使用 ECI 的场景，也可以通过预留资源池来实现资源预热。 当默认计算实例在业务低谷期被较低规格的预留实例替换时，在第一次请求到来时临时使用预留实例提供服务，并触发默认规格实例的伸缩。 默认规范的实例扩容后，所有新请求都将应用于默认规范，然后该实例将下线并保留。 这种无缝替换实现了成本和效率之间的平衡，从而降低了常驻实例的成本，而无需长时间的冷启动。 精确的弹性
单个 Pod 处理请求的吞吐率是有限的，如果向同一个 Pod 发送多个请求，会导致服务器端出现过载异常，因此需要准确控制单个 Pod 请求的并发处理次数。 特别是在一些AIGC场景下，单个请求会占用大量的GPU资源，需要严格限制每个Pod可以并发处理的请求数量。
结合 MSE 云原生网关，Knative 提供了一种基于并发数精确控制弹性的实现：MPA 弹性插件。
MPA 会从 MSE 网关获取并发，计算扩缩容所需的 Pod 数量，待 Pod 准备就绪后，MSE 网关会向对应的 Pod 请求 **。
弹性**
容器服务AHP可以自动识别弹性周期，并根据历史业务指标进行容量更新，解决弹性滞后问题。
目前 Knative 支持 Advanced Horizontal Pod Autoscaler（AHPA）的弹性能力，可以在请求周期性时通过弹性预热资源。 与降低资源变暖阈值相比，AHPA可以最大限度地提高资源利用率。
使用AHPA，您可以做到：
提前准备资源：在请求到达之前，提前扩展 稳定可信：准备的 RPS 吞吐量足以覆盖实际请求数。
事件驱动
Knative中提供了Eventing，事件流转和分发是通过Eventing中的Broker触发器进行的。
但是直接使用本机事件存在一些问题：
如何覆盖足够的事件源，以及如何确保事件在事件流过程中不会丢失。
如何构建生产级事件驱动功能？我们与阿里云 EventBridge 相结合。
EventBridge 是阿里云提供的 Serverless 事件总线服务阿里云的 Knative Eventing 集成了 EventBridge，为 Knative Eventing 提供云产品级的事件驱动能力。
那么，在实际业务场景中，我们该如何使用knative呢？我们能给 Knative 带来什么好处？接下来，我将为大家介绍束河科技使用knative的最佳实践。
舒禾科技（全称“上海舒禾信息科技”）成立于2024年8月，以大数据和技术为驱动，为金融机构提供高效的智慧零售金融解决方案，涵盖消费信贷、小微企业授信、场景舞台等领域，提供营销和获客、风险防控、运营管理等服务。
舒禾科技旗下的环北APP是一款基于多种消费场景的分期付款服务平台，于2024年2月正式进入市场。 通过与持牌金融机构合作，向公众提供个人消费信贷服务，为小微企业主提供贷款融资支持。 截至2024年6月，环北累计活跃用户13亿，为1700万用户提供合理的信用服务，帮助用户“借得好，还得好”。
模型发布痛点
在模型的在线阶段，资源被浪费了。
为了保证我们服务的稳定性，一般都会预留缓冲区，资源通常会按照超出我们实际使用情况的规格进行预留。 创建的资源在整个时间段内资源并不满，你会看到一些应用在线，尤其是一些离线作业类型的应用，大多数时候整个CPU和内存使用率非常低，只有在一定时间段资源使用率才会上升，并且有明显的潮汐现象。 由于资源的使用缺乏足够的弹性，往往会导致大量的资源浪费。
模型离线阶段资源困难的问题。
一个模型可能有多个版本。 使用不同的版本在线评估模型的真实性能，如果一个版本评估得不好，那么该版本将从决策过程中删除。 此时，模型实际上不再提供服务，如果不能及时下线资源，就会造成资源浪费。
对持续交付技术架构进行建模
模型平台部分。
模型平台生成模型文件，然后将模型文件注册到BetterCDS
BetterCDS 将生成与此模型文件对应的工件。
您可以使用工件完成模型发布和模型版本管理。
Knative 管理模块。
配置模型的全局 knative 扩展配置。
每个模型都可以为 knative 配置自己的弹性扩展配置。
CI 管道。
CI 流水线的主要流程是通过 Dockerfile 拉取模型文件并构建模型镜像。
部署过程。 流水线更新 knative 服务，设置路由版本和镜像地址，更新 knative 的弹性扩展配置，knative 会生成对应工件版本的修订版
Knative 服务更新过程。
如果所有 Pod 都准备就绪，则认为该版本部署成功，部署成功后，使用标签进行修订以创建版本路由。
该模型的多个版本发布
模型的多版本工件发布是通过 knative 的配置实现的：
1.工件的多个版本对应于配置的修订版本。
2.工件包含一个模型版本镜像，该镜像是通过更新 knative 服务的镜像版本生成的，该镜像版本由工件的相应修订版生成。
模型多版本服务共存能力：
1.通过标签创建版本路由进行修订，并根据不同的路由调用不同的版本服务。
2.由于同时存在多个版本，因此可以在决策过程中调用不同的模型版本来观察模型效果，并且由于存在多个路由版本，因此可以支持多个流量策略。
它还支持一组最新路由，可以在不改变决策流程的情况下切换到最新路由的任何版本，完成在线流量的切换。
基于请求的轰炸
为什么模型会采用基于请求数的弹出策略？
1.大多数模型都是计算密集型的，模型的 CPU 使用率与请求数呈正相关，因此一旦请求激增，CPU 就会满，最终服务会崩溃。
2.除了基于请求的扩缩容外，还有基于 CPU 和内存指标的 HPA 扩缩容，但 HPA 扩缩容也存在以下问题：
a.指标的弹性扩容环节较长：从服务暴露指标Prometheus中采集指标，指标上升，然后HPA根据指标计算出需要扩容的Pod数量，然后开始扩容Pod，整体弹性扩容环节比较长。
b.指标不准确：例如，j**a 的 GC 会导致内存周期性变化。
c.指标并不能反映服务的真实状态：当指标上升时，响应延迟已经很高了，也就是说，如果指标发现超过阈值，则已经延迟了，然后开始扩容 Pod，等到 Pod 准备就绪时，已经延迟了。
3.因此，我们需要提前扩容时间，利用请求数来触发模型扩容，以保证模型服务能够保持正常的服务状态。
以下是修订版本请求在 100%-0% 之间的工作方式。
knative炸弹扩展环节如下：
1.流量从服务请求到 Pod。
2.PodAutoscaler 实时收集 Pod 中的 queue-proxy 流量请求指标，并根据当前请求计算可扩容的 Pod 数量。
3.podautoscaler 控制部署以扩展 pod，并将 pod 添加到服务中，从而完成 pod 扩展。
与指标弹性扩容相比，基于请求的弹性扩容策略响应更快，灵敏度更高。 能够保证服务的响应能力。 针对以往资源离线的痛点，由于支持可以缩容到 0，我们可以将修订的最小 Pod 数量调整为 0，如果没有请求，会自动缩容为 0。 结合弹性节点，伸缩到0不再占用资源，也实现了模型服务的Serverless能力。
BetterCDS一站式模型发布
模型通过流水线部署，以下是bettercds发布流水线的分步流程。
部署版本步骤：触发 knative 模型的部署。 新建路由：新增Knative版本的路由。 更新最新路由：如果要将最新路由作为管道的参数进行更新，可以选择在部署完成的同时更新最新路由。 通过knative弹性扩容配置管理模块，可以配置每个模型的全局弹性配置和版本弹性配置。
集束炸弹扩展架构
容器应用运行在我们的ACK和虚拟节点集群上，ECS和弹性节点混合，平时的业务由按月付费的ECS节点承载，弹性服务由付费的弹性节点承载，可以低成本实现高弹性。 基于虚拟节点的弹性能力，既满足弹性要求，又避免了资源浪费，降低了使用成本。
1.ACK维护固定节点资源池，根据常驻Pod和常规业务量预留节点，订阅成本更低。
2.虚拟节点运行弹性实例，提供弹性能力，因为不需要关心节点，可以根据需要进行扩容。
弹性可以轻松处理流量激增以及高峰和低谷。
3.对于离线任务对实时性要求不高的作业和业务，由于是周期性的，不会一直占用资源，成本优势高。
4.免运维：弹性节点、Pod 用完后销毁。
结果优势
从资源和流量请求的曲线可以看出，我们的资源有高峰也有低谷，并且有明显的周期性，当请求量增加时，Pod 使用率增加，当请求减少时，Pod 使用率下降。 集群中 Pod 的峰值数量接近 2000 个与过去相比，成本降低了约60%，并且节省了大量资源。
得益于 knative 的多版本发布能力，发布效率也得到了提升，从过去的几小时缩短到几分钟。 舒和的knative模型实践也得到了权威认证被中国信息通信研究院云原生产业联盟评选为“云原生应用优秀案例”。
Knative 与 AIGC
cloud native
作为AIGC领域的知名项目，Stable Diffusion可以帮助用户快速、准确地生成想要的场景和**。 然而，目前在k8s中直接使用稳定扩散面临以下问题：
单个 Pod 处理请求的吞吐率是有限的，如果向同一个 Pod 发送多个请求，会导致服务器端出现过载异常，因此需要准确控制单个 Pod 请求的并发处理次数。 GPU资源弥足珍贵，期望在业务低谷期能够按需使用，及时释放资源。 基于以上两个问题，我们可以通过 knative 实现基于并发的精准弹性，在资源不使用时缩容到 0。
此外，knative 还提供开箱即用的可观测性**，可以查看请求数量、请求成功率、Pod 扩展趋势、请求响应延迟等。