作者 | 元毅

導讀：Knative 是基于 Kubernetes 的開源 Serverless 應用編排框架。阿里云 Knative 在社區(qū) Knative 基礎(chǔ)之上，與阿里云產(chǎn)品進行了深度的融合，給你帶來最純粹的容器化 Serverless 體驗。
?

關(guān)于 Knative

?

Knative 是基于 Kubernetes 的開源 Serverless 應用編排框架。實際上 Knative 包含的不單單是 Workload，它還有 Kubernetes 原生的流程編排引擎和完備的事件系統(tǒng)。Knative 目標是基于 Kubernetes 提供應用 Serverless 工作負載編排的標準化。Knative 核心模塊主要包括事件驅(qū)動框架 Eventing 和部署工作負載的 Serving。
?

1. Serverless 服務引擎 - Serving

?

Knative Serving 核心能力就是其簡潔、高效的應用托管服務，這也是其支撐 Serverless 能力的基礎(chǔ)。當然作為 Serverless Framework 就離不開按需分配資源的能力，Knative 可以根據(jù)應用的請求量在高峰時期自動擴容實例數(shù)，當請求量減少以后自動縮容實例數(shù)，可以非常自動化地幫助您節(jié)省成本。
?

Serving 還提供了流量管理能力和靈活的灰度發(fā)布能力。流量管理能力可以根據(jù)百分比切分流量，灰度發(fā)布能力可以根據(jù)流量百分比進行灰度。
?

1）簡單的應用模型

?

提供了極簡的應用模型 - Knative Service ，同時滿足服務部署、服務訪問以及灰度發(fā)布的能力。可以用下面的公式表述：Knative Service = 工作負載（Deployment）+ 服務訪問（ Service ）+ 灰度流量（ Ingress ）。
?

應用模型如下圖

• Service：對 Serverless 應用模型的抽象，通過 Service 管理應用的生命周期；
• Configuration：用于配置應用期望的信息。每次更新 Service 就會更新 Configuration；
• Revision：Configuration 的每次更新都會創(chuàng)建一個快照，用來做版本管理；
• Route：將請求路由到 Revision，并可以向不同的 Revision 轉(zhuǎn)發(fā)不同比例的流量。

?

• 應用托管

  • Kubernetes 是面向 IaaS 管理的抽象，通過 Kubernetes 直接部署應用需要維護的資源比較多；
  • 通過 Knative Service 一個資源就能定義應用的托管。

• 流量管理

  • Knative 通過 Gateway 結(jié)果應用流量，然后可以對流量按百分比進行分割，這為這為彈性、灰度等基礎(chǔ)能力做好了基礎(chǔ)。

?

• 灰度發(fā)布
  • 支持多版本管理，應用同時有多個版本在線提供服務很容易實現(xiàn)；
  • 不同版本可以設(shè)置不同的流量百分比，對灰度發(fā)布等功能實現(xiàn)起來很容易。

?

• 彈性
  • Knative 幫助應用節(jié)省成本的核心能力是彈性，在流量增加的時候自動擴容，容，流量下降的時候自動縮容；
  • 每一個灰度的版本都有自己的彈性策略，并且彈性策略和分配到當前版本的流量流量是相關(guān)聯(lián)的。Knative 會根據(jù)分配過來的流量多少進行擴容或者縮容的決策。

2）豐富的彈性策略

?
作為 Serverless 框架，其核心能力就是自動彈性，Knative 中提供了豐富的彈性策略：

• 基于流量請求的自動擴縮容 - KPA
• 基于 CPU、Memory 的自動擴縮容 - HPA
• 支持定時 + HPA 的自動擴縮容策略
• 事件網(wǎng)關(guān)，提供請求與 Pod 1 對 1 處理能力

?

2. Serverless 事件驅(qū)動框架 - Eventing

?
事件驅(qū)動是 Serverless 的標配，在 Knative 中同樣提供了事件驅(qū)動框架 - Eventing。
?
Knative 的 Eventing 提供了完整的事件模型，可以很容易地接入各個外部系統(tǒng)的事件。事件接入以后通過 CloudEvent 標準在內(nèi)部流轉(zhuǎn)。
?
在 Knative Eventing 提供兩種事件轉(zhuǎn)發(fā)方式：
?

• 事件源直接轉(zhuǎn)發(fā)到服務；
• 事件源轉(zhuǎn)發(fā)到 Broker / Trigger ，然后通過過濾轉(zhuǎn)發(fā)到服務。

對于在使用過程中究竟應該使用哪種方式進行轉(zhuǎn)發(fā)呢？其實很簡單，Broker / Trigger 模型是基于底層消息系統(tǒng)實現(xiàn)的，對于像 Github、Gitlab、K8s APIserver 這樣的事件源來說，需要對消息事件進行緩沖處理、保證消息傳輸可靠性，那么我們建議通過事件源轉(zhuǎn)發(fā)到 Broker / Trigger 進行事件流轉(zhuǎn)。
?
對于事件源本身就是消息系統(tǒng)來說，像 MNS、Kafka、RocketMQ來說，使用事件源直接轉(zhuǎn)發(fā)到服務更為高效。
?
講到這里，就不得不提 Knative 的事件源。我把它比喻成事件驅(qū)動引擎，Knative Eventing 正是通過這些事件源驅(qū)動事件流轉(zhuǎn)。
?
Knative 社區(qū)提供了豐富的事件源，如 Kafka、GitHub 等。此外還接入消息云產(chǎn)品事件源，如 MNS、RocketMQ 等。

阿里云 Knative

?
阿里云 Knative 在社區(qū)原生的 Knative 之上，與阿里云資源體系進行了全方位的整合，提供了更為豐富的能力以及云產(chǎn)品級別的支持。
?

1. 與阿里云產(chǎn)品融合

?

• 豐富的消息云產(chǎn)品事件源：Kafka 、MNS 、RocketMQ
• 服務訪問：SLB
• 存儲：NAS 、云盤等
• 可觀測性：日志服務、ARMS
• IaaS 資源：ECS 、ECI

2. 天然集成阿里云 K8s 生態(tài)

?

• 支持阿里云標準版 Kubernetes，專有版 Kubernetes；
• 支持阿里云 Serverless Kubernetes（ASK）， 并且在 ASK 中將 Knative 管控組件全托管，為用戶節(jié)省了資源以及運維成本。

一個例子

?
接下來以一個發(fā)送彈幕的示例來介紹一下如何玩轉(zhuǎn)阿里云 Knative。先看一下效果：
?

架構(gòu)示意圖：
?

流程說明：

• 用戶通過彈幕 Web 服務發(fā)送彈幕到阿里云 Kafka；
• Kafka Source 事件源監(jiān)聽到彈幕消息，然后發(fā)送到彈幕消息處理服務；
• 彈幕消息處理服務接收到消息，然后自動彈性擴容實例進行消息處理，并將處理完成的消息發(fā)送給彈幕服務；
• 最后彈幕通過 Web 服務界面展示給用戶；

總結(jié)

?
最后我們總結(jié)一下阿里云 Knative 能給我們帶來哪些能力：
?

• 服務部署低門檻、易上手
• Serverless 按需使用資源
• 事件驅(qū)動與消息云產(chǎn)品無縫對接
• 天然集成阿里云 K8s 生態(tài)
• 與阿里云產(chǎn)品打通

希望這些能力能給你帶來真正的按需使用，降低運維、資源使用成本的訴求，這也是 Serverless 思想理念所追求的目標。

總結(jié)

以上是生活随笔為你收集整理的春色满园关不住，带你体验阿里云 Knative的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。