作者：李鵬（阿里雲）、魏文哲（束禾科技），本文基於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 擴充套件趨勢、請求響應延遲等。