春色滿園關不住，帶你體驗阿里雲 Knative

簡介：Knative 是基於 Kubernetes 的開源 Serverless 應用編排框架。阿里雲 Knative 在社區Knative基礎之上，與阿里雲產品進行了深度的融合，給你帶來最純粹的容器化 Serverless 體驗。
Knative 是基於 Kubernetes 的開源 Serverless 應用編排框架。阿里雲 Knative 在社區Knative基礎之上，與阿里雲產品進行了深度的融合，給你帶來最純粹的容器化 Serverless 體驗。
章程
• 關於 Knative
• Serverless 服務引擎 - Serving
• Serverless 事件驅動 - Eventing
• 阿里雲 Knative
• 阿里雲產品融合
• 阿里雲 K8s 生態集成
• 一個例子
關於Knative
Knative 是基於 Kubernetes 的開源 Serverless 應用編排框架。實際上 Knative 包含的不僅僅是 Workload，它還有 Kubernetes 原生的流程編排引擎和完備的事件系統。 Knative 目標是基於 Kubernetes 提供應用 Serverless 工做負載編排的標準化。Knative 核心模塊主要包括事件驅動框架 Eventing 和部署工做負載的 Serving。
Serverless 服務引擎 - Serving
Knative Serving 核心能力就是其簡潔、高效的應用託管服務，這也是其支撐Serverless 能力的基礎。固然做爲SeverlesssFramework 就離不開按需分配資源的能力，Knative 能夠根據您應用的請求量在高峯時期自動擴容實例數，當請求量減小之後自動縮容實例數，能夠很是自動化的幫助您節省成本。Serving 還提供了的流量管理能力和靈活的灰度發佈能力。流量管理能力能夠根據百分比切分流量，灰度發佈能力能夠根據流量百分比進行灰度
簡單的應用模型
提供了極簡的應用模型 - Knative Service，同時知足服務部署、服務訪問以及灰度發佈的能力。能夠用下面的公式表述：Knative Service = 工做負載（Deployment）+服務訪問(service)+灰度流量(Ingress)。應用模型如圖：
• Service: 對 Serverless 應用模型的抽象，經過Service 管理應用的生命週期
• configuration: 用於配置應用指望的信息。每次更新Service 就會更新Configuration
• revision: configuration的每次更新都會建立一個快照，用來作版本管理
• route: 將請求路由到Revision，並能夠向不一樣的Revision 轉發不一樣比例的流量
• 應用託管
• Kubernetes 是面向 IaaS 管理的抽象，經過 Kubernetes 直接部署應用須要維護的資源比較多
• 經過 Knative Service 一個資源就能定義應用的託管
• 流量管理
• Knative 經過 Gateway 結果應用流量，而後能夠對流量按百分比進行分割，這爲彈性、灰度等基礎能力作好了基礎
• 灰度發佈
• 支持多版本管理，應用同時有多個版本在線提供服務很容易實現
• 不一樣版本能夠設置不一樣的流量百分比，對灰度發佈等功能實現起來很容易
• 彈性
• Knative 幫助應用節省成本的核心能力是彈性，在流量增長的時候自動擴容，流量降低的時候自動縮容
• 每個灰度的版本都有本身的彈性策略，而且彈性策略和分配到當前版本的流量是相關聯的。Knative 會根據分配過來的流量多少進行擴容或者縮容的決策
豐富的彈性策略
做爲 Serverless 框架，其核心能力就是自動彈性，Knative中提供了豐富的彈性策略：
• 基於流量請求的自動擴縮容-KPA
• 基於CPU、Memory的自動擴縮容-HPA
• 支持定時 + HPA的自動擴縮容策略
• 事件網關，提供請求與Pod 1對1處理能力
Serverless 事件驅動框架 - Eventing
事件驅動是Serverless的標配，在Knative 一樣提供了事件驅動框架-Eventing。
Knative 的 Eventing 提供了完整的事件模型，能夠很容易地接入各個外部系統的事件。事件接入之後經過 CloudEvent 標準在內部流轉。
在Knative Eventing提供兩種事件轉發方式：
• 事件源直接轉發到服務
• 事件源轉發到Broker/Trigger，而後經過過濾轉發到服務

對於在使用過程當中究竟應該使用哪一種方式進行轉發呢？其實很簡單，broker/trigger模型是基於底層消息系統實現的，對於像github、gitlab、k8s apiserver這樣的事件源來講，須要對消息事件進行緩衝處理、保證消息傳輸可靠性，那麼咱們建議經過事件源轉發到Broker/Trigger進行事件流轉。
對於事件源自己就是消息系統來講，像mns、kafka、rocketmq來講，使用事件源直接轉發到服務更爲高效。
講到這裏，就不得不提Knative的事件源。我把它比喻成事件驅動引擎，Knative Eventing正是經過這些事件源驅動事件流轉。
Knative社區提供了豐富的事件源，如Kafka、GitHub等。此外還接入消息雲產品事件源，如MNS、RocketMQ等。
阿里雲Knative
阿里雲 Knative 在社區原生的 Knative 之上，與阿里雲資源體系進行了全方位的整合，提供了更爲豐富的能力以及雲產品級別的支持。

與阿里雲產品融合
• 豐富的消息雲產品事件源：Kafka、MNS、RocketMQ
• 服務訪問：SLB
• 存儲：NAS、雲盤等
• 可觀測性：日誌服務、ARMS
• IaaS資源：ECS、ECI
自然集成阿里雲k8s生態
• 支持阿里雲標準版 Kubernentes，專有版Kubernentes
• 支持阿里雲Serverless Kubernetes（ASK）， 而且在ASK中將 Knative 管控組件全託管, 爲用戶節省了資源以及運維成本。
一個例子
接下來以一個發送彈幕的示例來介紹一下如何玩轉阿里雲Knative。先看一下效果：

架構示意圖

流程說明：
• 用戶經過彈幕web服務發送彈幕到阿里雲kafka
• Kafka Source事件源監聽到彈幕消息，而後發送到彈幕消息處理服務
• 彈幕消息處理服務接收到消息，而後自動彈性擴容實例進行消息處理，並將處理完成的消息發送給彈幕服務
• 最後彈幕經過web服務界面展現給用戶
具體實踐活動（密透：完成有機會拿Cherry機械鍵盤）：https://developer.aliyun.com/...
總結
最後咱們總結一下阿里雲 Knative 能給咱們帶來哪些能力：
• 服務部署低門檻、易上手
• Serverless 按需使用資源
• 事件驅動與消息雲產品無縫對接
• 自然集成阿里雲 K8s 生態
• 與阿里雲產品打通
但願這些能力能給你帶來真正的按需使用，下降運維、資源使用成本的訴求，這也是 serverless 思想理念所追求的目標。
原文連接
本文爲阿里雲原創內容，未經容許不得轉載。