1. 什麼是 Serverless ? 什麼是 Knative ?

什麼是 Severless，下面是  CNCF  對 Serverless 架構給出的定義：

“Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment”

從定義中可以看出 Serverless 架構應該下面的幾個特點：

• 構建及執行應用的基礎設施環境

• 無需進行服務的狀態管理

• 足夠細粒度的部署模式

• 可擴充套件且按使用量付費

上面的幾個特點，除去 足夠細粒度的部署模式 外，Kubernetes 都能夠提供非常好的支援。幸運的是，不管是為了讓 Kubernetes 完整支援 Serverless 架構，還是 Google 在 cloud 上更加吸引開發者，Google 在Google Cloud Next 2018 上，釋出了 Knative，並將其稱為 : “ 基於 Kubernetes 的平臺，用來構建、部署和管理現代 Serverless 架構 ”。Knative的主要角色如下圖中所描述：

Knative 致力於提供可重用的“通用模式和最佳實踐組合”的實現，目前可用的元件包括：

• Build：Cloud-native source to container orchestration

• Eventing：Management and delivery of events

• Serving：Request-driven compute that can scale to zero

1.1 Build 構建系統

Knative 的構建工作都是被設計於在 Kubernetes 中進行，和整個 Kubernetes 生態結合更緊密；另外，它旨在提供一個通用的標準化構建元件，使其可以在廣泛的場景內得以使用。正如官方文件中的說 Build 構建系統，更多是為了定義標準化、可移植、可重用、效能高效的構建方法。Knative 提供了 Build CRD 物件，讓使用者可以透過 yaml 檔案定義構建過程。一個典型的 Build 配置檔案如下：

1.2 Serving：服務系統

Serving 的核心功能是讓應用執行起來以提供服務。其提供的基本功能包括：
* 自動化啟動和銷燬容器
* 根據名字生成網路訪問相關的 Service、ingress 等物件
* 監控應用的請求，並自動擴縮容
* 支援藍綠髮布、回滾功能，方便應用方法流程

Knative Serving 功能是基於 Kubernetes 和 Istio 開發的，它使用 Kubernetes 來管理容器（deployment、pod），Istio 來管理網路路由（VirtualService、DestinationRule）。
下面這張圖介紹了 Knative Serving 各元件之間的關係。

1.3. Eventing：事件系統

Knative 定義了很多事件相關的概念。介紹一下：
* EventSource：事件源，能夠產生事件的外部系統。
* Feed：把某種型別的 EventType 和 EventSource 和對應的 Channel 繫結到一起。
* Channel：對訊息實現的一層抽象，後端可以使用 kafka、RabbitMQ、Google PubSub 作為具體的實現。channel name 類似於訊息叢集中的topic，可以用來解耦事件源和函式。事件發生後 sink 到某個 channel 中，然後 channel 中的資料會被後端的函式消費。
* Subscription：把 channel 和後端的函式繫結的一起，一個 channel 可以繫結到多個 Knative Service。

目前支援的事件源有三個：github（比如 merge 事件，push 事件等），Kubernetes（events），Google PubSub（訊息系統），後面還會不斷接入更多的事件源。

1.4 Auto-scaling

Auto-scaling 其實本質上是用於提高雲上使用資源的彈性、提供按照使用量計費的能力，以提供給使用者高價效比的雲服務，其有以下兩個特點：
* Request-driving：根據請求量動態伸縮，目前透過統計系統當前併發請求量、和配置中的基準值比較，做出伸縮決策。
* Scale to zero：無流量時完全釋放資源，有請求時重新喚醒。

Knative Serving 中抽象了一系列用於定義和控制應用行為的資源物件，稱為 Kubernetes Custom Resource Definitions (CRDs) 。
* Service：app/function生命週期管理
* Route：路由管理
* Configuration：定義了期望的執行狀態
* Revision： 某一時刻 code + configuration ，Revision 是不可變物件，修改程式碼或配置生成新的 Revision
4者間的互動如下圖示：

Revision 生命週期有三種執行狀態：
* Active：Revision 啟動，可以處理請求
* Reserve：一段時間未請求為 0 後，Revision 被標記為 Reserve 狀態，並釋放佔用的資源、伸縮至零
* Retired： Revision 廢棄，不再收到請求
其具體的 auto-scaling 的過程，這裡就不介紹了，可以自行了解。

2. Knative 實踐

在上面大致瞭解 Knative 後，本節將詳細介紹如何完成 Knative 的部署。為方便大家能按指引同樣完成 Knative 的部署，因此選擇滴滴雲提供的基本的雲伺服器完成，大家可在滴滴雲上申請雲伺服器然後按下面的步驟，完成 Knative 的基本部署。若未註冊滴滴雲賬號的，可以透過此 完成註冊，有券^_^。

2.1 雲伺服器申請

註冊好滴滴雲賬號後，申請一個  16核32G記憶體，帶80G本地盤及500G EBS資料盤  的雲伺服器，然後申請一按流量計費的  公網 IP 。之所以申請這樣的配置，是為後續完成整個部署的過程更為順暢。

首先登入伺服器，滴滴雲出於安全考慮預設的登入賬戶是 dc2-user，並且 禁止了 root 使用者的直接登入 ，登入命令如下：

伺服器登入成功，使用 sudo su 命令完成到 root 賬戶的切換，購買雲伺服器時，我們購買了一塊 500G 的資料盤，由於從未掛載過，需要先  格式化雲盤 ，才能開始使用該雲盤。初始化的過程如下：

vdb 即為那塊新買的 EBS 盤。詳細的掛載流程可見 。透過教程的指引完成了資料盤的掛載，如下：

到目前為此，雲伺服器的準備好了，下面開始 knative 的部署。

2.2 Knative 部署

我們買的是一臺裸的雲伺服器，因此需要完成整個 Knative 的部署，大致需要下面的幾個步驟：
* Go 安裝
* Docker 安裝
* kubectl 安裝
* Minikube 安裝
* Istio 部署
* Knative Serving/Knative Build 部署

依次完成上面幾個相關元件的安裝。

2.2.1 Go 安裝

安裝 Go 環境,先使用 yum 安裝一個低版本的 Golang，如下：

但因為 Kubectl 必須要大於 Go.1.11 版本的 Golang，需要升級 Golang,如下：

也可以在此 下載對應的 Go 版本進行安裝。
至此基本完成了 Go 的安裝。

2.2.2 Docker 安裝

Docker 的安裝是為後面的叢集搭建做準備的，如下：

透過上面的步驟，即完成了 Docker 的安裝。下面繼續安裝其它元件。

2.2.3 Kubectl 安裝

因為 Knative 依賴 Kubernates，剛剛在滴滴雲只買了一個 DC2 雲伺服器，在開始之前還需要一個 Kubernates 叢集，由於只有一臺雲伺服器，直接選擇安裝  。安裝 Minikube 前可以先安裝 Kubectl 及相關驅動，這裡選擇透過原始碼編譯安裝，編譯原始碼需要有 Git、Golang 環境的支撐。安裝過程如下：

至此完成了 Kubectl 工具的安裝。也可以不透過此方式安裝，但需要注意版本是否正確，否則下面啟動 Minikube 時會報錯。

2.2.4 Minikube 安裝

下一步即開始安裝 Minikube，Minikube 的安裝如下：

因為 Minikube 的啟動其實也需要依賴一些牆外的映象，為了順利安裝需要將相應的映象提前準備好，然後以 Docker tag 方式進行標記，相關的命令，已經準備好，放在了 github 中，準備過程如下：

執行完上面的命令後，在無報錯的情況，透過下面的命令即可完成 Minikube 的啟動, 如下：

經歷上面的過程，minikube 基本是準備好了，下面開始安裝knative相關元件

2.2.5 Istio 部署

使用下面的命令開始安裝

幾分鐘後，各 pods 的狀態均會變為 running 或者 completed，如下：

至此 Istio 基本部署完成。

2.2.6 Knative Serving/kKnative Build 部署

下面開始部署 Knative 相關的元件

官方提供了上面的部署命令，但是因為科學上網的問題，最後是不可能裝成功的，下載上面的  release-lite.yaml  其實部分依賴的 image 檔案是在 gcr.io 等地方，如下：

除去上面的幾個外，還有一部分這裡不一一給出了，上面的映象地址是帶  digest  引用的，直接用 D ocker tag  其實是解決不了問題的，如下會報 refusing to create a tag with a digest reference 的錯誤：

  [ root @ 10 - 255 - 1 - 243   dc2 - user ] # docker tag doopymc/knative-queue gcr.io/knative-releases/queue-

  7204c16e44715cd30f78443fb99e0f58@sha256:2e26a33aaf0e21db816fb75ea295a323e8deac0a159e8cf8cffbefc5415f78f1

  refusing  to   create   a   tag  with   a   digest  reference

因此得想其它辦法，一個比較簡單的辦法是利用  Docker Hub  ，可在國內 pull，但它同時能拉取國外映象的特點，選擇在  Docker Hub  上構建一個以 目標映象 為 base 映象的方式，然後將上面  release-lite.yaml  上的目標映象替換為在  Docker HUb  上建立的映象地址即可。如下為一個 Dockerfile 的示例：

 refusing  to   create   a   tag  with   a   digest  reference

 FROM  gcr . io / knative - releases / github . com / knative / build / cmd / webhook @ sha256 :

 58775663a5bc0d782c8505a28cc88616a5e08115959dc62fa07af5ad76c54a97

 MAINTAINER  doop

Docker Hub  的構建示例如圖示：

這裡我已經完成了對  release-lite.yaml  不可使用映象的替換，也放在 github 上了，但只替換了這裡需要用到的部分，下面安裝 Knative 相關元件的過程如下：

同樣幾分鐘後，所有的 pod 均會變為 Running 狀態，如下：

到這一步 Knative 的部署基本完成，我們能看到在整個叢集中有那些 pod 及 svc，及他們對應的狀態，首先是 Service，如下：

再來看一下 pod，如下：

從上可以看出 pod 的狀態基本處於 Running 及 completed，至此 Knative 基本搭建完成，下面開始在 Knative 上跑一下官方的示例。

3. Knative 示例演示

3.1 應用訪問演示

按官方提供的 , 簡單修改了  service.yaml ，如下：

下面是此應用的啟動過程，如下：

幾分鐘後，應該會被正常拉起，如下：

下面開始訪問此應用，首先找到此服務的IP地址，如下：

可以看到 EXTERNAL-IP 為 狀態，大概是因為無外部的 LoadBalancer，因此採用示例中的第二種方式，獲取 IP， 如下：

下一步獲取服務的訪問地址，如下：

訪問服務如下：

   [ root @ 10 - 255 - 1 - 243   dc2 - user ] # curl -H "Host: hellodidiyun-go.default.example.com" {IP_ADDRESS}

  Hello  World :  hello ,   didiyun !

 

成功返回了  Hello World: hello, didiyun!  符合預期。

3.2 auto-scaling 演示

上面介紹 Knative 時，提到了其非常重要的一個機制  auto-scaling 。這裡看一下，上面訪問應用一段時間後， hellodidiyun-go  應用的 pod 會慢慢被 Terminate，如下示：

我們重新發起一次請求，然後看一下 pod 的狀態，如下：

服務重新啟動，符合預期。

4. 結語

以前 Serverless 架構更多隻能在公有云上才可執行及使用， Knative 出現後，相信會有更多服務獨立維護小的 Serverless 服務，當然 Knative 釋出時間不長，問題肯定不少，我們一起來發現它們吧。