Knative是基於Kubernetes之上提供的一款開源Serverless應用程式框架，協助您部署和管理現代化的Serverless工作負載，打造企業級Serverless平台。ACK Serverless整合了Knative，您只需要擁有一個ACK Serverless叢集並開通Knative功能，就可以基於Knative API使用雲的能力。並且無需為Knative Controller付出任何成本。
ACK Serverless Knative優勢
社區Knative | ACK Serverless Knative |
預設使用Istio作為Gateway，安裝Istio的Controller需要額外支出部分IaaS成本。 | 無需為Knative Controller付出任何成本。 |
Knative自身的Controller部署，需要額外支出部分IaaS成本。 | |
在ACK Serverless叢集中建立一個Pod是有明顯的冷啟動時間，Knative的縮容到零機制可以很好的節省成本，但是第一批請求過來時有可能導致短暫的逾時失敗。 | ACK Serverless Knative在沒有流量的時候不把應用執行個體數縮容到零個，而是保留執行個體。通過低成本的保留執行個體來平衡成本和冷啟動時間長度。保留執行個體的詳細介紹請參見保留執行個體。 |
Knative資源託管
ACK Serverless作為無伺服器的Kubernetes叢集，無需單獨購買節點即可直接部署容器應用，是一種理想的Kubernetes使用方式。以下為Knative資源託管優勢：
ACK Serverless上提供了Knative的託管服務，您可以通過Knative管理應用。
Knative可以在需要的時候自動從ACK Serverless中申請IaaS資源，此處laaS資源在ACK Serverless中指Pod。
Knative Serving Controller和阿里雲Container Service進行了融合。您只需要擁有一個ACK Serverless叢集並開通Knative功能就可以基於Knative API使用雲的能力，並且無需為Knative Controller付出任何成本。
Knative Gateway
社區Knative預設支援Istio、Gloo、Contour、Kourier和Ambassador等多種Gateway實現方案。在這些實現方案中Istio使用頻率最高。因為Istio除了可以充當Gateway的角色還能作為ServiceMesh服務使用。Serverless服務需要有Gateway執行個體常駐運行，而為了保證高可用至少要有兩個執行個體互為備份。其次這些Gateway的Controller也需要常駐運行，這些常駐執行個體的IaaS費用和營運都是業務需要支付的成本。
為了提升Serverless體驗，通過阿里雲ALB實現了Knative Gateway。Knative Gateway具備所有需要的功能並且屬於雲產品層級的支撐。不需要常駐資源，不僅節省了您的IaaS成本還省去了很多營運負擔。
保留執行個體
社區Knative預設在沒有流量時可以把應用執行個體縮容到零，但是縮容到零之後，從零到一的冷啟動問題很難解決。冷啟動除了要解決IaaS資源的分配、Kubernetes的調度、拉鏡像等問題以外，還涉及到應用的啟動時間長度。而應用鏡像的大小以及應用啟動時間長度與具體的開發人員或者業務有很強的關聯。
ACK Serverless的Knative和社區Knative不同點在於預設在沒有流量的時候不把應用執行個體數縮容到零個，而是保留一個執行個體。以下為保留執行個體的策略：
在業務波穀時使用突發效能執行個體替換標準的計算型執行個體，當第一個請求來臨時再無縫切換到標準的計算型執行個體，從而降低流量低穀的成本。
流量低穀時獲得的CPU積分可以在業務高峰到來時使用，節約了使用成本。
保留執行個體的詳細介紹請參見保留執行個體。
Knative安裝部署
Serverless Kubernetes （ACK Serverless）叢集支援部署Knative。
如果您的ACK Serverless叢集版本≥1.16，可以直接通過控制台部署Knative，詳細介紹請參見Knative組件管理。
如果您的ACK Serverless叢集版本<1.16，請先升級ACK Serverless叢集。
計費說明
Knative本身不收取管理費用，但在使用過程中所建立的ECI容器執行個體、Server Load Balancer執行個體、NAT Gateway等會按照相應資源的價格計費。更多資訊，請參見容器執行個體計費概述。