使用Knative基於構建、部署、管理serverless應用

banq發表於2018-08-09
Server
Kubernetes的主要價值在於它極大地減少了許多基礎架構管理的痛苦，幾乎所有主要雲服務提供商（CSP）對它的廣泛支援也意味著我們的應用是可移植的，但是，對於在Kubernetes之上構建解決方案的開發人員來說還是複雜的，對於初學者來說，在Kubernetes上開發，部署和管理服務的行為仍然過於複雜。儘管有許多用於記錄、監控、整合的開源專案，但即使你把它們恰到好處地放在一起，在Kubernetes上進行開發還仍然很脆弱，而且過於勞動密集。

作為程式碼開發的原子單元的函式的日益普及進一步增加了整體複雜性，通常在兩個分離的區域建立不同的開發模式：一個用於函式（FaaS），一個用於應用程式（PaaS）。

因此，今天的開發人員不得不擔心與基礎架構相關的問題：例如，映像構建、登錄檔釋出、部署服務、負載平衡、日誌記錄、監視和擴充套件。但是，他們真正想要做的還是編寫程式碼。

介紹Knative

Knative凝聚了Google的許多經驗，這個開源專案也有來自Pivotal、IBM、Red Hat和SAP等公司的貢獻，包括OpenWhisk、riff和Kyma這樣開源的函式即服務的框架社群的合作，他們要麼重新轉換為Knative，要麼消使用來自Knative專案的元件。

它提供了一組構建塊，可在Kubernetes上實現現代的、以原始碼為中心的和基於容器的開發工作負載：

1. 構建  - 原始碼到容器的構建編排
2. 事件  - 管理和交付事件
3. 服務  - 請求驅動的計算，可以縮減到零


Knative總覽
Knative基於明確分離關注點的前提，它允許開發人員和操作人員透過以自定義資源（CRD）的形式定義原始物件來負責應用的開發、部署和管理。下面是它的原始物件：

1. 配置  - 是你的服務所需的狀態，包括程式碼和配置
2. 修訂版  - 表示程式碼和配置的不可變時間點快照
3. 路由  - 將流量分配給服務的修訂版或修訂版
4. 服務  - 是所有上述物件的組合lite版本，以實現簡單的用例

[img index=1]

除了這些物件之外，Knative還定義了用於事件的主要物件......你知道，因為無伺服器，Knative負責解耦事件生成者和使用者，並實現CNCF CloudEvents（v0.1）以簡化事件處理。

Knative 事件結構：
1. 事件源  - 代表事件的生產者（例如GitHub）
2. 事件型別  - 描述不同事件源支援的事件型別（例如，上面提到的GitHub源的Webhook）
3. 事件消費者  - 代表你Action目標（即Knative定義的任何路線）
4. 事件feed  - 是將事件型別連線到操作的繫結或配置

[img index=2]

Knative物件模型的這些功能實現說明Knative既易於入門，又能夠解決更高階的用例，特別是當你的解決方案的複雜性增加時。

Build, deploy, manage modern serverless workloads

相關文章