為什么80%的碼農都做不了架構師？>>> ??

作者| 阿里云智能事業群高級開發工程師 元毅

Knative 主要由 Build、Serving 和 Eventing 三大核心組件構成。Knative 正是依靠這三個核心組件，驅動著 Knative 這艘 Serverless 巨輪前行。下面讓我們來分別介紹一下這三個核心組件。

Build

Knative Build 是基于現有的 Kubernetes 能力之上，提供的一套標準化、可移植、可復用的容器鏡像構建方式。通過在 Kubernetes 上運行復雜的構建任務，Knative Build 使你不必再單獨開發和重復這些鏡像構建過程， 從而通過系統化、工程化的方式，減少了鏡像構建時間及成本。

Build 通過 Kubernetes 自定義資源定義(CRD)實現。 通過 Build 你可以自定義一個從運行到結束的構建流程。例如，可以使用 Knative Build 來獲取、構建和打包代碼。Build 具備以下功能：

• 支持 Source 源掛載，目前支持的 Source 源包括：

  • git 代碼倉庫
  • 任意容器鏡像
• 支持通過 BuildTemplate 創建可重復執行構建的模板
• 支持 K8s ServiceAccount 身份驗證

典型的 Build 示意圖：

雖然目前 Knative Build 并不提供完整的獨立 CI/CD 解決方案，但它卻提供了一個底層的構建模塊，用戶可單獨使用該構建模塊在大型系統中實現集成和利用。

Serving

Knative 作為 Severless 框架最終是用來提供服務的， 那么 Knative Serving 應運而生。

Knative Serving 構建于 Kubernetes 和 Istio 之上，為 ?Serverless 應用提供部署和服務支持。其特性如下：

• 快速部署 Serverless 容器
• 支持自動擴縮容和縮到 0 實例
• 基于 Istio 組件，提供路由和網絡編程
• 支持部署快照

Knative Serving 中定義了以下 CRD 資源：

• Service: 自動管理工作負載整個生命周期。負責創建 Route、Configuration 以及 Revision 資源。通過 Service 可以指定路由流量使用最新的 Revision 還是固定的 Revision
• Route：負責映射網絡端點到一個或多個 Revision?？梢酝ㄟ^多種方式管理流量。包括灰度流量和重命名路由
• Configuration: 負責保持 Deployment 的期望狀態，提供了代碼和配置之間清晰的分離，并遵循應用開發的 12 要素。修改一次 Configuration 產生一個 Revision
• Revision：Revision 資源是對工作負載進行的每個修改的代碼和配置的時間點快照。Revision 是不可變對象，可以長期保留

資源關系圖：

Eventing

Knative Eventing 旨在滿足云原生開發中通用需求, 以提供可組合的方式綁定事件源和事件消費者。其設計目標：

• Knative Eventing 提供的服務是松散耦合，可獨立開發和部署。服務可跨平臺使用（如 Kubernetes, VMs, SaaS 或者 FaaS）
• 事件的生產者和事件的消費者是相互獨立的。任何事件的生產者（事件源）可以先于事件的消費者監聽之前產生事件，同樣事件的消費者可以先于事件產生之前監聽事件
• 支持第三方的服務對接該 Eventing 系統
• 確?？绶盏幕ゲ僮餍?/li>

事件處理示意圖：

如上圖所示，Eventing 主要由事件源（Event Source）、事件處理（Flow）以及事件消費者（Event Consumer）三部分構成。

[]()

事件源（Event Source）

當前支持以下幾種類型的事件源：

• ApiserverSource：每次創建或更新 Kubernetes 資源時，ApiserverSource 都會觸發一個新事件
• GitHubSource：GitHub 操作時，GitHubSource 會觸發一個新事件
• GcpPubSubSource： GCP 云平臺 Pub/Sub 服務會觸發一個新事件
• AwsSqsSource：Aws 云平臺 SQS 服務會觸發一個新事件
• ContainerSource: ContainerSource 將實例化一個容器，通過該容器產生事件
• CronJobSource: 通過 CronJob 產生事件
• KafkaSource: 接收 Kafka 事件并觸發一個新事件
• CamelSource: 接收 Camel 相關組件事件并觸發一個新事件

[]()

事件接收/轉發（Flow）

當前 Knative 支持如下事件接收處理：

• 直接事件接收
  
  通過事件源直接轉發到單一事件消費者。支持直接調用 Knative Service 或者 Kubernetes Service 進行消費處理。這樣的場景下，如果調用的服務不可用，事件源負責重試機制處理。
• 通過事件通道(Channel)以及事件訂閱(Subscriptions)轉發事件處理
  
  這樣的情況下，可以通過 Channel 保證事件不丟失并進行緩沖處理，通過 Subscriptions 訂閱事件以滿足多個消費端處理。
• 通過 brokers 和 triggers 支持事件消費及過濾機制

從 v0.5 開始，Knative Eventing 定義 Broker 和 Trigger 對象，實現了對事件進行過濾（亦如通過 ingress 和 ingress controller 對網絡流量的過濾一樣）。

通過定義 Broker 創建 Channel，通過 Trigger 創建 Channel 的訂閱（subscription），并產生事件過濾規則。

[]()

事件消費者（Event Consumer）

為了滿足將事件發送到不同類型的服務進行消費， Knative Eventing 通過多個 k8s 資源定義了兩個通用的接口：

• Addressable 接口提供可用于事件接收和發送的 HTTP 請求地址，并通過status.address.hostname字段定義。作為一種特殊情況，Kubernetes Service 對象也可以實現 Addressable 接口
• Callable 接口接收通過 HTTP 傳遞的事件并轉換事件?？梢园凑仗幚韥碜酝獠渴录词录南嗤绞?#xff0c;對這些返回的事件做進一步處理

當前 Knative 支持通過 Knative Service 或者 Kubernetes Service 進行消費事件。

另外針對事件消費者，如何事先知道哪些事件可以被消費？ Knative Eventing 在最新的 0.6 版本中提供 Registry 事件注冊機制, 這樣事件消費者就可以事先通過 Registry 獲得哪些 Broker 中的事件類型可以被消費。

[]()

總結

Knative 使用 Build 提供云原生“從源代碼到容器”的鏡像構建能力，通過 Serving 部署容器并提供通用的服務模型，同時以 Eventing 提供事件全局訂閱、傳遞和管理能力，實現事件驅動。這就是 Knative 呈現給我們的標準 Serverless 編排框架。

原文鏈接?

本文為云棲社區原創內容，未經允許不得轉載。

轉載于:https://my.oschina.net/yunqi/blog/3056417

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Knative 核心概念介绍：Build、Serving 和 Eventing 三大核心组件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。