這篇文章給大家介紹Minikube中怎么搭建Knative，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

成都創(chuàng)新互聯公司成立于2013年，我們提供高端網站建設公司、成都網站制作、成都網站設計、網站定制、成都全網營銷推廣、微信小程序開發(fā)、微信公眾號開發(fā)、seo優(yōu)化排名服務，提供專業(yè)營銷思路、內容策劃、視覺設計、程序開發(fā)來完成項目落地，為成都三輪攪拌車企業(yè)提供源源不斷的流量和訂單咨詢。

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 架構應該下面的幾個特點：

構建及運行應用的基礎設施環(huán)境
無需進行服務的狀態(tài)管理
足夠細粒度的部署模式
可擴展且按使用量付費
上面的幾個特點，除去足夠細粒度的部署模式外，Kubernetes 都能夠提供非常好的支持。幸運的是，不管是為了讓 Kubernetes 完整支持 Serverless 架構,還是 Google 在 cloud 上更加吸引開發(fā)者，Google 在Google Cloud Next 2018 上，發(fā)布了 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 構建系統(tǒng)
Knative 的構建工作都是被設計于在 Kubernetes 中進行，和整個 Kubernetes 生態(tài)結合更緊密；另外，它旨在提供一個通用的標準化構建組件，使其可以在廣泛的場景內得以使用。正如官方文檔中的說 Build 構建系統(tǒng)，更多是為了定義標準化、可移植、可重用、性能高效的構建方法。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：服務系統(tǒng)
Serving 的核心功能是讓應用運行起來以提供服務。其提供的基本功能包括：

自動化啟動和銷毀容器
根據名字生成網絡訪問相關的 Service、ingress 等對象
監(jiān)控應用的請求，并自動擴縮容
支持藍綠發(fā)布、回滾功能，方便應用方法流程
Knative Serving 功能是基于 Kubernetes 和 Istio 開發(fā)的，它使用 Kubernetes 來管理容器（deployment、pod），Istio 來管理網絡路由（VirtualService、DestinationRule）。
下面這張圖介紹了 Knative Serving 各組件之間的關系。

1.3. Eventing：事件系統(tǒng)
Knative 定義了很多事件相關的概念。介紹一下：

EventSource：事件源，能夠產生事件的外部系統(tǒng)。
Feed：把某種類型的 EventType 和 EventSource 和對應的 Channel 綁定到一起。
Channel：對消息實現的一層抽象，后端可以使用 kafka、RabbitMQ、Google PubSub 作為具體的實現。channel name 類似于消息集群中的topic，可以用來解耦事件源和函數。事件發(fā)生后 sink 到某個 channel 中，然后 channel 中的數據會被后端的函數消費。
Subscription：把 channel 和后端的函數綁定的一起，一個 channel 可以綁定到多個 Knative Service。
目前支持的事件源有三個：github（比如 merge 事件，push 事件等），Kubernetes（events），Google PubSub（消息系統(tǒng)），后面還會不斷接入更多的事件源。

1.4 Auto-scaling
Auto-scaling 其實本質上是用于提高云上使用資源的彈性、提供按照使用量計費的能力，以提供給用戶高性價比的云服務，其有以下兩個特點：

Request-driving：根據請求量動態(tài)伸縮，目前通過統(tǒng)計系統(tǒng)當前并發(fā)請求量、和配置中的基準值比較，做出伸縮決策。
Scale to zero：無流量時完全釋放資源，有請求時重新喚醒。
Knative Serving 中抽象了一系列用于定義和控制應用行為的資源對象，稱為Kubernetes Custom Resource Definitions (CRDs)。

Service：app/function生命周期管理
Route：路由管理
Configuration：定義了期望的運行狀態(tài)
Revision: 某一時刻 code + configuration ，Revision 是不可變對象，修改代碼或配置生成新的 Revision
4者間的交互如下圖示：

Revision 生命周期有三種運行狀態(tài)：
Active：Revision 啟動，可以處理請求
Reserve：一段時間未請求為 0 后，Revision 被標記為 Reserve 狀態(tài)，并釋放占用的資源、伸縮至零
Retired: Revision 廢棄，不再收到請求
其具體的 auto-scaling 的過程，這里就不介紹了，可以自行了解。

關于Minikube中怎么搭建Knative就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。