Knative是一款基于Kubernetes的Serverless框架，支持基于請求的自動彈性、在沒有流量時將實例數量自動縮容至零、版本管理與灰度發(fā)布等能力。在完全兼容社區(qū)Knative和Kubernetes API的基礎上，ACS Knative進行了多維度的能力增強，例如通過保留實例降低冷啟動時間、基于AHPA實現彈性預測等。
為什么要在Kubernetes集群中使用Knative
Knative介紹
Knative是一款基于Kubernetes集群的Serverless框架，提供了云原生、跨平臺的Serverless編排標準。Knative通過整合容器構建、工作負載管理以及事件模型來實現這一Serverless標準，優(yōu)勢如下。
更聚焦于業(yè)務邏輯：Knative通過簡單的應用配置、自動擴縮容等手段讓開發(fā)者聚焦于業(yè)務邏輯，降低運維負擔、減少對底層資源的關注。
標準化：將業(yè)務代碼部署到Serverless平臺時，需要考慮源碼的編譯、部署和事件的管理。目前社區(qū)和云廠商提供的Serverless解決方案和FaaS方案標準不一。Knative提供了一個標準、通用的Serverless框架。
例如，如需在Knative中實現事件驅動，您可以編寫對應的YAML文件（CR）并在集群中部署，無需與云產品做深度綁定，便于跨平臺遷移。
使用門檻低：Knative支持將代碼自動打包為容器鏡像并發(fā)布為服務，也支持將函數快捷地部署到Kubernetes集群中，以容器的方式運行。
應用管理自動化：Knative支持在沒有流量時自動將實例數量縮容至零，從而節(jié)省資源，還提供版本管理、灰度發(fā)布等功能。
事件驅動：Knative提供了完整的事件模型，便于接入外部系統(tǒng)的事件，并將事件路由到適當的服務或函數進行處理。
核心組件
Knative包括以下核心組件，分別執(zhí)行不同的功能。
Knative Serving：管理Serverless工作負載，提供了應用部署、多版本管理、基于請求的自動彈性、灰度發(fā)布等能力，而且在沒有業(yè)務流量時可以將應用實例縮容至零。
Knative Eventing：提供了事件源的接入、事件注冊和訂閱、以及事件過濾等一整套事件管理的能力。事件模型可以有效地解耦生產者和消費者的依賴關系。
Knative Functions: 提供了一個簡單的方式來創(chuàng)建、構建和部署Knative服務。您無需深入了解底層技術棧（例如Kubernetes、容器、Knative），通過使用Knative Functions，即可將無狀態(tài)、事件驅動的函數作為Knative服務部署到Kubernetes集群中。
功能特性
相較于在Kubernetes集群不使用Knative，使用Knative能幫您以更簡便的方式實現如下功能特性。
基于請求的自動彈性
基于CPU或者Memory的彈性有時并不能完全反映業(yè)務的真實使用情況。對于Web服務來說，基于并發(fā)數（QPS）或者每秒處理請求數（RPS）進行彈性伸縮更能直接反映服務性能。Knative Serving會為每個Pod注入queue-proxy容器，收集容器并發(fā)數（Concurrency）或請求數（RPS）指標。Autoscaler定時獲取指標后，會根據相應的算法自動調整Deployment的Pod數量，從而實現基于請求的自動擴縮容。
如果在ACS集群中實現相應的操作，您需要分別創(chuàng)建Deployment、Service，配置Ingress網關，然后配置HPA參數。而使用Knative服務時，您只需要部署Knative并配置Knative服務的YAML文件。
在沒有流量時將實例數量自動縮容至零
Knative支持在應用無流量請求時將Pod數量自動縮容至0，并在有請求時自動擴容Pod。Knative中定義了兩種請求訪問模式：Proxy（代理模式）和Serve（請求直達模式）。模式的切換由Autoscaler組件負責。當請求為0時，Autoscaler會將請求模式切換為Proxy模式。當有請求訪問時，Autoscaler會收到通知進行擴容，擴容的Pod狀態(tài)變?yōu)镽eady后對請求進行轉發(fā)，此時Autoscaler會將訪問模式切換為Serve模式。
版本管理與灰度發(fā)布
創(chuàng)建Knative服務時底層會自動創(chuàng)建一個Configuration資源和一個Route資源。
Configuration：當前期望狀態(tài)的配置。每次更新Service就會更新Configuration，Configuration的更新會創(chuàng)建一個唯一的Revision。Revision相當于Configuration的版本管理機制。
Route：負責將請求路由到Revision，并可以向不同的Revision轉發(fā)不同比例的流量。
基于以上特性，您可以使用Revision進行版本的管理，例如版本的回退。您還可以進行流量的灰度發(fā)布，例如創(chuàng)建了V1版本的Revision后，當版本需要變更時可以更新服務的Configuration，創(chuàng)建V2版本的Revision，通過Route對V1、V2設置不同的流量比例（例如V1為70%，V2是30%），那么流量會按照預設的比例進行分發(fā)。
事件驅動
Knative通過Eventing提供了完整的事件模型，便于接入外部系統(tǒng)（例如GitHub、消息隊列等）的事件，并將事件路由到適當的Knative服務或函數進行處理。
為什么要使用ACS Knative
在完全兼容社區(qū)Knative并提供標準Kubernetes API接口的基礎上，ACS Knative進一步增強產品化能力并提供了更豐富的產品方案。
產品化的能力：提供了產品化一鍵部署能力，您無需購買資源搭建系統(tǒng)。同時提供產品控制臺，支持白屏化操作，降低Kubernetes集群和Knative的使用門檻。
簡化運維：
核心組件托管：在ACS集群中，Knative的核心組件Knative Serving和Knative Eventing均由ACS創(chuàng)建和托管，無需您承擔資源費用，且提供高可用保障。
網關托管：ACS Knative提供ALB、MSE、ASM和Kourier四種網關。除社區(qū)兼容的Kourier外，其余三種云產品網關的Controller均由ACS創(chuàng)建，提供全托管、免運維的網關服務。
生態(tài)集成：無縫集成了阿里云的計算、可觀測（日志服務SLS、Prometheus）、CI/CD（云效）、應用集成（EventBridge）等產品。您無需自行采購服務器，也無需自建服務，便能在Knative服務中實現日志與監(jiān)控告警、持續(xù)交付、事件驅動等能力。
更豐富的功能特性：在社區(qū)Knative的基礎上，ACS Knative結合實際業(yè)務場景提供了開箱即用的、更為豐富的產品方案。例如以下方案。
保留實例：在應用沒有流量時，社區(qū)Knative默認將應用實例數縮容至零以降低成本，從而導致應用重新啟動時會經歷較長的冷啟動時間。如果您的應用對冷啟動延時較為敏感，推薦使用此功能，保留一個低規(guī)格的突發(fā)性能實例，平衡好使用成本和啟動時長。
Knative自動伸縮： 除提供開箱即用的HPA、KPA（Knative Pod Autoscaler）外，您還可以為Knative服務配置AHPA（Advanced Horizontal Pod Autoscaler）彈性能力。如果您的應用所需資源具備周期性變化，推薦您使用AHPA進行彈性預測，提前預熱所需的資源，緩解使用Knative時遇到的冷啟動問題。
關于ACS Knative和社區(qū)Knative對比的更多信息，請參見阿里云Knative和開源Knative對比。
使用場景
ACS Knative的典型使用場景如下。
業(yè)務場景 | 說明 |
Web服務的托管 |
|
Serverless應用 |
|
AI場景 |
|
事件驅動場景 | Knative Eventing提供了完整的事件模型，簡化了接入外部系統(tǒng)的事件的流程。例如，IoT設備可以將傳感器數據發(fā)送到Knative服務中，ACS Knative可以配置對應的事件源用于接收數據，并觸發(fā)相應的處理邏輯，例如數據存儲、實時分析、監(jiān)控告警等。 |
ACS Knative的使用流程
流程 | 說明 |
前提條件 | 已在ACS集群中部署Knative。具體操作，請參見部署Knative。 |
在控制臺一鍵部署ACS Knative，安裝Knative Serving組件。具體操作，請參見管理Knative組件。 | |
完成網關選型并部署網關。ACS Knative支持ALB、MSE、ASM、Kourier四種網關。詳細信息，請參見Knative網關選型建議。
| |
服務部署與管理 | 自動伸縮：
|
版本管理與灰度發(fā)布：
| |
Knative服務的訪問：
| |
進階功能 | 事件驅動：在滿足云原生開發(fā)的常見需求的基礎上，Knative Eventing提供了完整、系統(tǒng)的Serverless事件驅動模式，包括外部事件源的接入、事件流轉和訂閱、以及對事件的過濾等功能。ACS Knative直接豐富的事件源，包括GitHub、EventBridge等。請參見事件驅動概述。 |
Knative Functions：簡化在Kubernetes集群中創(chuàng)建、部署和調用函數的流程，請參見部署Knative Functions。 | |
AI推理服務： KServe提供了一個基于Kubernetes集群的機器學習模型服務框架，提供簡單的Kubernetes CRD，可將單個或多個經過訓練的模型（例如TFServing、TorchServe、Triton等推理服務器）部署到模型服務運行時。您可以部署KServe組件并基于KServe快速部署一個推理服務。 | |
服務網格：如果您需要在Knative服務中集成服務網格，以實現復雜的流量管理并增強服務安全性，推薦您使用服務網格ASM，請參見在Knative on ASM中基于流量灰度發(fā)布服務。 | |
可觀測性與成本管理 | |
監(jiān)控大盤：您可以把Knative接入阿里云Prometheus監(jiān)控，便于查看Knative的響應延遲、請求并發(fā)數等數據，請參見查看Knative服務監(jiān)控大盤。 | |
相關計費
在ACS集群中使用ACS Knative時，ACS Knative本身不收取管理費用，但在使用過程中產生的負載均衡實例、NAT網關等，按照相應資源的價格計費。更多信息，請參見ACS集群的計費說明。
常見問題
如您在使用ACS Knative時遇到問題，可以先參見Knative FAQ完成自排查。
客戶案例
數禾科技以大數據和技術為驅動，為金融機構提供高效的智能零售金融解決方案。為了解決支撐模型計算的底層應用資源無法靈活且快速地根據請求量調整算力等問題，數禾科技采用ACK + Knative的方式來部署模型服務，實現了根據請求的擴縮容能力、允許Pod縮容到0以及多版本管理的能力。更多信息，請參見數禾科技 AI 模型服務基于阿里云容器服務實現 Serverless 容器化。
靈伴科技（Rokid）是一家專注于人機交互技術的產品平臺公司，基于ACK Knative方案部署了其在線服務系統(tǒng)，實現了多版本管理以加快應用迭代、基于請求的自動擴縮容以精準調配GPU資源等能力，實現了運維、成本和性能之間的平衡。更多信息，請參見靈伴科技（Rokid）借助 Knative 實現 AI 應用云原生 Serverless 化。
XTransfer是一站式外貿企業(yè)跨境金融和風控服務公司，基于ACK Knative方案搭建了DevOps平臺，實現了算法模型的Serverless部署。在DevOps平臺上，算法工程師可以創(chuàng)建待上線模型版本、定義推理腳本、指定模型服務所需資源（最小副本數、所需的GPU資源、所需的內存資源等），并最終完成模型的發(fā)布。更多信息，請參見云原生 Knative 組件助力 XTransfer 加速應用云原生 Serverless 化。
深圳硅基仿生科技股份有限公司是一家創(chuàng)新醫(yī)療器械研發(fā)與產業(yè)化公司，采用ACK Knative方案加速了深度學習模型的性能提升，同時降低了服務部署成本。更多信息，請參見硅基仿生業(yè)務全面 Serverless 容器化的增效降本之旅。
聯系我們
如果您在使用Knative的過程中有任何疑問或建議，歡迎您搜索釘群號23302777加入釘群。
相關文檔
請及時升級Knative Serving組件，以便享受最新的功能特性和缺陷修復。建議您在業(yè)務低峰期進行升級。更多信息，請參見Knative版本發(fā)布說明、升級Knative Serving組件。
Knative官方文檔提供了一個在線書店應用程序教程，帶您體驗使用Knative構建、部署和監(jiān)控應用程序的各個步驟，請參見Knative Bookstore Tutorial。