如何Knative中的Build、Serving 和 Eventing三大核心組件

本篇文章給大家分享的是有關如何Knative中的Build、Serving 和 Eventing三大核心組件，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

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

劃重點

初識 Knative:  跨平臺的 Serverless 編排框架 讓我們對于 Knative 有了初步了解，Knative 主要由 Build、Serving 和 Eventing 三大核心組件構成。Knative 正是依靠這三個核心組件，驅動著 Knative 這艘 Serverless 巨輪前行，本文就來分別介紹一下這三個核心組件。

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

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

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

  * git 代碼倉庫

  * 任意容器鏡像

• 支持通過 BuildTemplate 創建可重復執行構建的模板

• 支持 K8s ServiceAccount 身份驗證

典型的 Build 示意圖：

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

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 是不可變對象，可以長期保留

資源關系圖：

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

• Knative Eventing 提供的服務是松散耦合，可獨立開發和部署。服務可跨平臺使用（如 Kubernetes, VMs, SaaS 或者 FaaS）

• 事件的生產者和事件的消費者是相互獨立的。任何事件的生產者（事件源）可以先于事件的消費者監聽之前產生事件，同樣事件的消費者可以先于事件產生之前監聽事件

• 支持第三方的服務對接該 Eventing 系統

• 確保跨服務的互操作性

事件處理示意圖：

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

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

• ApiserverSource：每次創建或更新 Kubernetes 資源時，ApiserverSource 都會觸發一個新事件

• GitHubSource：GitHub 操作時，GitHubSource 會觸發一個新事件

• GcpPubSubSource： GCP 云平臺 Pub/Sub 服務會觸發一個新事件

• AwsSqsSource：Aws 云平臺 SQS 服務會觸發一個新事件

• ContainerSource: ContainerSource 將實例化一個容器，通過該容器產生事件

• CronJobSource: 通過 CronJob 產生事件

• KafkaSource: 接收 Kafka 事件并觸發一個新事件

• CamelSource: 接收 Camel 相關組件事件并觸發一個新事件

當前 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），并產生事件過濾規則。

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

• Addressable 接口提供可用于事件接收和發送的 HTTP 請求地址，并通過status.address.hostname字段定義。作為一種特殊情況，Kubernetes Service 對象也可以實現 Addressable 接口

• Callable 接口接收通過 HTTP 傳遞的事件并轉換事件。可以按照處理來自外部事件源事件的相同方式，對這些返回的事件做進一步處理

  
  

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

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

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

以上就是如何Knative中的Build、Serving 和 Eventing三大核心組件，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。