Knative是一款基於Kubernetes的Serverless架構，支援基於請求的自動彈性、在沒有流量時將執行個體數量自動縮容至零、版本管理與灰階發布等能力。在完全相容社區Knative和Kubernetes API的基礎上，ACK Knative進行了多維度能力增強，例如通過保留執行個體降低冷啟動時間、基於AHPA實現彈性預測等。
為什麼要在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）進行Auto Scaling更能直接反映服務效能。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）、可觀測（Log ServiceSLS、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的典型使用情境如下。
業務情境 | 說明 |
Web服務的託管 |
|
Serverless應用 |
|
AI情境 |
|
事件驅動情境 | Knative Eventing提供了完整的事件模型，簡化了接入外部系統的事件的流程。例如，IoT裝置可以將感應器資料發送到Knative服務中，ACK Knative可以配置對應的事件來源用於接收資料，並觸發相應的處理邏輯，例如資料存放區、即時分析、監控警示等。 |
ACK Knative的使用流程
ACK Knative的使用流程如下圖所示。
流程 | 說明 |
前提條件 | |
在控制台一鍵部署ACK Knative，安裝Knative Serving組件。具體操作，請參見部署Knative。 | |
完成網關選型並部署網關。ACK Knative支援ALB、MSE、ASM、Kourier四種網關。詳細資料，請參見Knative網關選型建議。
| |
服務部署與管理 | 指定使用的資源類型：
|
自動調整：
| |
版本管理與灰階發布：
| |
Knative服務的訪問：
| |
進階功能 | 事件驅動：在滿足雲原生開發的常見需求的基礎上，Knative Eventing提供了完整、系統的Serverless事件驅動模式，包括外來事件源的接入、事件流轉和訂閱、以及對事件的過濾等功能。ACK Knative直接豐富的事件來源，包括GitHub、EventBridge等。請參見事件驅動概述。 |
Knative Functions：簡化在Kubernetes叢集中建立、部署和調用函數的流程，請參見部署Knative Functions。 | |
AI推理服務： KServe提供了一個基於Kubernetes叢集的機器學習模型服務架構，提供簡單的Kubernetes CRD，可將單個或多個經過訓練的模型（例如TFServing、TorchServe、Triton等推理伺服器）部署到模型服務運行時。您可以部署KServe組件並基於KServe快速部署一個推理服務。 同時，ACK提供了在Knative中部署AI模型推理服務的最佳實務，例如如何在Knative中部署一個vLLM推理服務、如何加速模型部署、如何配置GPU共用調度等，請參見在Knative中部署AI模型推理服務的最佳實務。 | |
服務網格：如果您需要在Knative服務中整合服務網格，以實現複雜的流量管理並增強服務安全性，推薦您使用服務網格ASM，請參見什麼是服務網格ASM？。 | |
可觀測性與成本管理 | 日誌採集：您可以在Knative服務中使用SLS，無需開發便能快捷完成日誌資料擷取、消費、投遞以及查詢分析等功能，請參見在Knative上實現日誌採集。 |
監控大盤：您可以把Knative接入阿里雲Prometheus監控，便於查看Knative的響應延遲、請求並發數等資料，請參見查看Knative服務監控大盤。 | |
監控警示：您可以使用SLS建立日誌警示監控規則，請參見為Knative服務開啟監控警示。 | |
成本洞察：作為企業IT成本管理員，您可以為Knative服務啟用成本洞察功能，瞭解Knative服務的資源使用量及成本分布，請參見啟用Knative服務成本洞察。 |
相關計費
在ACK叢集中使用ACK Knative時，ACK Knative本身不收取管理費用，但在使用過程中產生的叢集管理費用、所建立的雲端服務器、Server Load Balancer執行個體、NAT Gateway等，按照相應資源的價格計費。更多資訊，請參見ACK叢集的計費概述、雲產品資源費用。
常見問題
如您在使用ACK Knative時遇到問題，可以先參見Knative FAQ完成自排查。
聯絡我們
如果您在使用Knative的過程中有任何疑問或建議，歡迎您搜尋釘群號23302777加入釘群。
相關文檔
請及時升級Knative Serving組件，以便享受最新的功能特性和缺陷修複。建議您在業務低峰期進行升級。更多資訊，請參見Knative版本發布說明、升級Knative Serving組件。
Knative官方文檔提供了一個線上書店應用程式教程，帶您體驗使用Knative構建、部署和監控應用程式的各個步驟，請參見Knative Bookstore Tutorial。