為什么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 系統
- 確保跨服務的互操作性
事件處理示意圖:
如上圖所示,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 傳遞的事件并轉換事件。可以按照處理來自外部事件源事件的相同方式,對這些返回的事件做進一步處理
當前 Knative 支持通過 Knative Service 或者 Kubernetes Service 進行消費事件。
另外針對事件消費者,如何事先知道哪些事件可以被消費? Knative Eventing 在最新的 0.6 版本中提供 Registry 事件注冊機制, 這樣事件消費者就可以事先通過 Registry 獲得哪些 Broker 中的事件類型可以被消費。
[]()
總結
Knative 使用 Build 提供云原生“從源代碼到容器”的鏡像構建能力,通過 Serving 部署容器并提供通用的服務模型,同時以 Eventing 提供事件全局訂閱、傳遞和管理能力,實現事件驅動。這就是 Knative 呈現給我們的標準 Serverless 編排框架。
原文鏈接?
本文為云棲社區原創內容,未經允許不得轉載。