目錄

一、 Serverless介紹

二、Knative 介紹

2.1??Knative 的定位

2.2?Knative的組成?

2.2.1 Build 構建系統

2.2.2?Serving：服務系統

2.2.3?Eventing：事件系統

補充：?

三、總結：

---

一、 Serverless介紹

在講Knative之前，需要先講一下Serverless。

對于Serverless，目前還沒有形成一個比較權威的定義，最新的一個定義是這樣描述的：

“無服務器架構是基于互聯網的系統，其中應用開發不使用常規的服務進程。相反，它們僅依賴于第三方服務（例如AWS Lambda服務），客戶端邏輯和服務托管遠程過程調用的組合。”

最開始，“無服務器”架構試圖幫助開發者擺脫運行后端應用程序所需的服務器設備的設置和管理工作。

這顯然是不成立的，因為這項技術的目標并不是為了實現真正意義上的“無服務器”，而是指由第三方云計算供應商負責后端基礎結構的維護，以服務的方式為開發者提供所需功能，例如數據庫、消息，以及身份驗證等。

簡單地說，這個Serverless架構的目標：就是要讓開發人員關注代碼的運行而不需要管理任何的基礎設施。

程序代碼被部署在諸如AWS Lambda這樣的平臺之上，通過事件驅動的方法去觸發對函數的調用。

也可以理解為，這是一種完全針對程序員的架構技術。為了簡化開發人員的工作，提高業務實現效率而研發的一種架構。

其技術特點包括了事件驅動的調用方式，以及有一定限制的程序運行方式，例如AWS Lambda的函數的運行時間默認為3秒到5分鐘。

從這種架構技術出現的兩年多時間來看，這個技術已經有了非常廣泛的應用，例如移動應用的后端和物聯網應用等。

簡而言之，無服務器架構的出現不是為了取代傳統的應用。而是從具有高度靈活性的使用模式及事件驅動的特點出發，

開發人員／架構師應該重視這個新的計算范例，它可以幫助我們達到減少部署、提高擴展性并減少代碼后面的基礎設施的維護負擔。

如下圖，按照傳統的方式，一個項目前端+后端+基礎設施都是必須的，基本上項目都是需要有一套。

但是，對于無服務架構來說，拆分后端，比如把權限、業務應用、數據庫等拆分，從而使得開發更靈活，復用性更強，也就是一直說的，縮短產品到落地的時間，從而縮短產品周期，提高整個項目實現的效率。

這個也是無服務的主要意義。感覺架構的發展也好，服務的演變也好，所有的發展，基本上為了提高效率，更快的從想法到產品的一個落地實施。

但是，傳統的 Serverless 解決方案自身的問題有一些問題，目前存在以下問題：

• 缺乏統一標準。呈現碎片化，各家都有各自的實現。
• 廠商鎖定。比如使用 AWS Lambda 就必須配套使用 AWS 的 DB, S3 等產品，這樣用戶就被該廠商綁定，不能進行隨意的遷移或者遷移成本非常高。

為了解決傳統的 Serverless這幾個問題，Knative就出現了。?

二、Knative 介紹

Knative 是谷歌牽頭發起的 Serverless 項目。

其目標是基于 Kubernetes 的 Serverless 解決方案，旨在標準化 Serverless，簡化其學習成本。

Knative 是以 Kubernetes 的一組自定義資源類型（CRD）的方式來安裝的，因此只需使用幾個 YAML 文件就可以輕松地開始使用 Knative 了。

這也意味著，在本地或者托管云服務上，任何可以運行 Kubernetes 的地方都可以運行 Knative 和代碼。

2.1??Knative 的定位

Knative構建在Kubernetes、Istio、Container的基礎上，以K8S的CRD形式存在。

基礎設施：Kubernetes作為基礎設施：容器編排，解決應用編排和運行環境

通信設施：Isito作為通信基礎設施層，保證服務的運行可檢測、可配置、可追蹤

模板+環境：Knative使用應用模板和統一的運行環境來標準化服務的構建、部署和管理

2.2?Knative的組成?

為了實現 serverless 應用的管理，knative 把整個系統分成了三個部分：

• Build：構建系統，把用戶定義的函數和應用 build 成容器鏡像
• Serving：服務系統，用來配置應用的路由、升級策略、自動擴縮容等功能
• Eventing：事件系統，用來自動完成事件的綁定和觸發

2.2.1 Build 構建系統

build 的功能是把用戶的代碼自動化構建成容器鏡像

與普通docker+Dockerfile 構建容器相比較

Knative優勢：

• 內部構建：是它的構建完成是在 kubernetes 中進行的，和整個 kubernetes 生態結合更緊密
• 標準化：它旨在提供一個通用的標準化的構建組件，可以作為其他更大系統中的一部分

它的存在，更多是為了定義標準化、可移植、可重用、性能高效的構建方法

Knative 提供了?Build?CRD 對象，讓用戶可以通過 yaml 文件定義構建過程。一個典型的?Build?配置文件如下：

apiVersion: build.knative.dev/v1alpha1 kind: Build metadata:name: test-build spec:serviceAccountName: build-auth-test #認證信息source:git:url: https://github.com/your-example/build-example.git #代碼地址revision: master #分支信息steps:- name: ubuntu-exampleimage: ubuntuargs: ["ubuntu-build-example", "SECRETS-example.md"]steps:- image: gcr.io/example-builders/build-exampleargs: ['echo', 'test-example', 'build']

serviceAccountName?：是構建過程中需要用到的密碼和認證信息（比如連接到 git repo 的 SSH keys、push 鏡像到 registry 的用戶名和密碼等）；

source?：是代碼信息，比如這里的 git 地址和分支；

steps?：是真正運行過程中的各個步驟，這個只是作為 demo，真正的構建過程一般是 pull 代碼、 build 鏡像和 push鏡像到 registry 等邏輯。

因為大部分的構建過程都是一致的，因此 knative 還提供了?Build template?的概念，

Build template 封裝了預先定義好的構建過程（就是封裝了上面的?steps?過程），并提供了非常簡單的配置參數來使用。

使用 build template 構建容器鏡像就更簡單了，只需要提供代碼的地址和鏡像名字即可，比如下面是使用 Google kaniko 模板構建 github 源碼的 yaml 文件（需要在代碼根目錄存在 Dockerfile 文件）

apiVersion: build.knative.dev/v1alpha1 kind: Build metadata:name: test-kaniko-build spec:serviceAccountName: build-auth-test #認證信息source:git:url: https://github.com/your-user/your-reporevision: mastertemplate:name: kanikoarguments:- name: IMAGEvalue: us.gcr.io/my-project/my-app

2.2.2?Serving：服務系統

基于負載自動伸縮，包括在沒有負載時縮減到零。

允許為多個修訂版本（revision）應用創建流量策略，從而能夠通過 URL 輕松路由到目標應用程序。

knative serving 功能是基于 kubernetes 和 istio 開發的

• kubernetes 來管理容器（deployment、pod）
• istio 來管理網絡路由（VirtualService、DestinationRule）

可以認為 knative 提供了更高的抽象，自動封裝掉了 kubernetes 和 istio 的實現細節。

serving 的核心功能是讓應用運行起來提供服務。雖然聽起來很簡單，但包括了很多的事情：

• 自動化啟動和銷毀容器
• 根據名字生成網絡訪問相關的 service、ingress 等對象
• 監控應用的請求，并自動擴縮容
• 支持藍綠發布、回滾功能，方便應用方法流程

2.2.3?Eventing：事件系統

使得生產和消費事件變得容易。

抽象出事件源，并允許操作人員使用自己選擇的消息傳遞層。

serverless 最重要的是基于事件的觸發機制，也就是說當某件事發生時，就觸發某個特定的函數。

事件概念的出現，讓函數和具體的調用方能夠解耦。

函數部署出來不用關心誰會調用它，而事件源觸發也不用關心誰會處理它。

為了讓整個事件系統更有擴展性和通用性，knative 定義了很多事件相關的概念。簡單介紹一下：

• EventSource：事件源，能夠產生事件的外部系統
• Feed：把某種類型的 EventType 和 EventSource 和對應的 Channel 綁定到一起
• Channel：對消息實現的一層抽象，后端可以使用 kafka、RabbitMQ、Google PubSub 作為具體的實現。
• Subscription：把 channel 和后端的函數綁定的一起，一個 channel 可以綁定到多個knative service

補充：?

對于服務系統和事件系統，涉及到的內容比較多，后面會專門用2篇文章來講解

三、總結：

knative的優勢：

• 便利性：Knative 以 Kubernetes 作為其底層框架，因此無論是線上還是線下，任何 Kubernetes 集群，無論是云上 Kubernetes 服務還是自建 Kubernetes 集群，都可通過安裝 knative 插件快速的搭建 serverless 平臺。
• 標準化：Knative 聯合 CNCF，把所有事件標準化，統一為 CloudEvent，提供事件的跨平臺，同時讓函數和具體的調用方能夠解耦。
• 服務間解耦：使用 Knative 使得應用不在與底層依賴服務強綁定，可以跨云實現業務互通
• 成熟的生態：Knative 基于 Kubernetes 體系構建，與 kubernetes 生態結合更緊密；
• 自動伸縮：監控應用的請求，并自動擴縮容, 借助于istio(ambassador,gloo等)天生支持藍綠發布、回滾功能，方便應用發布流程。
• 應用監控：支持日志的收集、查找和分析，并支持 VAmetrics 數據展示、調用關系 tracing

Knative 解決了現在Serverless 的諸多問題

如果kubernetes是容器編排的事實上的標準，那么Knative也許就是未來serverless的事實上的標準。

總結

以上是生活随笔為你收集整理的【云原生系列】第二讲：Knative 简介的全部內容，希望文章能夠幫你解決所遇到的問題。

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