國內在Minikube上搭建Knative及示例演示

1. 什麼是Serverless?什麼是Mnative?
什麼是 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 配置文件以下：

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: kaniko-build
spec:
  serviceAccountName: build-bot
  source:
    git:
      url: https://github.com/my-user/my-repo
      revision: master
  template:
    name: kaniko
    arguments:
    - name: IMAGE
      value: us.gcr.io/my-project/my-app
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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 的過程，這裏就不介紹了，能夠自行了解。 ---------------------